Re: WebKit now supports CSS Variables

On Jun 29, 2008, at 10:00 AM, Simetrical wrote:

> But if I'm reading this correctly, this requires local styles to be
> placed *before* global styles.  This is the opposite of the way things
> are normally done in CSS, where the *later* styles take precedence.  I
> think this might cause quite a bit of extra clutter.  For instance,
> consider the MediaWiki software.  It loads all of the following
> stylesheets, in the following order (some possibly appended onto the
> end of others, some loaded really as separate files):
>
> * A hardcoded common CSS file shared among all skins, users, etc.
> * A hardcoded skin-specific CSS file
> * An admin-customizable common CSS file
> * An admin-customizable skin-specific CSS file
> * A user-specific CSS file to enforce preferences selected through  
> the GUI
> * A manually-created user-specific CSS file (that can contain
> arbitrary CSS rules)
>
> Each one of these must override the previous one, logically.
> Currently this is achieved simply by loading them in that order.  To
> override the previous one, you just include a rule, and it magically
> works, overriding existing rules with the same specificity.

Yes, and you would be able to continue to do so, same as you do now.

> But for constants to be overridable at all levels, the stylesheets
> would have to be loaded in the *opposite* order.  The manual
> user-specific stylesheet's constants would need to go first, then the
> automatic user-specific stylesheet, and so forth.  This reverses
> current behavior and complicates it.

To my mind this allows more flexibility. You can continue to have  
additional style sheets overriding each other, when it is most useful  
to do it that way, but you can also have some global constants  
declared up front that are guaranteed to remain exactly as you  
declared them there, regardless of additional rules. Of course you  
could always add more specificity in a later rule, but then you are  
really then overriding one of the key features of constants: their  
constancy.

> To get the full flexibility of
> the proposal, allowing any stop along the line to change the
> variables, you'd have to include twice as many stylesheets, separating
> constants out from everything else.

I would say that if you want that variety of theming, in which  
subsequent rules make changes to previous rules, then you already have  
it. For that sort of theme support, @var does not really add that  
much. It does add other benefits, which are also present in @const,  
but for theme support, it seems you already have what you want. For  
@conts, there is a big benefit of NOT allowing any stop along the line  
to change the values. It is the same reason programmers sometimes use  
constants instead of variables, and why they are usually at the  
beginning of the program code.

Received on Sunday, 29 June 2008 19:48:51 UTC