Re: [csswg-drafts] [css-nesting-1] Syntax Invites Errors (#7834)

> If viewing it as an error-correction why couldn't it be inserted whenever it encounters a non-literal token? That way it would only require an extraneous & or @nest when the first selector starts with a tag name.

Yeah, I've been thinking thru the parsing implications, and this should be doable. I need to be a little careful, because people today rely on "put some random symbol at the start of your property to 'comment it out'" and that needs to be preserved, but I believe I can handle this very reasonably in the spec.

Currently the [parsing rules for style blocks](https://w3c.github.io/csswg-drafts/css-syntax-3/#consume-a-style-blocks-contents) are (ignoring the ending conditions and the one bit that's for the current Nesting spec):

* if you see an at-keyword, consume an at-rule
* if you see an ident, consume a declaration
* if you see anything else, this is a parse error; throw out everything until you see a semicolon

To accommodate this new bit, I'd instead have:

* Parser starts in "declarations" mode.
* If you see an at-keyword, consume an at-rule. Switch to "rules" mode if not already in it.
* If you see an ident:
 * if you're in "declarations" mode, consume a declaration. If you're in "rules" mode, consume a rule.
* if you see anything else:
 * if you're in "declarations mode", consume an ambiguous rule. If this succeeds, switch to "rules" mode.
 * if you're in "rules" mode, consume a rule.

Then "consume an ambiguous rule" is identical to the existing ["consume a qualified rule"](https://w3c.github.io/csswg-drafts/css-syntax-3/#consume-qualified-rule), except it'll fail early if it encounters a top-level semicolon, raising a parse error and returning nothing.

I believe it's okay in practice to defer a "parse this as X or fail" decision until later in the stream, while "parse this as X or as Y" needs to be know which  with small, finite lookahead (which is why "just do it like Sass" is problematic for our impls).

Note, tho, that this will slightly tie our hands in the future - we'll never be able to change the property syntax to start with a non-ident (like doing additive CSS by writing `+transform: ...` or something). This probably isn't a huge deal, but it is definitely a forwards-compat/language evolution issue to worry about.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7834#issuecomment-1270665794 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 6 October 2022 20:46:30 UTC