A css discussion...

[David Bolter]

Thanks, agreed Eli covered the html disabled attribute. Actually I was 
hoping my main point was about ARIA :)

I'm thinking that implementors can look at both ARIA *and* native host 
markup for semantics. The distinction is admittedly fuzzy... especially 
when one looks at html5.

cheers,
D

Jacob Farber wrote:
> 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 example.
>
> 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?
>>>
>>>
>>
>
>
>