A css discussion...

David Bolter david.bolter at utoronto.ca
Thu Jul 31 20:12:50 UTC 2008

Interesting. My gut likes this Jacob.

In cases where you do a selector like "state_foo", probably a good rule 
of thumb to look to see if there is an aria-foo property/state/attribute 
so that semantics are captured.  Look for semantics in the host language 
(html, xhtml or whatever) too of course.
e.g. for "state_disabled" consider also adding the aria-disabled state: 

(... and for "mySelector" look for a corresponding aria role)


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?

More information about the fluid-work mailing list