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

On Tue, May 22, 2012 at 6:56 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> * Tab Atkins Jr. wrote:
>>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.".
>
> Breaking style sheets and forcing implementers to change their token-
> izer every time you discover yet another place where you want to dis-
> allow comments is not improving the language in any way.

If you read my email, I agree with you.  Breaking a non-trivial amount
of public content is a strong argument against making a change,
because it hurts authors and users (and then, by extension, hurts
browsers too).

The fact that an impl has to change isn't a strong argument - that has
to happen every time we make any change or addition to the language at
all.  If a change is *difficult*, that's a moderate argument against a
feature.  What I'm suggesting here definitely is not.

~TJ

Received on Wednesday, 23 May 2012 16:07:33 UTC