Re: Explicit feature manifesting for backward-compatibility safety (Was: Comment syntax)

On Mon, Aug 27, 2012 at 4:07 PM, Marat Tanalin | tanalin.com
<mtanalin@yandex.ru> wrote:
> 28.08.2012, 02:27, "Tab Atkins Jr." <jackalmage@gmail.com>:
>> Right now, you can naively minify just by replacing all runs of
>> whitespace with a single space.  (The only exception is if you use a \
>> at the end of a line to create a multi-line string, but this is rare
>> enough that I wouldn't be surprised if there were plenty of naive
>> minifiers that didn't take this into account.)  If you use // comments
>> on your source document, the minified document today will act
>> identically (the next property will be ignored as invalid).  If we
>> switched behavior, it would instead remove the entire rest of the
>> stylesheet.
>>
>> This is, unfortunately, a problem with *existing* stylesheets, so we
>> can't just rely on the "well, don't do that" defense.  I'd like a
>> reasonable assurance that adding this wouldn't cause a significant
>> number of sites to suddenly break due to this. ^_^
>
> A way to explicitly manifest newer features that author of specific styleshet is intended to use in the stylesheet would be helpful in cases like introducing new syntax features like one-line comments [1]:
>
>     @features {
>         one-line-comments;
>         some-another-feature;
>     }
>
> In the example, new features that are potentially risky for older user agents and/or stylesheets are _disabled by default_. Such features then are enabled _only_ if they are listed in `@features` rule that means "this stylesheet's author knows about this feature and intends to use it".
>
> So, for newer CSS stylesheets, we could add this:
>
>     @features {
>         one-line-comments;
>     }
>
> to top of CSS file to be able to use one-line comments in rest part of CSS file. Existing stylesheets does _not_ contain such declaration, so they are _not_ affected at all, and therefore there is _no_ any backward-compatibility issues.
>
> Each of feature keywords like `one-line-comments` to use in `@features` rule would be listed and described in CSS spec.
>
> `@features` is somewhat like `@supports` [2], but is not limited to properties and values and does not require to wrap all related code.
>
> [1] http://lists.w3.org/Archives/Public/www-style/2012Aug/0622.html
> [2] http://dev.w3.org/csswg/css3-conditional/#at-supports

"Big red switches" like this are an anti-pattern.  Occasionally they
can be useful, but they're hazardous and should be avoided if
possible.

Some of the hazards:

1. They have to appear at the top of the stylesheet, as this might
require a parser restart and should happen as soon as possible.  This
is an editting hazard - you already must put @charset rules at the top
of a stylesheet, and in fact @charset must occur *before* @features.
2. Because they have to be at the top of a stylesheet, naive
optimizers that simply concatenate CSS files together will produce
broken files.
3. Because they have to apply to an entire stylesheet, even a smart
optimizer is hazardous - you can't just move them all to the top of
the merged sheet, because some of the sheets might not want the
feature, and may break if it was specified.

(These hazards are all true of @charset as well, but no one should be
using @charset - just serve your stylesheet as utf-8 and everything's
fine.  Serving in a different charset doesn't offer any benefit,
unlike @features.)

It's much better to design the language such that new features fit
into the existing language cleanly.  This sometimes requires
additional effort, and occasionally shuts out certain features
entirely, but that's the price you pay.

~TJ

Received on Monday, 27 August 2012 23:28:25 UTC