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

(12/06/09 9:06), Tab Atkins Jr. wrote:
> Please critique and tell me about any errors you find.

== technical feedback ==

1. In "3.5.4 At-rule mode"

  # open-bracket token
  # open-brace token
  #
  # Consume a block with..

I think you meant to say open-paren here.

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.

3. You seem to assume that bad-url doesn't open a "block". CSS 2.1 is a
bit vague on this (it doesn't say a bad-url contributes to a unbalanced
'(' or not), but since at least IE and Firefox implement this, this
should be marked as an issue.

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

5. In "3.5.11. Next-statement error mode", the '}' token should do the
same thing as it does in Declaration-value mode.

6*. According to CSS 2.1, the ';' token triggers a "parse error" in the
Top-level mode, Style-rule mode, Declaration-value mode if it is the
first token.

7*. According to CSS 2.1, the '}' token triggers a "parse error" if it
is the first token in the Declaration-value mode

== 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). Also,
it'll be very limited in terms of its usefulness since parsing of
specific parts like the selector would have a stricter syntax.

If we really want to do this, we'll need to say something similar to the
HTML spec like

  [[
  user agents must either act as described below when encountering such
problems, or must abort processing at the first error that they
encounter for which they do not wish to apply the rules described below".
  ]]

But we all want browsers to act as what's described in the state
machine, so I think we should avoid the unnecessary "or"s.

If we choose to drop the "parse error", a lot of of branches in the
state machine can just merge into "anything else" and make some parts a
lot readable.

[1] http://lists.w3.org/Archives/Public/www-style/2010Aug/0435

2. Instead of describing open-* (or close-*) token, it might be more
readable just to use the character literally like '(', '{' and so on.
Also, it might be more readable to fold, say, open-* in three lines in
to a single line: '(', '{', '['.

Note that I use "might" here and I am not sure.

> I'm also interested in feedback about Issue 4, regarding how to
> specify the parser around at-rule block bodies.  What's the most
> useful way for me to specify that section, for someone implementing a
> CSS parser?

I think in general at-rule-block parsing would just be Top-level parsing
with a special flag that says '}' ends the Top-level mode. It's likely
to be what's going on with a non-machine generated parer (similary,
@style value parsing will be "Declaration mode" parsing *without* such a
mode).


I might have more comments when "At-rule-block" is complete.


Cheers,
Kenny

Received on Saturday, 9 June 2012 04:02:30 UTC