Re: CSS Variables Draft Proposal

On 2/10/11 1:06 PM, "L. David Baron" <dbaron@dbaron.org> wrote:

>On Thursday 2011-02-10 12:44 -0800, Tab Atkins Jr. wrote:
>> On Wed, Feb 9, 2011 at 6:56 PM, Linss, Peter <peter.linss@hp.com> wrote:
>> > On 2/9/11 5:22 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>> > "A token stream" is really dangerous (or exceptionally powerful,
>>depending
>> > on your point of view). You're definitely going to have to tighten
>>this
>> > up.
>> 
>> Yeah, "token" isn't the word I want here.  More like "component
>> value".  I've edited the language in the draft, but this needs some
>> thought to capture the right concept.
>
>I think this change makes the proposal much harder to implement,
>since it requires implementations to enforce that there's never a
>situation where part of a component value comes from a variable and
>part doesn't (or comes from a different variable).  Since there's
>nothing close to a definition of what a component value is, it's
>hard to know how much work enforcing that is, but it could be
>substantial.
>
>(If we go down this road, I think we're likely to end up with the
>rule that variables are not permitted in values of 'font-family',
>for example.)
>
>> > Consider:
>> >
>> > @var $foo bar, baz / 100px     ;
>> >
>> > Does that simply get dropped into place macro style? Including the
>>leading
>> > and trailing whitespace?
>> 
>> @var is not a character macro (shudder).  This gets parsed into three
>> component values and two separators, and gets substituted in as such.
>
>There are cases in CSS where whitespace is substantive.  Consider:
>  p.foo
>  p .foo
>
>  font-family: Times New Roman;
>  font-family: TimesNew Roman;

Right. Now how about:
@var $foo Times; p { font-family: $foo New Roman }

>
>> > Do we really want that?
>> >
>> > How about:
>> > @var $foo url(;
>> > @var $bar );
>> >
>> > p { content: $foo http://example.com/yikes.gif $bar }
>> 
>> Oh jeezus no.  I don't know the precise details of url() parsing, but
>> either that is parsed into a single $foo variable containing
>> "url(;\n@var $bar )", or they're both invalid.  Either way works for
>> me.
>
>Even if variables represent a token-stream, we should require that
>they be (), {}, and [] -balanced.

We also need to prohibit ':' from being in a variable value.

Now, how about:

@var $foo */;

Or if at runtime I change a variable value to "/*"?

I think the "token stream" concept is opening us up to a word of hurt...

Variable values are going to need to be very tightly restricted... and/or
the rules of variable expansion. The more I think about "hixie style evil
test cases" the more I think variable values should be only a single
property value.

Received on Friday, 11 February 2011 01:25:09 UTC