Re: [css-variables] Using $foo as the syntax for variables

On Mon, May 21, 2012 at 5:43 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> * Tab Atkins Jr. wrote:
>>Some further details - to handle $foo in the syntax, we'll either need
>>to add a VAR token to the grammar (defined identically to HASH but
>>with the $ character instead of #) or accept that variables show up in
>>the tokenizer as a $ DELIM followed by an IDENT.  The latter is
>>suboptimal, though - it allows comments between the $ and the foo,
>>which sucks, and it means we have to deal with the "first character of
>>an IDENT" detail, despite there being no ambiguity (HASH gets to avoid
>>all that and just use "nmchar+").
>
> Do you think CSS should have a core syntax that fully describes where
> comments are allowed and that does not change every couple of months?
>
> I am asking because you argued that comments between a sign and a num-
> ber should be disallowed, now argue that comments between '$' and an
> identifier should be disallowed, and I suspect you would also argue a-
> gainst allowing comments, say, between the ':' and the identifier in a
> pseudo-class selector, and everything else that you regard as "atomic"
> construct, say, "!important". If the Working Group agrees, that would
> likely mean that COMMENT tokens are treated as if they were whitespace
> tokens. If you would like that, I think it would be good if you could
> start a new thread to that end, and if the idea does not find support,
> simply accept the tokenizer as it has been defined. It's after all part
> of the one "we promise to never ever change this" section of CSS 2.1.

I think we should have a syntax that is forward-compatible, such that
we can make changes that are gracefully ignored in legacy clients.
Luckily, that's precisely what we have now, so yay!

Attempting to lock the syntax forever is a silly restriction.  It
restricts our ability to improve the language in some ways.  It
doesn't *gain* us anything, either, as long as we stay within the
confines of the forward-compatibility error-parsing rules.  Parsers
based on the old syntax still work to parse new stuff - they just
either accept some things that are now "invalid" or trigger
error-recovery on some new newly "valid" things.  The latter is just
the day-to-day operation of legacy clients as we add new properties
and such.

We should reject changes that would break non-trivial amounts of
existing content.  That's the only reasonable restriction that we can
operate under; anything else would mean that we're promoting
theoretical purity over improving the language for everyone else.  I
refuse to reject a good suggestion with an excuse like "Sorry, your
change is good and we know that it wouldn't actually cause any
problems, but some of us decided a few years ago to reject all of
these types of changes anyway.".

~TJ

Received on Tuesday, 22 May 2012 01:15:26 UTC