A css discussion...
jacob.farber at utoronto.ca
Thu Jul 31 18:41:35 UTC 2008
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-
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
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
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.
More information about the fluid-work