- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Aug 2024 16:49:42 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/14-css-minutes.html fantasai<br> <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<br> <keithamus> ... should :not match everything but the host by default?<br> <keithamus> ... not should, by default, not match the host element by default. Just like .foo wouldn't match, not(.foo) wouldn't.<br> <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<br> <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.<br> <keithamus> ... if this sounds reasonable I can write the edits<br> <emilio> q+<br> <astearns> ack emilio<br> <keithamus> ... I believe that brings all logical combinator pseudos into a reasonable state wrt the host eleemnt<br> <keithamus> emilio: the only selector that would matter would be :not(:host)? Other stuff would never match effectively?<br> <keithamus> TabAtkins: I believe so<br> <keithamus> emilio: can we make this simpler and say it never matches? Given :host is featureless<br> <keithamus> ... is there a use case for :not(:host)?<br> <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...<br> <keithamus> ... example:<br> <TabAtkins> if :has(.foo) doesn't match the host (but is allowed to), the :not(:has(.foo)) would match the host<br> <keithamus> emilio: do you really want :not(:has(.foo)) to really match?<br> <keithamus> TabAtkins: that's the next issue<br> <keithamus> emilio: I thought the next issue was :host(:has work<br> <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<br> <keithamus> TabAtkins: that's the next issue<br> <keithamus> astearns: Could we move forward with the complicated bits and drop them if we dont need them?<br> <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.<br> <keithamus> ... that's the underpinning I want to resolve on<br> <TabAtkins> s/match all elements/match all those potential elements/<br> <keithamus> PROPOSED RESOLUTION: edit in what's described in Tabs last comment<br> <keithamus> RESOLVED: edit in what's described in Tabs last comment<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10179#issuecomment-2289301689 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 14 August 2024 16:49:43 UTC