- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 Oct 2023 18:13:31 +0000
- To: public-css-archive@w3.org
@tabatkins > As I said, I'd object to treating a rule with a lone & differently; this sort of context-sensitivity is confusing for authors It depends on whether you see `:is()` as part of the design of this feature, or as an implementation detail. If you see it as an implementation wart, the less authors are exposed to it, the better. If you see it as part of the design that you need to teach and explain, then I see your point: it would indeed be confusing for authors iff `:is()` _were_ actually part of their mental model about how nested selectors match. However, right now I guarantee you it is not. Their mental model is that selectors match as if they were rewritten with the combinatorial explosion method. I'd hypothesize that even authors who *do* know that `:is()` is used for the rewrite would *still* not take it into account most of the time. You can easily verify this by asking authors what they'd expect in any situation where the two produce a different outcome. It's just that they don't hit the differences between the two often enough that this becomes a pain point. But at least with preprocessors, they can peek at the output and debug — here this is entirely internal. > and means that seemingly-innocent changes like adding an additional selector to a list can change the meaning of other selectors they didn't touch. The existing behavior has _exactly_ that effect! See https://github.com/w3c/csswg-drafts/issues/9492#issuecomment-1779758880 -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9492#issuecomment-1779804513 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 25 October 2023 18:13:37 UTC