Re: CSS Variables Draft Proposal

On Thu, Feb 10, 2011 at 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.)

The contents of unquoted url() expressions might be in a similar boat.
 I don't care how either of these cases get handled, because they were
both mistakes, so long as it's well-defined.  I'm willing to spec
whatever implementors want here.

Let's work on the definitions, though.  I'm aiming for allowing
primitive values, functions, and separators (which should just
constitute whitespace, commas, and slashes, right?).


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

This seems equivalent to the distinction between "red" and "r ed".
Yes, there's certainly a difference between "whitespace" and "no
whitespace" - this is generally true in CSS outside of a couple of
separators.  Outside of unquoted font-family, there shouldn't be any
distinction between "some whitespace" and "some more whitespace".


>  font-family: Times New Roman;
>  font-family: TimesNew Roman;

I'm not sure how this sort of ambiguity would arise with variables.


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

Certainly, yes.  Isn't that a restriction on the core-grammar level already?

~TJ

Received on Thursday, 10 February 2011 21:30:23 UTC