Re: [csswg-drafts] [css-nesting] Problem with mixing properties and selectors (#8249)

I'd like to point back to [@fantasai's comment](https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1362033982) about what precisely the syntax constraints we're actually adopting are.

There are two aspects: things that are currently valid, and things that are currently invalid.

For things that are currently valid, we are indeed closing the door on options. With the current spec, we cannot allow a declaration to start with `+`, for example, as that's a valid relative selector. (At least, not without paying a lookahead tax that we're currently rejecting.) We cannot start a selector with an ident. As I've said in previous threads, tho, starting a declaration with a symbol is *already* very likely off the table, given the prevalence of people using a random ascii symbol to "comment out" a property. So in practice we're closing the door on *very little* new space that wasn't already verboten.

For things are the currently invalid, we are in general *not* closing the door on anything. CSS's existing forward compatibility parsing rules give us a *lot* of leeway to reinterpret things, ensuring that "new stuff" (aka invalid stuff in an older browser) gets properly isolated and ignored without screwing up surrounding stuff that *is* recognized in an older browser.

The recovery rules are: 
* if something invalid is being parsed as a declaration, we throw away tokens until the next top-level semicolon.
* if something invalid is being parsed as a nested rule, we throw away tokens until the next top-level semicolon or top-level {}-block.

This suggests that (a) we want to bias toward parsing unknown things as nested rules, since the recovery is stricter/safer, and (b) if an older browser parses some pattern as an (invalid) nested rule, and we decide to make that pattern a declaration instead, this is fine *so long as it doesn't contain a {}-block followed by something that looks like a complete (`prop:val;`) declaration*.

That's the crux. The pattern we are locking ourselves out of is just `%foo: {...} bar: baz;` being parsed as a declaration. That is such a *ridiculously* arcane pattern that I feel completely comfortable stating we'd never explore that space *anyway*, even if it did continue to be an option.

Notably, say in the future we decide that `1: red;` should be a valid declaration. Currently that'll trigger nested-rule parsing, but the semicolon will cause us to stop parsing and throw it out as an invalid construct, then resume parsing fresh afterwards. If we changed the rules so that browsers parsed that as a declaration, then older browsers will... see it as invalid, and throw away tokens until the semicolon, then restart parsing fresh. In other words, we have precisely identical error-recovery *regardless* of how it's categorized in older browsers.

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


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

Received on Wednesday, 11 January 2023 19:08:32 UTC