[selectors] Should :not(foo) match the host of the shadow tree? #10179

emilio · 2024-04-05T13:12:40Z

#9509 clarified that stuff like :is(:host) should definitely match, due to text in https://drafts.csswg.org/selectors/#data-model:

A featureless element does not match any selector at all, except those it is explicitly defined to match (and logical combination pseudo-classes representing those selectors).

So after discussing a bit with @sesse, it wasn't super-clear to me what the expected behavior is for something like this:

<!doctype html>
<div id="host" style="color: blue">
  <template shadowrootmode="open">
    <style>:not(span) { color: green !important }</style>
    What color is this text?
  </template>
</div>

I could see arguments for both behaviors:

On one hand, it feels very unexpected that something that doesn't contain a :host selector at all to match that host.
But on the other hand, it feels weird that neither span nor :not(span) match.

My read of the spec is that :not(span) should not match, because that selector is not "a logical combination pseudo-class representing those selectors [:host for simplicity]".

I think that's my preferred behavior too, because that makes it simpler to determine "can this selector match the host" (we optimize stylesheets in shadow trees to not match a lot of the rules from the host). But ultimately I could go either way I guess.

My read of the spec doesn't match @sesse, and it seems at least the spec could get a clarification of what that "representing those selectors" means. Maybe "containing those selectors", if my read is correct, or just removing that text, if @sesse's is?

cc @tabatkins @rniwa

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

lilles · 2024-04-05T13:56:20Z

An author reason for not matching the host with :not(foo):

Say I want to style <img> elements in the shadow tree that's not wrapped in some .foo:

:not(.foo) img { ... }

If :not(.foo) matches the shadow host, that selector would always match all img elements.

I would instead have to write:

:host :not(.foo) img { ... }

or add some other selector outside :not() that I knew matched the element on which I set .foo.

emilio · 2024-04-05T14:12:14Z

Yeah that's a really good point.

LeaVerou · 2024-04-09T03:02:54Z

I think it’s important to preserve the expectation that foo, :not(foo) = *.

The img example could easily be img:not(foo *)

emilio · 2024-04-09T06:31:34Z

Well, * wouldn't match the host.

Loirooriol · 2024-04-09T12:04:26Z

Consider :not(:not(:host)). I think it would be very unexpected for :not(:host) to match the host. Thus for both :not(:not(:host)) and :not(.foo) the argument is something that doesn't match the host, so the behavior should be consistent.

Logically it can be a bit strange if :host matches but :not(:not(:host)) doesn't?

I think the possibilities are:

:not() matches the host if none of its arguments matches the host.
:not() never matches the host.

Selector	Option 1	Option 2
`:not(:host)`	❌	❌
`:not(:not(:host))`	✅	❌
`:not(.foo)`	✅	❌
`:not(:host, .foo)`	❌	❌
`:not(:host.foo)`	✅	❌
`:not(:not(:host), .foo)`	✅	❌
`:not(:not(:host)):not(.foo)`	✅	❌
`:host:not(.foo)`	✅	❌

emilio · 2024-04-09T12:25:53Z

I think there might be a third option which even though it's a bit weird would be an improvement on (1) if we go that route, which is conditioning matching it on the selector having a :host selector in some way (which was my read of the spec). Depending on how we define that, it could make :not(:not(:host)):not(.foo) not match, but it'd also make :not(.foo) not match, which is IMO the preferred behavior (both for performance and for matching author expectations).

sesse · 2024-04-09T12:33:34Z

This has some pitfalls, though: The mere presence of :host would influence the rest of the selector. We probably don't want this situation:

:not(.foo): false (no :host in selector, so not considered for match)
:not(:host): false (:host in selector, so considered for match, but the selector itself does not match)
:is(:not(.foo), :not(:host)): true!

Not to mention the forward-compat issues we had with nesting, where people were worried about what would happen if something unknown to the browser (from a future spec) was nest-containing. You have a similar problem here with “host-containing”.

TBH I'm not too worried about performance here; it's just one more element to match in a potentially very long chain, and if you want to optimize that out by checking for :host, you can just as easily drop the optimization if there's a :not in there (which is fairly rare).

emilio · 2024-04-09T12:54:15Z

