(btw, I'm going through all this feedback in order, so don't worry if
you've responded to me about earlier stuff and I haven't gotten to it
yet.)
On Fri, Jun 8, 2012 at 11:45 PM, Kang-Hao (Kenny) Lu
<kennyluck@csail.mit.edu> wrote:
> (12/06/09 12:01), Kang-Hao (Kenny) Lu wrote:
>> (12/06/09 9:06), Tab Atkins Jr. wrote:
>>> Please critique and tell me about any errors you find.
>> 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."
Yes, thanks. Fixed.
>> 4. In "3.5.13. Consume a block"
>>
>> # whitespace token
>> #
>> # Do nothing.
>>
>> If you do this, UA can't tell if "calc(1+1)" is different from
>> "calc(1 + 1)", while the former is non-conforming. (Even if we end up
>> allowing optional spaces in calc(), there's still "attr(ns|name)").
>
> Also, in general the new spec asserts that whitespace isn't significant
> in At-rule mode and Declaration-value. CSS 2.1 didn't have this
> restriction and I am not sure we want to unnecessarily limit our future
> (like how the CSS 2.1 Core Grammar did to css-hierarchy and the
> $foo-on-the-left-of-':' idea).
Yup, changed now so that whitespace tokens are preserved.
> Some more:
>
> 8. In "3.5.7" Declaration mode",
>
> | semicolon token
> |
> | Do nothing. Remain in this mode.
>
> 9*. According to CSS 2.1, in "3.5.13. Consume a block",
>
> # semicolon token
> # cdo token
> # cdc token
> # at-keyword token
> #
> # This is a parse error. Set the error flag to true.
>
> . For a [] or {} pair, these four does not trigger a "parse error" as
> they belong to "unused". The ';' token and an at-keyword does not
> trigger a "parse error" according to the grammar of 'block' in CSS 2.1.
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.
Don't attach much meaning to the Syntax "parse error" either. It's
just an indicator that validators can flag this as an error for
authors. It has no effect on the actual parsing.
> 3. The name "Next-statement error mode" is confusing as the thing being
> drop is a declaration.
Good point. Changed.
> 4. In Next-statement error mode, Declaration-value mode and
> After-declaration-name mode, there's no point adding an unnecessary
> abstraction: "Switch to the current rule's content mode.". Simply saying
> "Switch to the Declaration mode" would make it a lot easier and
> enjoyable to follow the state machine.
Changed.
> 5. In "3.5.7. Declaration mode",
>
> # ... of the current input token Switch to the ...
>
> is missing a "." in the middle.
Fixed.
> 6. In Style-rule mode and likely At-rule mode,
>
> # open-bracket token
> # open-brace token
> #
> # Otherwise, this is a parse error...
>
> The "Consume a block" algorithm already declares a parse error so this
> doesn't need to be said again. There's no harm saying this twice, though.
No need to be extra wordy when it's already been stated elsewhere.
I've removed the mentions in the normal modes and left the one in the
"consume a block" algo.
> 7. If some of the deviations to CSS 2.1 are intentional (like the
> tokenization section), can these differences be documented as a list?
Yes, I need to do this before I forget them. :/
~TJ