A css discussion...
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:
> (... and for "mySelector" look for a corresponding aria role)
> Jacob Farber wrote:
>> 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
>> spits out visual effects like
>> 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
>> 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.
>> Any thoughts?
More information about the fluid-work