W3C home > Mailing lists > Public > www-style@w3.org > February 2011

Re: CSS Variables Draft Proposal

From: Peter Linss <peter.linss@hp.com>
Date: Mon, 14 Feb 2011 15:32:00 -0800
Cc: "L. David Baron" <dbaron@dbaron.org>, Boris Zbarsky <bzbarsky@MIT.EDU>, "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
Message-Id: <A117FD08-904C-4A04-8141-CFA0869EB674@hp.com>
To: "Linss, Peter" <peter.linss@hp.com>
On Feb 14, 2011, at 3:18 PM, Linss, Peter wrote:

> On Feb 14, 2011, at 2:02 PM, L. David Baron wrote:
>> On Monday 2011-02-14 16:28 -0500, Boris Zbarsky wrote:
>>> {snip}
>>> I agree that a raw token stream may not be the right thing due to
>>> things like:
>>>  @var foo 255, 255);
>>> which could add pretty oddly if $foo is used like so:
>>>  color: rgb(0, $foo, 0);
>> FWIW, what I'd want is a token stream that has balanced (), {}, and
>> [], and of course no ; at top-level (not within the (), {}, or []).
> If it's going to be a "token stream", then I'd say, balanced () and  
> [], NO '{', '}', ':' or ';'
> Having braces conflicts with forward compatible @rule parsing, ie:
> @var $foo bar { baz; } blah;
> An older client would terminate the @var before the 'blah'.  
> Furthermore braces have no place in a property value, neither does a  
> ':'.

For that matter, I'm not too sure about allowing ',' or '/' either,  
see my previous (unanswered) note about variables used in shorthands.  
Putting commas and/or slashes in a variable used in the middle of a  
shorthand property can cause the following values to have to be re- 
interpreted, perhaps dramatically. I'm not sure if we want to allow  
that. There are probably some other delimiters we'd want to restrict  
as well.

When you go down that path, even having multiple values in a variable  
can get dangerous.

Another thing occurred to me, what about inline style declarations, ie:

     @var $foo red;
   <p style='color: $foo'>Text</p>

I presume we want that to work too?

Ok, another fun one, what about calc? Do we want to allow variables  


Received on Monday, 14 February 2011 23:32:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:56 UTC