A css discussion...

Jacob Farber jacob.farber at utoronto.ca
Thu Jul 31 18:58:03 UTC 2008

This is exactly what Eli and I are attempting to solve.
Placement and physical organization of the files and they're respective  
content still needs to be fleshed out a fair bit. One way is to break it  
down by function (so for each component would have its own CSS file,  
and/or share a common css file for global state declarations, and within  
each components file there would be a breakdown of presentation, states,  

Im trying to quite my habit of underscorism, but group therapy takes a bit  
of time...

On Thu, 31 Jul 2008 14:47:35 -0400, Antranig Basman  
<antranig at caret.cam.ac.uk> wrote:

> Yes, I think that sounds like a good strategy, although I'm sure
> you will find that Colin despises your underscorism :)
> A further issue is where physically to package "built-in" CSS
> styles and what convention to establish for finding these things -
> perhaps the "Fluid Loader" that I have drafting up might help with
> this.
> As I questioned on the channel a few days ago where to put things
> like the default CSS file for the tiny little "Undo" visual
> state that appears when you change a field.
> For example, this now consists of the words
> .fluid-undo {
>   font-size: smaller;
> }
> which violates all kinds of criteria on sensible naming and
> packaging.
> Cheers,
> A.
> 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

Jacob Farber

More information about the fluid-work mailing list