A css discussion...

Antranig Basman antranig at caret.cam.ac.uk
Thu Jul 31 18:47:35 UTC 2008


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



More information about the fluid-work mailing list