A css discussion...

Jacob Farber jacob.farber at utoronto.ca
Thu Jul 31 18:41:35 UTC 2008


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