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

(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."

> 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).

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.


> == non-technical feedback ==
> 
> 1. Fundamentally, I don't see a value of the "parse error" idea. It's
> not like this error class has been stable throughout the history of CSS.
> (e.g. "({})" went from an valid input to an "any"[1]), and css3-syntax
> seems to want to change this again (the parts marked * above).

s/valid/invalid/

Some more:

3. The name "Next-statement error mode" is confusing as the thing being
drop is a declaration.

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.

5. In "3.5.7. Declaration mode",

  # ... of the current input token Switch to the ...

is missing a "." in the middle.

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.

7. If some of the deviations to CSS 2.1 are intentional (like the
tokenization section), can these differences be documented as a list?


Cheers,
Kenny

Received on Saturday, 9 June 2012 06:46:19 UTC