- From: vmpstr via GitHub <sysbot+gh@w3.org>
- Date: Tue, 06 Feb 2024 15:44:21 +0000
- To: public-css-archive@w3.org
Discussed this internally and could not reach a clear consensus. In the spirit of "arguing for the other side", I found the following arguments in support of parameter directly affecting specificity of the selector: From https://drafts.csswg.org/selectors/#matches-pseudo > NOTE: The specificity of the [:is()](https://drafts.csswg.org/selectors/#matches-pseudo) pseudo-class is replaced by the specificity of its most specific argument. Thus, a selector written with :is() does not necessarily have equivalent specificity to the equivalent selector written without :is() For example, if we have :is(ul, ol, .list) > [hidden] and ul > [hidden], ol > [hidden], .list > [hidden] a [hidden] child of an [ol](https://html.spec.whatwg.org/multipage/grouping-content.html#the-ol-element) matches the first selector with a specificity of (0,2,0) whereas it matches the second selector with a specificity of (0,1,1). See [§ 17 Calculating a selector’s specificity](https://drafts.csswg.org/selectors/#specificity-rules). From: https://drafts.csswg.org/css-scoping/#host-selector > The [specificity](https://drafts.csswg.org/selectors-4/#specificity) of [:host](https://drafts.csswg.org/css-scoping/#selectordef-host) is that of a pseudo-class. The specificity of [:host()](https://drafts.csswg.org/css-scoping/#selectordef-host-function) is that of a pseudo-class, plus the specificity of its argument. > NOTE: This is different from the specificity of similar pseudo-classes, like [:is()](https://drafts.csswg.org/selectors-4/#matches-pseudo) or [:not()](https://drafts.csswg.org/selectors-4/#negation-pseudo), which only take the specificity of their argument. This is because [:host](https://drafts.csswg.org/css-scoping/#selectordef-host) is affirmatively selecting an element all by itself, like a "normal" pseudo-class; it takes a selector argument for syntactic reasons (we can’t say that :host.foo matches but .foo doesn’t), but is otherwise identical to just using :host followed by a selector. From https://drafts.csswg.org/css-scoping/#slotted-pseudo > The [specificity](https://drafts.csswg.org/selectors-4/#specificity) of [::slotted()](https://drafts.csswg.org/css-scoping/#selectordef-slotted) is that of a pseudo-element, plus the specificity of its argument. From https://drafts.csswg.org/selectors/#nth-child-pseudo > NOTE: The specificity of the [:nth-child()](https://drafts.csswg.org/selectors/#nth-child-pseudo) pseudo-class is the specificity of a single pseudo-class plus, if S is specified, the specificity of the most specific [complex selector](https://drafts.csswg.org/selectors/#complex) in S. See [§ 17 Calculating a selector’s specificity](https://drafts.csswg.org/selectors/#specificity-rules). Thus S:nth-child(An+B) and :nth-child(An+B of S) have the exact same specificity, although they do differ in behavior (see example below). However, specificity of `::part` seems to be 0, regardless of the argument? (I couldn't find anything on `::part`'s specificity, other than what Chromium implements) More importantly there is no prior attempts at the tie-breaker specificity, whether or not it may make sense for some of the selectors above. One thing to note is that most of these selectors above are "structural" in that their arguments make sense outside of the argument as well. For example, the parameter in `:has(#foo)`, namely `#foo` has a meaning as a selector on its own. For `::view-transition-*` elements, the parameter is a property copied from the source element, either `view-transition-name` or `view-transition-class`, which on their own are not valid selectors and thus don't have a specificity. We're giving a specificity to them to mean "id" and "class" since that's how they are meant to be used. This is likely a minor point. -- GitHub Notification of comment by vmpstr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9887#issuecomment-1930083575 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 6 February 2024 15:44:23 UTC