A css discussion...

[Eli Cochran]

Jacob,
I agree with your approach.

I'll add one more thing, which is that where possible we should use  
attributes as well. For example instead of setting

<input class="myDiv disabled" />

we should use:

< input class="myDiv" disabled="disabled" />

Unfortunately the CSS for this is not very well supported by IE6  
(#myDiv[disabled]). But the advantage of using attributes is that this  
is semantically correct and supported by browser behaviors. (Not all  
elements support disabled.)

I did not really take advantage of this for Uploader but I should have.

- Eli

On Jul 31, 2008, at 11:41 AM, Jacob Farber wrote:

> Hello,
> Eli and I are working on a system to neatly package our components  
> into
> more approachable examples of what they can do. In doing so, the
> discussion led to a technique I wanted to toss around:
>
> The ideas was about separating CSS selectors and CSS as other  
> functions.
> What we do now is something like this-
>
> <div class="mySelector-disabled"></div>
>
> which represents a lot information.
>
> Sometimes we prefix the class with "mySelector" and save that as a
> selector, we attach a suffix like "disabled" to represent a state  
> for the
> element, or maybe we even bake the state into the javascript that  
> spits
> out visual effects like $("div.mySelector").css("display","none").
> More so, we overload this element with css stylings through either  
> that
> class name and/or css3 selector patterns (which are fragile).
>
> What about a more semantic and recycleable approach, where you divide
> class names into roles (Selector, State, Presentation)?
>
> <div class="mySelector state_disabled theme_redAndBlue"></div>
>
> Here, by default we can offer a semantic class name as a selector, or
> allow the implementor to override it with another pattern (maybe no  
> class
> name at all), without any negative effects on presentation or state.
>
> We can offload the presentation into an easy to read canned css  
> group or
> file where a designer can easily modify it or erase its properties
> entirely.
>
> we can also offload the elemetns state into a more semantic and re- 
> usable
> class name, which will be easier to maintain and reduce the amount  
> of code
> required to achieve certain effects (state_focus/blur,
> state_disabled/enabled, state_valid/invalid, etc)
>
> The idea is we've put a lot of brainpower into making our JS less  
> fragile
> and prone to breakage, but I think CSS needs the same TLC.
> Any thoughts?
>
> -- 
> Jacob Farber
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

. . . . . . . . . . .  .  .   .    .      .         .              .                     .

Eli Cochran
user interaction developer
ETS, UC Berkeley