A css discussion...

Eli Cochran eli at media.berkeley.edu
Thu Jul 31 19:27:53 UTC 2008


Yes, I should have added "where appropriate".

- Eli

On Jul 31, 2008, at 12:15 PM, Jacob Farber wrote:

> 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

. . . . . . . . . . .  .  .   .    .      .         .              .                     .

Eli Cochran
user interaction developer
ETS, UC Berkeley





More information about the fluid-work mailing list