- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 25 Sep 2012 16:08:29 -0700
- To: Simon Sapin <simon.sapin@kozea.fr>
- Cc: www-style@w3.org
On Tue, Sep 25, 2012 at 12:10 AM, Simon Sapin <simon.sapin@kozea.fr> wrote:
> Le 25/09/2012 03:41, Tab Atkins Jr. a écrit :
>> Issue 3, forward compatible parsing of @supports. We believe the
>> forward-compatible parsing is sufficient here. Testing selectors and
>> whatnot can be easily done in a way that is invalid per the current
>> grammar.
>
> The current parsing ignores the whole at-rule if it does not match the
> grammar. For example:
>
> @supports (color: black) or selector(a! b) {}
>
> I *think* that issue 3 suggests alternative parsing rules where only the
> invalid part evaluates to "not supported". With such rules the above would
> still evaluate to "supported".
>
> "The invalid part" is not obvious to define (you need error recovery in the
> parsing) but these rules could be more forward-compatible. Or is this
> precisely what you think is not necessary?
That's a reasonable point, I suppose. We could make a tiny tweak to
the syntax and change supports_declaration_condition to:
supports_declaration_condition
: '(' S* core_declaration ')' S* | FUNCTION S* [any|unused]* ')' S*
;
Then make it like MQ, and have unrecognized functions evaluate as
false. We'd probably also want negations of unknown functions to
evaluate as false. Basically, only an "or" should be able to
whitewash away the unrecognized-ness.
~TJ
Received on Tuesday, 25 September 2012 23:09:16 UTC