A css discussion...

Jacob Farber jacob.farber at utoronto.ca
Thu Jul 31 19:15:18 UTC 2008


In that situation it is definitely more sematic (and required), but like  
you said - poorly supported in browsers, plus it is a specific situation  
where you have attributes designed for the task.
Im not sure if you could find an equivalent attribute when you want to say  
more complex things.

Jacob

On Thu, 31 Jul 2008 15:07:57 -0400, Eli Cochran <eli at media.berkeley.edu>  
wrote:

> Jacob,
> I agree with your approach.
>
> I'll add one more thing, which is that where possible we should use  
> attributes as well. For example instead of setting
>
> <input class="myDiv disabled" />
>
> we should use:
>
> < input class="myDiv" disabled="disabled" />
>
> Unfortunately the CSS for this is not very well supported by IE6  
> (#myDiv[disabled]). But the advantage of using attributes is that this  
> is semantically correct and supported by browser behaviors. (Not all  
> elements support disabled.)
>
> I did not really take advantage of this for Uploader but I should have.
>
> - Eli
>
> On Jul 31, 2008, at 11:41 AM, 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
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at fluidproject.org
>> http://fluidproject.org/mailman/listinfo/fluid-work
>
> . . . . . . . . . . .  .  .   .    .      .         .               
> .                     .
>
> Eli Cochran
> user interaction developer
> ETS, UC Berkeley
>
>



-- 
Jacob Farber



More information about the fluid-work mailing list