:is(:not(.foo), :not(:host)): true!

Not necessarily, right? The :not(.foo) wouldn't match (again, depending on how we define this), because it doesn't contain :host, and thus the whole thing would be false?

Loirooriol · 2024-05-02T23:07:51Z

So if I understand correctly, your proposal would be that a selector needs to fall into one of these cases:

It's not allowed to match the host
It's allowed to match the host, but doesn't match it
It matches the host

Then, for simple selectors:

:host matches the host
:is() / :where() matches the host if some of its arguments matches the host, otherwise it's allowed to match the host but doesn't match it if some of its arguments is allowed to match the host but doesn't match it, otherwise it's not allowed to match the host.
:not() is allowed to match the host but doesn't match it if some of its arguments matches the host, otherwise it matches the host if some of its arguments is allowed to match the host but doesn't match it, otherwise it's not allowed to match the host.
Other simple selectors aren't allowed to match the host.

For selector lists: same as :is() / :where().

I'm less sure about compound and complex selectors:

Should :not(.foo:host) match even though :not(.foo), :not(:host) doesn't?
Should :not(:host > .foo) match even though :root.foo, :not(:host) > .foo, :host > :not(.foo) doesn't?

tabatkins · 2024-05-03T23:05:51Z

Whoops, sorry for missing this!

For the general behavior, @lilles got it exactly right - the point of featurless-ness is to make it so that authors don't have to think about the host elements most of the time and will still get the likely intended behavior, so :not(.foo) should not match a host element, for the same reason * doesn't.

