- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Tue, 15 Feb 2011 07:58:23 -0800
- To: Peter Linss <peter.linss@hp.com>
- 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>
On Feb 14, 2011, at 3:32 PM, Peter Linss wrote:
>>> 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
My thoughts are that we would not want the first character to be a comma or slash or parens or brackets, and that the last character should not be a comma or slash. Thus if the variable is used as a component, it would fit in between normal delimiters in the value. But we could still allow commas and slashes within the variable def, as long as it wasn't first or last character, so that a variable could represent a complete value (even a complete shorthand value).
Perhaps we could say that any variable definition containing commas or slashes can only be used for complete values and not just components of a value.
Received on Tuesday, 15 February 2011 15:59:03 UTC