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

On Thu, Jun 14, 2012 at 11:58 AM, Divya Manian <manian@adobe.com> wrote:
> 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').

I don't understand the distinction you're drawing here.  The effect of
a variable property is to assign a value to a var.  That line just
ensures that silly implementors don't try and hook UA-defined stuff
off of it in an attempt to route around standards body, like people
occasionally suggest for @data (which has similar text).


> 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.

An empty value, actually, not an empty string.


> 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.

As Sylvain says, can you actually suggest something?  I have no idea
what you're trying to suggest I change things to.  The only concrete
suggestions I've gotten so far have been several suggestions for
different names within the current structure, then one suggestion for
nesting an at-rule inside of style rules for defining vars.


> 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.

The future always makes our well-considered designs look stupid and
short-sighted.  Can you explain why you think the current structure is
future-hostile for something?  The only thing I know of so far that
the current design prevents is using a variable's value for a property
name.  As far as I can tell, the only use-case for this is renaming
properties to shorter forms, though, which doesn't seem like a
sufficiently strong use-case to warrant changing the syntax around it.


>>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.

Unfortunately, I'm not sure what else to do without suggestions, and
I'm not sure how to design around future pitfalls without a decent
example of how the current design is future-hostile to some use-case.

~TJ

Received on Thursday, 14 June 2012 19:43:54 UTC