A css discussion...

Jacob Farber jacob.farber at utoronto.ca
Thu Jul 31 20:21:15 UTC 2008

Thanks - your point about utilizing semantics in the host language is  
critical to creating a cleaner starting point for implementors.
We should definitely avoid redundant information when there is a native  
property that can do it for us, which is what Eli touched upon with his  

On Thu, 31 Jul 2008 16:12:50 -0400, David Bolter  
<david.bolter at utoronto.ca> wrote:

> 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?

Jacob Farber

More information about the fluid-work mailing list