- From: Peter Linss via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Jan 2023 20:29:27 +0000
- To: public-css-archive@w3.org
A problem I have with the "it's only an error recovery problem" approach, is that once something new gets added to selectors or properties, it's closed off forever in use for the other case. For example, if we add `%` as a special prefix for properties, we can never use it as a combinator (or vice versa). And that's not even considering cases we're already closing off, e.g. IIRC there's a proposal for extending list properties like: `+backrgound: green;`, kiss that goodbye before it's even properly considered. I still feel that's too constraining. Paraphrasing as I believe @Loirooriol said elsewhere, we are bending and constraining the language here in ways that are restrictive, and introducing new (and seemingly arbitrary to the non-initiated) rules that authors have to learn and follow, all for the benefit of avoiding a *single* character. (And if we chose a mandatory `&` prefix, it just choosing a *different* character.) I just don't see the benefit being worth the cost. And frankly, I don't think the copy/paste argument has all that much merit. As the proposal stands, authors *cannot* 'simply' copy paste rules into a nested context because they will have to manually scan them for the cases that need fixups, this will be error-prone. Big picture, I don't think we're really helping authors here. If authors have to add a simple prefix, that can be easily automated by tooling. Other solutions that satisfy my concerns that I'm not sure have been properly considered are creating a nested rule context within an existing style rule, e.g.: ```css foo { color: red; @nest { bar { color: blue; } baz { color: green; } } } ``` Which could be simplified to: ```css foo { color: red; @ { bar { color: blue; } baz { color: green; } } } ``` or even: ```css foo { color: red; { bar { color: blue; } baz { color: green; } } } ``` A solution like the above *does* simplify copy/paste and avoids all the syntax rules and extension issues. (It also doesn't preclude allowing `@ bar { ... }` for individual nested rules.) -- GitHub Notification of comment by plinss Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1379447123 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 20:29:29 UTC