W3C home > Mailing lists > Public > www-style@w3.org > May 2012

Re: [css-variables] CSS Variables are a NEW kind of variable

From: Florian Rivoal <florianr@opera.com>
Date: Tue, 29 May 2012 09:31:01 +0200
To: www-style@w3.org
Message-ID: <op.we165zda4p7avi@localhost.localdomain>
On Mon, 28 May 2012 01:54:43 +0200, Thaddee Tyl <thaddee.tyl@gmail.com>  
wrote:

> On Sun, May 27, 2012 at 6:57 AM, Fran├žois REMY
> <fremycompany_pub@yahoo.fr> wrote:
>> It's important to understand that CSS variables are inherited from the
>> parents and are able to emulate some preprocessor-like variables: one
>> variable can be defined at one place, the root of the document, and stay
>> unoverriden everywhere else. The main use-cases of such globals are to  
>> allow
>> alternate stylesheets to redefine constants instead of redefining a  
>> whole
>> set of css declaration, and to promote the use of easily maintainable  
>> css
>> code. Both are pretty important use cases.
>
> It seems to me that there can be many acceptable scope systems.
> Having variables be cross-CSS files seems far from logical to me.
> As a result, I'm not sure anymore of what a global is.
>
> Also, can we have a system to choose the scope in which a variable is?

The CSS working group discussed a number of variables propositions before
this one. Some scoped the variables to be valid in a single style sheet.
Some did the same, but allowed them to be defined in one style sheet
and used in another through @import. Some were completely global, and
applied to any style sheet loaded for the current document.

All these proposals had interesting aspects, but each time we tried to
figure out the implications of scope working the way it did, we ended
up finding situations that a significant number of the WG's member
could point to, saying: "see, this is why it can't work".

The latest proposal is based on the existing cascade, which solves all
of that. There is no need to discuss a scoping mechanism that may end
up conflicting with how CSS works in general, as it naturally fits with
the rest.

Also, using the cascade opens up a number of new uses that are just
impossible in a preprocessor, because the cascade isn't there at
preprocessing time, and that also is a significant win.
As long as variable proposals were things that could be done
in a preprocessor, a number of the working group members felt
that doing them in a preprocessor rather than in the browser was
perfectly adequate.

So here we are, with a mechanism that fits CSS well, solves the
number one use case for variables (centralize color definitions),
and allows things that can't be done server side. This convinced
the working group that we should go after this proposal, after
many years of rejecting various other proposals.

  - Florian
Received on Tuesday, 29 May 2012 07:31:36 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:54 GMT