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

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

From: Divya Manian <manian@adobe.com>
Date: Thu, 14 Jun 2012 11:58:18 -0700
To: Sylvain Galineau <sylvaing@microsoft.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Chris Eppstein <chris@eppsteins.net>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <CBFF7437.2F68%manian@adobe.com>
On 6/13/12 6:48 PM, "Sylvain Galineau" <sylvaing@microsoft.com> wrote:

>
>[Tab Atkins Jr.:]
> 
>> You seem to be saying that if variable declarations look like
>>properties,
>> then they must be identical to properties (and properties must be
>> identical to variable declarations), and if they're different at all,
>>then
>> they must look different.

It is not about looking different. This is what I know about CSS Variables:

No browser should use a user-defined variable to implement a feature (for
example: Using current syntax: var-hover-color: red; should never be
parsed and rendered to apply to all elements which go to hover state).
Currently all browsers that claim to implement CSS are required to parse
and applt properties defined in CSS specs (e.g. 'Background-color').

Typically variables have a default value that is set to inherit/none or
one of the options that the property can take. In this case, the default
value used to be a mysterious invalid, but is now an empty string. I do
not know of any css property that has this default value.


The variable does not quite 'apply' to any element. It is only available
for use within an element that it is defined in.

The effect of a variable can only be seen when it is used as a value for a
property. In this part it acts as a proxy for a value.

Not only is it just a proxy for value, but it can also be an input to a
function that is used to output a value (gradients, attrs, calcs).

However, the variable cannot be applied as a value for @-rule features and
, contrary to how Sass/Less variables operate, these variables cannot be
proxies to other properties.

I think there are sufficient differences to merit defining variable as an
entirely new definition without piggybacking on CSS properties.

What I fear is that we will soon find new usecases for variables that
would suddenly alter our perception of what they are and then we would
want to alter the definition of a property to accommodate for the new use
case and then a whole lot of bikeshedding will occur on whether this
existing property should be altered and then 100 people will chime in on
how it will break everything that exists on the web.

I would rather the bikeshed be a small one and restricted to esoteric edge
features of CSS that would not cause such heart burn among the CSS
old-timers. 

My point is, we should not go with the solution that is merely palatable
to the CSS WG but we need to find a solution that is as less destructive
in the future and as easy to understand and use *correctly* as possible by
developers. 

>Assuming I read all this right, the suggestions were to either:
>	
>1. Give users the extra capability suggested to them by the syntax
>
>	OR
>
>2. Adjust the syntax in such a manner that 'universal' property
>references are 
>unambiguously out of scope.


Sure. But I just am concerned with shoe-horning new features into a dated
model, especially one that was not designed to solve the problems that
variables are expected to solve.

I am not attached to any syntax, or proposal as others in this thread seem
to be. Nor am I  a language designer to propose a new syntax. I can only
tell, if as a web developer, the syntax appears as something I would use
correctly right off the bat. In this case, it is definitely not the case.
I think this feature is too important to get it wrong the first time  and
have the initial haphazard implementation guide the rest of features that
would depend on it.
Received on Thursday, 14 June 2012 18:58:55 GMT

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