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: 
http://www.w3.org/WAI/PF/aria/#disabled

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

cheers,
David

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