Re: CSS Variables Draft Proposal

On Mon, Feb 14, 2011 at 3:32 PM, Peter Linss <peter.linss@hp.com> wrote:
> 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 ':'.

These are fine with me.  I have to sit down and see if I can define
precisely the syntax that we want to allow is.  It sounds like Bjoern
has the basic restrictions down that would prevent some of the sillier
things here.


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

You need to allow "," and "/", so you can put a whole property value
in a variable.  That said, I share the fear you have, and have
outlined some restrictions in a section at the end of the draft that
I'd like to incorporate.


> Another thing occurred to me, what about inline style declarations, ie:
> <head>
>   <style>
>     @var $foo red;
>   </style>
> </head>
> <body>
>   <p style='color: $foo'>Text</p>
> </body>
> I presume we want that to work too?

Yeah, there's no reason why it shouldn't.  You can use
@font-face-defined font families in inline styles.


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

Yes.  (Though this can wait for the next level of calc() that allows
things like attr() inside, too.)

~TJ

Received on Tuesday, 15 February 2011 18:18:07 UTC