- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Wed, 21 Dec 2022 19:29:51 +0000
- To: public-css-archive@w3.org
> As an example, if this were implemented first, we could never have added custom properties with the current syntax (which redefined identifiers). This isn't accurate. We couldn't have *naively* redefined identifiers; we'd have had to do some compat analysis to check if it would actually cause a problem or not. (And we'd have found it was perfectly okay, since `--foo` wouldn't be the start of any valid selector anyway, so usage would be minimal.) The hard restriction we have is that we can't introduce new property syntax that *looks like a (relative) selector*. So nothing that puts any of `>+~.:#[` at the start, for example. (`.:#` could be used if followed by whitespace or some other non-ident, tho.) (Unless we end up solving the perf problems with the unbounded lookahead. Then we can potentially do a lot more so long as they're eventually distinguishable, tho we'd likely still want to be careful about mixing things too hard.) > Alternatively, we could limit selector combinators to the current set This won't help, as descendant combinators mean the nested selector can start with any of the simple selector glyphs (`.:#[`). We'd also have to restrict our ability to add new simple selectors, not just combinators. ----- "Mandatory `@nest`" was rejected by the group already, and verbosity wasn't the sole concern about it; copy/paste ability is still affected even if you reduce the required prefix to a single character. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1361994083 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 21 December 2022 19:29:53 UTC