- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 Oct 2023 18:37:05 +0000
- To: public-css-archive@w3.org
> I don't this this is correct, because specificity commutes ;) Yes, specificity commutes, but that's not particularly relevant in this case. There are 3^4 = 81 possible *ways to be matched*, and we still need to check all of them to know what the highest specificity among the valid matches are. (And the number of unique specificities is still exponential, just somewhat smaller.) So I slightly misspoke; please substitute the correct term when you read my previous post. ^_^ > Far better to say that the specificity is equal to the first one that actually matches, rather than the max specificity in the list! As I keep saying, this is impossible, as it implies doing exponential work. No browser is willing to do that. Excise it from your possibility space; nothing that achieves this will be acceptable. > It depends on whether you see :is() as part of the design of this feature, or as an implementation detail. It's *absolutely* an implementation detail. If we could do the "real" desugaring, we absolutely would; it definitely makes more sense. We just can't. The impossibility of this was well-established in Nesting discussions years ago, and there's no solution to it. > The current behavior has exactly that effect! Fair, but your suggestion has a *significantly larger* effect. Currently, adding a new selector to an existing list only changes the behavior if the new selector has higher specificity; if it's the same or lower, there's no behavior change at all. In your suggestion, `& {...}` would change specificity *regardless* of what was added to it, *and* pseudo-elements in the parent list would suddenly stop matching. That's a pretty big change! And, I think, definitely confusing. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9492#issuecomment-1779840713 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:37:06 UTC