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

(12/06/13 8:57), Tab Atkins Jr. wrote:
>>  * DASHMATCH and INCLUDES are gone.
>>  * BAD_URI is changed to be self-contained (including the ')').
> 
> I've started a list with these.  Given that several of the changes you
> noticed were accidental, the list is definitely necessary. ^_^

Great!

>>  * a new line following a backslash changed from a DILIM S to just a
>>    DEMIM.
> 
> I'm not sure what this is supposed to mean.  As far as I can tell, a
> backslash followed by a newline emits a DELIM WHITESPACE in Syntax.

Ah, I think I just misread this.

>>>> 7*. According to CSS 2.1, the '}' token triggers a "parse error" if it
>>>> is the first token in the Declaration-value mode
>>>
>>> I'm not sure precisely how to decipher what CSS 2.1 wants us to do in
>>> this case (and with semicolon as first token in declaration-value, but
>>> browsers interoperably just drop the declaration.  It's currently
>>> undetectable whether this is because it's considered an overall
>>> violation of the Core Grammar, or because the empty value doesn't
>>> match any property's grammar.  I'm going with the latter for now,
>>> because it leaves the door open for the empty value for Variables.  I
>>> can change it if anyone feels strongly about it.
>>
>> I only feel strongly that we should document the difference between
>> "Parse Error" and the CSS 2.1 "Core Grammar", so for whoever implements
>> this grammar (e.g. tinycss) this is still trackable. Or otherwise, the
>> simplest thing, as I've been saying, is to drop the "Parse Error"
>> concept at all (and say the difference is that "Core Grammar" is just
>> obsoleted).
> 
> The intention of this is that the Core Grammar is obsoleted.  As I've
> expressed before, the "parse error" concept is solely a hint for
> validators to give feedback to authors, just like in HTML.

Given the above statement and

(12/06/13 2:28), Tab Atkins Jr. wrote:
> Don't pay any attention to the relationship between Syntax parse
> errors and 2.1 parse errors.  The "unused" production in 2.1
> represents a class of things that are parse errors if encountered.  It
> was just an attempt to make the grammar somewhat more complete, so
> there was less undefined behavior.

, can we then point out this at "3. Parsing" with something like

  | The Core Grammar in 2.1 is obsoleted in favor of the parse error
  | concept. They are different (for whatever reasons).

? Or otherwise it's only natural for a person who read CSS 2.1 like me
to find these different and get confused. I think it's pretty obvious
that having two different subclasses of the whole input is just a
confusing thing to do so we should get rid of either.

(12/06/13 8:57), Tab Atkins Jr. wrote:
> On Mon, Jun 11, 2012 at 11:15 PM, Kang-Hao (Kenny) Lu
>> The reality is that browsers don't implement the "Parse Error"
>> thing. It is just going to be quite confusing if a Web Console, when
>> encountering "width: <!--", says "violation of the core grammar in
>> the value of 'width'" instead of just "unrecognized value in
>> 'width'".
>
> It's still perfectly fine for a validator to say that.

I disagree, since especially telling certain tokens like "<!--" apart
from other invalid values is sort of make work, with unclear, if at all,
benefits to a user of a validator. But we can discuss about this later
when we define "Parse Error"s for selectors and values, without which
you can't really build a conformance checker anyway.

As data input, the Web console in Firefox doesn't treat "<!--" any
different from other invalid values, but Jigsaw does.

(12/06/13 7:26), Tab Atkins Jr. wrote:
> 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!

Yeah, I mentioned this as a reason why we should not have the "parse
error" thing, but whatever, as long as it's not confusing it should be fine.

(12/06/13 8:59), Tab Atkins Jr. wrote:
> The CSS2.1 grammar is incomplete and occasionally goes against
> reality, yes, but mostly only in odd corner cases.  The vast majority
> of my work here in Syntax is just recasting the grammar-based approach
> to a state-machine-based one, and fixing the couple of places where it
> doesn't match browser behavior.

I think the correct read of the CSS 2.1 core grammar is just to ignore
it and take more look into the balanced ()[] rules and such. That's why
I anticipated that css3-syntax won't have something like it (the "Parse
Error" thing), but I can live with "Parse Error" if there's a statement
saying that the CSS 2.1 Core Grammar is just obsoleted (see above).


Cheers,
Kenny

Received on Wednesday, 13 June 2012 02:09:26 UTC