Re: [csswg-drafts] [css-syntax] Dashed-ident rules and error recovery (#9336)

The CSS Working Group just discussed `[css-syntax] Dashed-ident rules and error recovery`, and agreed to the following:

* `ACTION: TabAtkins to look into using a more generic term than 'nested' for the flag for mixed declaration+rule contexts`
* `RESOLVED: at top level, if you see a rule that looks like a custom property, we consume as a rule and throw it away as invalid`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> scribe+ TabAtkins<br>
&lt;fantasai> TabAtkins: We resolved the fundamental grammar ambiguity between properties and declarations in nesting by deciding we would start by parsing as a declaration, and if it was invalid, go backand parse as a rule<br>
&lt;fantasai> TabAtkins: recently tweaked to make more efficient<br>
&lt;fantasai> TabAtkins: works pretty fine, but a wrinkle about custom properties<br>
&lt;fantasai> TabAtkins: custom properties are very hard to make invalid<br>
&lt;fantasai> TabAtkins: anything you write in a custom property will always be valid<br>
&lt;fantasai> TabAtkins: so if you write --foo: [anything] that's a valid custom property<br>
&lt;fantasai> TabAtkins: in order to avoid a behavior change for authors<br>
&lt;fantasai> TabAtkins: if it looks like custom property, we treat it as a custom property during rule parsing<br>
&lt;fantasai> TabAtkins: if you have 'display:hover', can quickly tell it's not a valid display<br>
&lt;fantasai> TabAtkins: issue is that I didn't condition that check on being in a nested context<br>
&lt;fantasai> TabAtkins: so as written, if you have a top-level style rule starting with --foo:whatever, it will try to consume a custom property declaration<br>
&lt;fantasai> TabAtkins: it will eat everything up to the next top-level semicolon<br>
&lt;fantasai> TabAtkins: lose the rest of the stylesheet from that point forward<br>
&lt;fantasai> TabAtkins: I didn't think about this case, so proposal is to condition that check for "does this look like a custom property" to check whether in a nested context or not<br>
&lt;fantasai> TabAtkins: if not nested context, we let it parse as a rule<br>
&lt;fantasai> TabAtkins: but will do rule-parsing and end at next curly brace<br>
&lt;fantasai> TabAtkins: this means that behavior-wise, this brings us back to how this case would have acted before my recent change to allow nesting to work<br>
&lt;fantasai> TabAtkins: i.e. if you write a style rule --foo:whatever, it will only eat one style rule<br>
&lt;fantasai> TabAtkins: I've checked this with Emilio during TPAC<br>
&lt;astearns> q+<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: so what this means is that parsing behavior for style rules with a custom ident is different in top level vs nested<br>
&lt;TabAtkins> fantasai: so if we have custom idents at beginnign of selector, will we be int rouble?<br>
&lt;fantasai> TabAtkins: In both cases, if you try to write a rule with --foo:something, you would end up with something invalid<br>
&lt;fantasai> TabAtkins: if it wasn't a valid custom property, you won't get a rule<br>
&lt;fantasai> TabAtkins: The difference in parsing behavior is, if it's nested it'll consume as a declaration<br>
&lt;fantasai> TabAtkins: whereas at top level it'll consume as a rule<br>
&lt;fantasai> TabAtkins: in both cases, can't be a rule<br>
&lt;fantasai> TabAtkins: we took as an implicit restriction on ourselves that if you have a style rule that wants to start with a dashed type selector, you have to spell it differently e.g. wrap in :is()<br>
&lt;fantasai> TabAtkins: considered that to be fine because that's not a valid custom element name in HTML or XML (I think?)<br>
&lt;fantasai> TabAtkins: very difficult to have a type selector that looks like that, can work around<br>
&lt;fantasai> TabAtkins: error recovery is different in both cases, but either way the rule is invalid and won't work<br>
&lt;fantasai> TabAtkins: and I think that's enough consistency<br>
&lt;fantasai> ok, sgtm<br>
&lt;fantasai> astearns: My qeustion is, defining it as working normally in nested context vs defining it as doing different thing in top-level<br>
&lt;fantasai> astearns: would that be exactly the same? I'm worried nested context are about CSS nesting, not a regular declaration block...<br>
&lt;fantasai> TabAtkins: the switch used in Syntax is "is it mixed with declarations"<br>
&lt;fantasai> astearns: ok, and nested context is that type of context<br>
&lt;fantasai> TabAtkins: yeah<br>
&lt;fantasai> TabAtkins: flag is called "nested" but in practice used for mixed cases<br>
&lt;fantasai> astearns: might want a different term<br>
&lt;fantasai> TabAtkins: I'll look into it<br>
&lt;fantasai> ACTION: TabAtkins to look into using a more generic term than 'nested' for the flag for mixed declaration+rule contexts<br>
&lt;fantasai> TabAtkins: Proposal is, at top level, if you see a rule that looks like a custom property, we consume as a rule and throw it away as invalid<br>
&lt;fantasai> RESOLVED: at top level, if you see a rule that looks like a custom property, we consume as a rule and throw it away as invalid<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9336#issuecomment-1747773800 using your GitHub account


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

Received on Wednesday, 4 October 2023 23:16:12 UTC