[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".

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[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

emilio commented Apr 5, 2024

LeaVerou commented Apr 9, 2024 •

edited

Loading

emilio commented Apr 9, 2024

Loirooriol commented Apr 9, 2024

emilio commented Apr 9, 2024

sesse commented Apr 9, 2024

emilio commented Apr 9, 2024 •

edited

Loading

Loirooriol commented May 2, 2024

tabatkins commented May 3, 2024

[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

emilio commented Apr 5, 2024

LeaVerou commented Apr 9, 2024 • edited Loading

emilio commented Apr 9, 2024

Loirooriol commented Apr 9, 2024

emilio commented Apr 9, 2024

sesse commented Apr 9, 2024

emilio commented Apr 9, 2024 • edited Loading

Loirooriol commented May 2, 2024

tabatkins commented May 3, 2024

LeaVerou commented Apr 9, 2024 •

edited

Loading

emilio commented Apr 9, 2024 •

edited

Loading