(In other words, Lea's request that X, :not(X) be equivalent to * is still preserved, since in both cases the host element isn't matched so long as X isn't :host.)

For the more complex cases, I hadn't actually thought thru those cases when writing up the feature, but I think @Loirooriol's breakdown works well.

For the more complex :not() cases, I think we might want to add the following:

Compound selectors are allowed to match the host only if all the contained simple selectors are allowed to match the host.
Complex selectors are allowed to match the host only if the subject compound selector is allowed to match the host. (So in :host > .foo, the first compound selector is allowed to match the host (and does), but the complex selector as a whole isn't allowed to match the host.)

This would make both of the complex :not() cases "not allowed to match the host".

css-meeting-bot · 2024-08-14T16:49:40Z

The CSS Working Group just discussed [selectors] Should :not(foo) match the host of the shadow tree?, and agreed to the following:

RESOLVED: edit in what's described in Tabs last comment

The full IRC log of that discussion

<RRSAgent> I have made the request to generate https://www.w3.org/2024/08/14-css-minutes.html fantasai
<keithamus> TabAtkins: a q raised: what the `:not` pseudo class means wrt the `:host` element. The point of it being featureless is to avoid having to defensively think about what the outer page is doing with the host element
<keithamus> ... should :not match everything but the host by default?
<keithamus> ... not should, by default, not match the host element by default. Just like .foo wouldn't match, not(.foo) wouldn't.
<keithamus> ... if you explicitly mention the host in the :not, you're explicitly opting in, so there could be a small set of rules for :not matching, compound selectors matching, complex selectors are allowed to match only if the subject compound is allowed to match
<keithamus> ... this captures the notion of if the :not selector is caring about the host element. If so it is allowed to match otherwise it ignores like everything else.
<keithamus> ... if this sounds reasonable I can write the edits
<emilio> q+
<astearns> ack emilio
<keithamus> ... I believe that brings all logical combinator pseudos into a reasonable state wrt the host eleemnt
<keithamus> emilio: the only selector that would matter would be :not(:host)? Other stuff would never match effectively?
<keithamus> TabAtkins: I believe so
<keithamus> emilio: can we make this simpler and say it never matches? Given :host is featureless
<keithamus> ... is there a use case for :not(:host)?
<keithamus> TabAtkins: there are other things that could do that. Also :has(). You could potentially match a host element without :host, and if you :not that, you could potentially match the host...
<keithamus> ... example:
<TabAtkins> if :has(.foo) doesn't match the host (but is allowed to), the :not(:has(.foo)) would match the host
<keithamus> emilio: do you really want :not(:has(.foo)) to really match?
<keithamus> TabAtkins: that's the next issue
<keithamus> emilio: I thought the next issue was :host(:has work
<keithamus> emilio: I think I see, it's very weird. In general I dont think you can match the host with something which doesn't contain :host
<keithamus> TabAtkins: that's the next issue
<keithamus> astearns: Could we move forward with the complicated bits and drop them if we dont need them?
<keithamus> TabAtkins: a selector X that's potentially able to match a set of elements, X and :not(X) should match all elements, which may or may not include the host.
<keithamus> ... that's the underpinning I want to resolve on
<TabAtkins> s/match all elements/match all those potential elements/
<keithamus> PROPOSED RESOLUTION: edit in what's described in Tabs last comment
<keithamus> RESOLVED: edit in what's described in Tabs last comment

…s elements, and the WG-approved rule for matching :has(). #10179 #10693

emilio added selectors-4 Current Work Agenda+ labels Apr 5, 2024

astearns added this to CSSWG June 2024 meeting Jun 3, 2024

astearns moved this to Unsorted in CSSWG June 2024 meeting Jun 3, 2024

Loirooriol mentioned this issue Aug 6, 2024

[selectors][css-scoping] Should :host:has() match? #10693

Closed

css-meeting-bot removed the Agenda+ label Aug 14, 2024

chromium-helper mentioned this issue Aug 14, 2024

[selectors] Should :not(foo) match the host of the shadow tree? chromium-helper/csswg-resolutions#525

Closed

mozilla-apprentice mentioned this issue Aug 14, 2024

[selectors] Should :not(foo) match the host of the shadow tree? mozilla/wg-decisions#1591

Open

tabatkins added the Needs Edits label Aug 14, 2024

tabatkins added a commit that referenced this issue Aug 22, 2024

[selectors-4] Edit in the more complete rules for matching featureles…

028aed6

…s elements, and the WG-approved rule for matching :has(). #10179 #10693

tabatkins added Closed Accepted by CSSWG Resolution and removed Needs Edits labels Aug 22, 2024

tabatkins closed this as completed Aug 22, 2024

tabatkins mentioned this issue Aug 22, 2024

Test all the assertions about featureless elements web-platform-tests/wpt#47746

Merged

tabatkins added the Tested Memory aid - issue has WPT tests label Aug 22, 2024

Loirooriol mentioned this issue Jun 5, 2025

[css-nesting] Make nesting work in :host rules #9496

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[selectors] Should :not(foo) match the host of the shadow tree? #10179

[selectors] Should :not(foo) match the host of the shadow tree? #10179

emilio commented Apr 5, 2024

lilles commented Apr 5, 2024

Uh oh!

emilio commented Apr 5, 2024

Uh oh!

LeaVerou commented Apr 9, 2024 •

edited

Loading

Uh oh!

emilio commented Apr 9, 2024

Uh oh!

Loirooriol commented Apr 9, 2024

Uh oh!

emilio commented Apr 9, 2024

Uh oh!

sesse commented Apr 9, 2024

Uh oh!

emilio commented Apr 9, 2024 •

edited

Loading

Uh oh!

Loirooriol commented May 2, 2024

Uh oh!

tabatkins commented May 3, 2024

Uh oh!

css-meeting-bot commented Aug 14, 2024

Uh oh!

[selectors] Should :not(foo) match the host of the shadow tree? #10179

[selectors] Should :not(foo) match the host of the shadow tree? #10179

Comments

emilio commented Apr 5, 2024

lilles commented Apr 5, 2024

Uh oh!

emilio commented Apr 5, 2024

Uh oh!

LeaVerou commented Apr 9, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

emilio commented Apr 9, 2024

Uh oh!

Loirooriol commented Apr 9, 2024

Uh oh!

emilio commented Apr 9, 2024

Uh oh!

sesse commented Apr 9, 2024

Uh oh!

emilio commented Apr 9, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Loirooriol commented May 2, 2024

Uh oh!

tabatkins commented May 3, 2024

Uh oh!

css-meeting-bot commented Aug 14, 2024

Uh oh!

LeaVerou commented Apr 9, 2024 •

edited

Loading

emilio commented Apr 9, 2024 •

edited

Loading