Re: CSS Variables

On Mon, Feb 7, 2011 at 1:35 PM, L. David Baron <dbaron@dbaron.org> wrote:
> On Saturday 2011-02-05 16:34 -0800, Tab Atkins Jr. wrote:
>> The syntax isn't complex.  What we're going with so far is this:
>>
>> @var $foo red;
>> bar {
>>   color: $foo;
>> }
>>
>> The @var rule declares a single variable, taking a name and then
>> arbitrary CSS as a value.  The var name must start with a $ character,
>> so we can use $ as an unambiguous indicator in the content that a
>> variable is being used.
>
> What does "arbitrary CSS" mean?  Is it a character stream?  A token
> stream?  A valid value?  A valid part of a value?  (Failing to
> answer this question clearly before implementing may lead to a spec
> that depends on the details of a particular implementation.  The
> answer to this question also has *significant* effects on how hard
> this proposal is to implement, but those answers may be different
> for different implementations.)

I didn't go into too much detail in my original email, since it was
too long already, but yeah, it's an excellent question and one that
we're working through the precise implications of.  I'm definitely
shooting for 100% clear definitions.

At minimum, it's a token stream.  We want higher-level restrictions,
though.  I cursorily mentioned the direction we're exploring right
now, which is that the value given must be something that would be
valid if given an appropriate type.


> Or, to put it more concretely, which of the following lines are valid:
>
>  (a) @var $a x;             p { width: 20p$a; }
>  (b) @var $b Roman";        p { font-family: "Times New $b; }
>  (c) @var $c 2px;           p { text-shadow: green $c $c; }
>  (d) @var $d green 2px 2px; p { text-shadow $d; }
>  (e) @var $e green 2px 2px; p { text-shadow $e, $e; }
>  (f) @var $f green 2px 2px; p { text-shadow $f 3px; }
>  (g) @var $g 2px, green;    p { text-shadow: blue 2px $g 1px 1px; }
>
> (Note that line (b) is not compatible with the forwards-compatible
> parsing rules.)
>
>
> My expectation, for the record, would be that the answer is "token
> stream", which would make lines (c) through (g) valid, but (a) and
> (b) invalid.

(I numbered your lines explicitly for easier reference.)

I like the way you think, because I produced almost exactly the same
examples myself when we were exploring this space.

(a) and (b) are definitely invalid.  (c), (d), and (e) are definitely
valid.  The variable declaration for (f) is definitely valid, but
we're not completely decided on whether the use is valid or not.  I
lean toward it being invalid, because "partial shadow" won't be a
valid type.  We're somewhat more aligned toward declaring (g) invalid
(again, the variable declaration may be valid, but not the use).

(f) and (g) are most subject to implementation constraints.  It would
be awesome to hear how difficult making them valid/invalid would be
for Firefox and other browsers.

(By the way, (a) and (b) are horrifying.  Seriously, it scares me to
even contemplate the sort of fucked up code that would result from
such an abomination.)

~TJ

Received on Monday, 7 February 2011 22:55:18 UTC