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