Re: [css3-syntax] First draft of parser section completed

On Sun, Jun 10, 2012 at 4:50 PM, Kang-Hao (Kenny) Lu
<kennyluck@csail.mit.edu> wrote:
> (12/06/09 14:45), Kang-Hao (Kenny) Lu wrote:
>> (12/06/09 12:01), Kang-Hao (Kenny) Lu wrote:
>>> 2. "At-rule-block" is incomplete, so it's hard to say if there's error
>>> relating to at-rule error handling here or not.
>>
>> Mah, on a second read, I think I start to understand this, so...
>>
>> In "3.5.4. At-rule mode"
>>
>>   # close-paren token
>>   # at-keyword token
>>   #
>>   # This is a parse error. Pop the current rule from the stack of open
>>   # rules. Switch to the current rule's content mode.
>>
>> I think the spec probably meant to say "Switch to the
>> next-block-or-statement error mode."
>
> On a second thought, neither of these two matches IE9, Firefox13 and
> Operal12alpha .
>
> Test case:
>
> data:text/html,<style>@media ),screen { body { background: green; }
> }</style>
>
> and the variants using "]", "@ab", "<!--", "-->" in place of ")". WebKit
> browsers don't implement the error handling even for, say, "@media
> a+b,screen" so it's far from conforming anyway.
>
> What will be needed is
>
>  | This is a parse error. Append the current input token to the
>  | prelude of the current rule and remain in this mode.

Hm, okay.  I'm pretty sure I'm reading it correctly as invalid in the
Core Grammar, but if we have interop in just accepting it (and
treating it like an invalid media query), then I'll change to match.
It's undetectable whether or not it's accepted in Selectors (since
they all produce invalid selectors and kill the block, the same as if
they are a parse error), so I'll just allow them there too.

...and yup, just did testing, and you're right.  Every single one of
the tokens that I have listed as a parse error in the at-rule mode are
perfectly valid and just form an invalid media query in every browser
but WebKit.  The only exception is that } seems to close the block in
Firefox (or maybe trigger error-handling).

That eliminates a bunch of parse errors.  In particular, "consume a
block" now always returns a block, which lets me simplify all the call
sites!

> But then, I will wonder why we don't do the same for "style-rule mode"
> and "consume a block". Failing early is going to limit our future. For
> example, we could introduce
>
>  (selector1, selector2) { }
>
> in css4-selectors for media query-like error handling, but if "consume a
> block" fails early when the "unused" things are encountered, it wouldn't
> work like media queries.

Since it's currently undetectable, I've done so.

~TJ

Received on Tuesday, 12 June 2012 23:27:38 UTC