A css discussion...
eli at media.berkeley.edu
Thu Jul 31 19:27:53 UTC 2008
Yes, I should have added "where appropriate".
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.
> On Thu, 31 Jul 2008 15:07:57 -0400, Eli Cochran <eli at media.berkeley.edu
> > wrote:
>> 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
>> - Eli
>> On Jul 31, 2008, at 11:41 AM, Jacob Farber wrote:
>>> Eli and I are working on a system to neatly package our components
>>> 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
>>> 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
>>> out visual effects like $("div.mySelector").css("display","none").
>>> More so, we overload this element with css stylings through either
>>> class name and/or css3 selector patterns (which are fragile).
>>> What about a more semantic and recycleable approach, where you
>>> 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,
>>> 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
>>> we can also offload the elemetns state into a more semantic and re-
>>> 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
>>> 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
>> . . . . . . . . . . . . . . . . . . .
>> Eli Cochran
>> user interaction developer
>> ETS, UC Berkeley
> Jacob Farber
. . . . . . . . . . . . . . . . . . .
user interaction developer
ETS, UC Berkeley
More information about the fluid-work