Re: [csswg-drafts] [css-cascade] [css-nesting] Figure out whether we're fine with "shifting up" bare declarations after rules (#8738)

> Could you please elaborate on that? Not sure I follow what you mean by "a rule has been parsed trigger".

Yeah, I've elaborated on this in the past when Emilio suggested disallowing properties after rules.

So, this is a parsing switch. In theory parsing switches are doable; we explored a few of these earlier when working thru Nesting options. But the switch needs to be reliable - the earlier discussion about `@nest;` being the switch worked, because we know exactly what to look for and don't expect that to change in the future.

But if the parsing switch is "a rule of some kind is seen", that's hard. The most obvious interpretation of that is "a *valid* rule of some kind is seen" - that's well-defined, but it means that authors can see unexpected differences in parsing behavior if the rule in question is supported in some browsers but not others, as older browsers will throw out the rule and continue allowing declarations, while newer browsers will see it and disallow declarations. (And consider: an invalid *selector* makes the style rule invalid, and we do new selectors all the time.)

So ideally we define invalid rules as also triggering this. But then we open up the full syntax space of what an "invalid rule" actually *is*. Is `foo bar:baz {...};` an invalid rule? Or is it a new property syntax? We can define something for this, but it means restricting our future evolution capabilities, to a larger extent than what we've already done for Nesting.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8738#issuecomment-1747640413 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 21:05:51 UTC