[css-nesting] Specificity of contextually-invalid selectors. #9600

emilio · 2023-11-15T13:28:42Z

Consider something like:

<!doctype html>
<style>
p {
  color: green;
}

*, ::before {
  & * {
    color: red;
  }
}

:is(*, ::before) * {
  color: purple;
}
</style>
<p>Which color is this?

That's red in browsers, quite surprisingly, because ::before, even though is invalid when nested (:is(*, ::before) or so wouldn't parse it), still contributes to specificity. p should win due to specificity otherwise, and the text should be green.

That seems pretty confusing? It's even more confusing when nesting :has() etc. But "fixing" it is actually relatively annoying.

What is the expected result here? What should be the expected result of something like nesting :has() inside :has() which suffers from the same issue?

cc: @dshin-moz, @andruud, @tabatkins, @LeaVerou, @mdubet

The text was updated successfully, but these errors were encountered:

Loirooriol · 2023-11-15T14:06:46Z

This is also exposing the fact that Firefox and WebKit consider the specificity of a pseudo-element to be the same as a type selector, while Blink seems to treat it as a class selector? I believe this might not be observable before CSS nesting.

<!DOCTYPE html>
<style>
p { border: 20px solid }

*, ::before { & { border-left-color: red; }}
p { border-left-color: green; }

p { border-right-color: red; }
*, ::before { & { border-right-color: green; }}

*, ::before { &.p { border-top-color: red; }}
.p.p { border-top-color: green; }

.p.p { border-bottom-color: green; }
*, ::before { &.p { border-bottom-color: red; }}
</style>
<p class="p">Which color is this border?</p>

https://crbug.com/1474144

emilio · 2023-11-15T14:30:16Z

I don't know what Blink is doing, but the specificity of pseudo-elements should be the type selector's, unless I'm reading https://drafts.csswg.org/css2/#specificity wrong:

count the number of element names and pseudo-elements in the selector (= d)

For now, do the same as pseudo-elements, which is effectively to keep them in the replaced selector but don't match them. Avoid crashing in this case. I filed w3c/csswg-drafts#9600 since this issue isn't specific about :has(), and depending on the result of that discussion, the "proper" solution might be different. Differential Revision: https://phabricator.services.mozilla.com/D193663 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1864647 gecko-commit: 69bede2c30ec37c0a9b3b44879e28a5dd1c0b1c5 gecko-reviewers: dshin

…shin For now, do the same as pseudo-elements, which is effectively to keep them in the replaced selector but don't match them. Avoid crashing in this case. I filed w3c/csswg-drafts#9600 since this issue isn't specific about :has(), and depending on the result of that discussion, the "proper" solution might be different. Differential Revision: https://phabricator.services.mozilla.com/D193663

For now, do the same as pseudo-elements, which is effectively to keep them in the replaced selector but don't match them. Avoid crashing in this case. I filed w3c/csswg-drafts#9600 since this issue isn't specific about :has(), and depending on the result of that discussion, the "proper" solution might be different. Differential Revision: https://phabricator.services.mozilla.com/D193663 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1864647 gecko-commit: 69bede2c30ec37c0a9b3b44879e28a5dd1c0b1c5 gecko-reviewers: dshin

…shin For now, do the same as pseudo-elements, which is effectively to keep them in the replaced selector but don't match them. Avoid crashing in this case. I filed w3c/csswg-drafts#9600 since this issue isn't specific about :has(), and depending on the result of that discussion, the "proper" solution might be different. Differential Revision: https://phabricator.services.mozilla.com/D193663

…shin For now, do the same as pseudo-elements, which is effectively to keep them in the replaced selector but don't match them. Avoid crashing in this case. I filed w3c/csswg-drafts#9600 since this issue isn't specific about :has(), and depending on the result of that discussion, the "proper" solution might be different. Differential Revision: https://phabricator.services.mozilla.com/D193663 UltraBlame original commit: 69bede2c30ec37c0a9b3b44879e28a5dd1c0b1c5

css-meeting-bot · 2024-01-17T17:47:26Z

The CSS Working Group just discussed [css-nesting] Specificity of contextually-invalid selectors., and agreed to the following:

RESOLVED: contextually-invalid selectors have a specificity of zero

The full IRC log of that discussion

<Frances> Alan: next is css-nesting
<matthieud> q+
<Frances> Emilio: About what happens when nesting invalid pseudo-element. Keeps sort of being valid, reuse selector from the outside. Behavioral specificity of nesting doesn't seem defined.
<astearns> ack matthieud
<TabAtkins> I have no opinion on this issue, happy to clarify/edit whatever the group wants.
<Frances> matthieu: Weird that specificity is taken in account. Keep invalid selector, we don't take specificity in account.
<Frances> Emilio: seems fine to me, would make behavior of nesting and not nesting as consistent, makes sense. Part of the way to prevent is by sharing memory, need to make specificity not count.
<Frances> Alan: Defining a behavior shouldn't have too much backwards compatibility risk possibly.
<Frances> Emilio: Right now are consistent in reusing the specificity, other cases like :has(:has)
<Frances> Alan: Any other comments or questions?
<Frances> PROPOSAL: Specify contextually-invalid selectors via nesting
<Frances> Emilio: nesting doesn't have specificity at the moment.
<astearns> PROPOSAL: contextually-invalid selectors have a specificity of zero
<Frances> Matthieu: Specific wording?
<Frances> Emilio: Make it behave the same as the regular selector list
<Frances> RESOLVED: contextually-invalid selectors have a specificity of zero

…ecificity. #9600

…shin For now, do the same as pseudo-elements, which is effectively to keep them in the replaced selector but don't match them. Avoid crashing in this case. I filed w3c/csswg-drafts#9600 since this issue isn't specific about :has(), and depending on the result of that discussion, the "proper" solution might be different. Differential Revision: https://phabricator.services.mozilla.com/D193663

emilio added Agenda+ css-nesting-1 Current Work labels Nov 15, 2023

moz-wptsync-bot mentioned this issue Nov 15, 2023

[Gecko Bug 1864647] Don't crash when finding nested relative selectors. web-platform-tests/wpt#43186

Merged

css-meeting-bot removed the Agenda+ label Jan 17, 2024

chromium-helper mentioned this issue Jan 17, 2024

[css-nesting] Specificity of contextually-invalid selectors. chromium-helper/csswg-resolutions#322

Closed

mozilla-apprentice mentioned this issue Jan 17, 2024

[css-nesting] Specificity of contextually-invalid selectors. mozilla/wg-decisions#1360

Open

tabatkins added a commit that referenced this issue Jan 18, 2024

[selectors] Specify that invalid selectors in :is()/:where() are 0 sp…

47c4244

…ecificity. #9600

tabatkins added the Closed Accepted by CSSWG Resolution label Jan 18, 2024

tabatkins closed this as completed Jan 18, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-nesting] Specificity of contextually-invalid selectors. #9600

[css-nesting] Specificity of contextually-invalid selectors. #9600

emilio commented Nov 15, 2023

Loirooriol commented Nov 15, 2023 •

edited

emilio commented Nov 15, 2023

css-meeting-bot commented Jan 17, 2024

[css-nesting] Specificity of contextually-invalid selectors. #9600

[css-nesting] Specificity of contextually-invalid selectors. #9600

Comments

emilio commented Nov 15, 2023

Loirooriol commented Nov 15, 2023 • edited

emilio commented Nov 15, 2023

css-meeting-bot commented Jan 17, 2024

Loirooriol commented Nov 15, 2023 •

edited