A css discussion...
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
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
which violates all kinds of criteria on sensible naming and
Jacob Farber wrote:
> 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
> 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
> 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
More information about the fluid-work