- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Fri, 14 Nov 2025 08:47:07 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Mixing :is() (or equivalent) with pseudo-elements`, and agreed to the following:
* `RESOLVED: Resolve on behavior for nesting, and thinking about non-nesting later`
* `ACTION: Emilio to file issue about specificity`
<details><summary>The full IRC log of that discussion</summary>
<kbabbitt> miriam: I want to see this happen<br>
<kbabbitt> TabAtkins: we've explicitly excluded putting pseudo elements inside :is for a while<br>
<kbabbitt> ... this is for various selector data model reasons<br>
<kbabbitt> ... big one is that :is is a pseudo class which is simple selector, and simple selectors do nothing but filter<br>
<kbabbitt> ... can always take the things matched by a couple of simple selectors, intersect them, and that's what you get when you combine them together<br>
<kbabbitt> ... if we allowed pseudo elements inside :is, that stops being tryue<br>
<kbabbitt> ... you can have .foo which selects all .foo, add :is::before<br>
<kbabbitt> ... and suddenly set of elements is not a subset of .foo<br>
<kbabbitt> ... it's a completely different set, the befores<br>
<kbabbitt> ... and that's weird<br>
<kbabbitt> ... however people want to be able to do that because it's useful<br>
<kbabbitt> ... both directly in :is and indirectly via nesting<br>
<kbabbitt> ... useful to split slector and resolve differently<br>
<kbabbitt> ... so I have a proposal for how to slightly alter the semantics of selectors to make this possible to do<br>
<kbabbitt> ... in :is and in nesting<br>
<kbabbitt> ... so that all of the nesting cases work more naturally<br>
<kbabbitt> ... example that doesn't work well:<br>
<TabAtkins> .foo { ::before, ::after { :hover { color: red; } } }<br>
<kbabbitt> ... that example does not work because, while we let first 2 work okay via special case<br>
<miriam> (I think those all need `&`)<br>
<kbabbitt> ... as soon as you go past that, before and after get shoved into internal :is<br>
<kbabbitt> ... and that makes the innermost nested selector invalid<br>
<TabAtkins> .foo { &::before, &::after { &:hover { color: red; } } }<br>
<kbabbitt> ... doesn't match anything<br>
<kbabbitt> ... so the suggested change is, before you match a complex selector unit<br>
<kbabbitt> ... i.e. compound selector plus pseudo elements<br>
<kbabbitt> ... (thing between combinators)<br>
<kbabbitt> ... we grow the set of matched elements by adding all pseudo elements that are...<br>
<TabAtkins> A > B:is(::before) > C<br>
<emilio> But does that even work? ::before and ::after don't support :hover: data:text/html,<style>:root::before{ content: "foo"; } :root::before:hover { color: red }}</style><br>
<kbabbitt> ... in that example, ignore whether they go left or right, equivalent meaningfully<br>
<kbabbitt> ... start with elements that match A, combinator takes us to children<br>
<kbabbitt> ... now we add to that set all pseudo elements of A children<br>
<kbabbitt> ... then we execute the B:is(::before)<br>
<kbabbitt> ... that will chop down the list of possible elements to things just matching that<br>
<kbabbitt> ... then before we move on, we will remove any pseudos that were not explicitly matched by that selector<br>
<oriol> emilio, ::before:hover is supposed to work per the spec, https://drafts.csswg.org/selectors-4/#pseudo-element-states<br>
<kbabbitt> ... that last step is required because that selector unit might not have had a pseudo in there, could be :hover applying to a bunch of elements<br>
<kbabbitt> ... can't keep those in list for compat reasons<br>
<kbabbitt> ... a number of psuedo classes do work on pseudo elements<br>
<kbabbitt> ... so, this means my nesting example would work<br>
<kbabbitt> ... there are a few limitations<br>
<emilio> q+<br>
<kbabbitt> ... listed in issue<br>
<astearns> q+<br>
<TabAtkins> .foo:is(*, ::before, ::after)<br>
<kbabbitt> ... this selector ^<br>
<kbabbitt> ... worked in the old webkit matches<br>
<kbabbitt> ... would match .foo, .foo::before, .foo::after<br>
<kbabbitt> ... doesn't match in todays world and will continue to not match<br>
<kbabbitt> ... because pseudoes are supposed to be re-orderable<br>
<kbabbitt> astearns: why does that rule invalidate your example?<br>
<emilio> `::before.foo`<br>
<kbabbitt> TabAtkins: there are no ::before pseudos that are also .foo<br>
<lea> q+<br>
<kbabbitt> ... that is not only illegal syntactically but will not match<br>
<kbabbitt> ... will continue to not match<br>
<kbabbitt> emilio: but it matches now?<br>
<kbabbitt> TabAtkins: no<br>
<kbabbitt> ... only matches .foo, not .foo::before or ::after<br>
<kbabbitt> ... that selector is illegal right now<br>
<romain> q+<br>
<kbabbitt> ... won't match what webkit-matches would have matched<br>
<astearns> q-<br>
<lea> q-<br>
<kbabbitt> ... secondly, building on that same thing<br>
<TabAtkins> :hover:is(::before) and :is(::before):hover<br>
<kbabbitt> ... simple selectors in a compound are always reorderable<br>
<kbabbitt> ... these 2 selectors need to be identical<br>
<kbabbitt> ... they are in all cases today and should continue to be<br>
<kbabbitt> ... but that means that these 2 selectors...<br>
<TabAtkins> :hover::before and ::before:hover<br>
<romain> q-<br>
<kbabbitt> ... which are indeed distinct things and select different things, only 1 can be the meaning of those other 2<br>
<kbabbitt> ... my proposal selects one of these<br>
<kbabbitt> ... the latter<br>
<kbabbitt> ... a before which is hovered<br>
<kbabbitt> ... not the before of a hovered element<br>
<ntim> I wouldn't expect :hover:is(::before) and :is(::before):hover to be the same<br>
<kbabbitt> astearns: here we're defining new behavior<br>
<lea> Would that change the meaning of .foo { &:hover { &::before {} } }?<br>
<kbabbitt> emilio: that's channging currint behavior?<br>
<kbabbitt> TabAtkins: no<br>
<lea> `.foo { &:hover { &::before {} } }`<br>
<kbabbitt> ... the 2 I listed without :is do work today, select distinct elements<br>
<kbabbitt> ... but the 2 that use :is are illegal today<br>
<lea> q+<br>
<kbabbitt> ... giving them meaning, both equal to second one<br>
<kbabbitt> ... those are the only places where this I believe gives potentially unintuitive results<br>
<astearns> q+<br>
<lea> Or, if not, would it become illegal once you turned it into `.foo, .bar { &:hover, &:focus { &::before, &::after {} } }`?<br>
<kbabbitt> ... in all other cases this lets pseudos be used in is and gives obvious answers for all these work<br>
<romain> q+<br>
<astearns> ack emilio<br>
<kbabbitt> emilio: I'm not quite fond of this proposal<br>
<miriam> q+<br>
<ntim> +1 to emilio<br>
<kbabbitt> ... it feels like, especially making hover before mean the same as before hover seems super intuitive to me<br>
<kbabbitt> TabAtkins: if you replace :hover with .foo does it make more sense?<br>
<kbabbitt> emilio: no, I don't know why reordering preserves the meaning<br>
<kbabbitt> ... point is you want to preserve that, within a sinple selector, reordering is important<br>
<kbabbitt> ... vs doing intuitive thing which I think would be, hover before selects the before of hovered element, before hover does something different<br>
<kbabbitt> miriam: that argument makes sense until you add :is<br>
<kbabbitt> ... the is makes them the same thing<br>
<kbabbitt> emilio: so when you add ...<br>
<miriam> ::before:is(:hover)<br>
<kbabbitt> oriol: if you have before and hover without is, they'll be different<br>
<miriam> and :hover:is(::before)<br>
<kbabbitt> ... when you add is, reordering them will ?<br>
<kbabbitt> emilio: don't think that makes sense<br>
<kbabbitt> ... hover before should not be different from before hover<br>
<kbabbitt> miriam: I think they should be, 'is' says theyre the same thing<br>
<kbabbitt> ... not the before on the hover, the ...<br>
<kbabbitt> emilio: that doesn't make sense to me<br>
<kbabbitt> ... I get it in that you're using :is<br>
<kbabbitt> ... but that's so confusing<br>
<kbabbitt> ... also not what authors would expect.<br>
<kbabbitt> ... if I have a complex sector, before after, &::before &::after<br>
<kbabbitt> ... behave the same as if<br>
<kbabbitt> miriam: distinction will be if it has the & or not<br>
<oriol> q+<br>
<kbabbitt> emilio: in general, pseudos in my mental model are basically a combinator<br>
<kbabbitt> TabAtkins: correct<br>
<kbabbitt> emilio: which means making this work is annoying<br>
<miriam> q-<br>
<kbabbitt> ... but if you look at it that way, isn't :is ... guess if you do .foo descendant .bar then ... you're not selecting anything hover<br>
<kbabbitt> ... feels really annoying<br>
<kbabbitt> ... wouldn't expect that behavior at all<br>
<astearns> ack lea<br>
<TabAtkins> :hover:is(> .bar) and :is(> .bar):hover<br>
<kbabbitt> lea: was about to say +1<br>
<kbabbitt> ... but this reordering thing is giving me pause<br>
<kbabbitt> ... might have misunderstood, questions in IRC<br>
<lea> 1. `.foo { &:hover { &::before {} } }`<br>
<kbabbitt> ... would that change how it works given it would be composed with is?<br>
<kbabbitt> TabAtkins: no that would work fine<br>
<kbabbitt> lea: you said foo hover is before<br>
<TabAtkins> equivalent to :is(.foo:hover)::before<br>
<kbabbitt> ... would be equivalent to ???<br>
<kbabbitt> ... doesn't that mean it would change?<br>
<kbabbitt> TabAtkins: the stuff higher in nesting list gets wrapped in pretend :is<br>
<kbabbitt> ... if you invert these, that would give different behavior than you might expect<br>
<kbabbitt> ... as written, equivalent to foo hover before<br>
<lea> `.foo { &::before { &:hover {} } }`<br>
<kbabbitt> lea: so if you had this<br>
<kbabbitt> TabAtkins: that would be equivalent to:<br>
<TabAtkins> ::before:is(.foo:hover)<br>
<ntim> s/???/:is(::before):hover<br>
<kbabbitt> ... not that<br>
<TabAtkins> :is(.foo::before):hover<br>
<kbabbitt> ... that<br>
<kbabbitt> lea: so hover is on before itself?<br>
<kbabbitt> TabAtkins: yes<br>
<kbabbitt> lea: same result is same?<br>
<kbabbitt> TabAtkins: no, hover on foo vs hover on before<br>
<kbabbitt> lea: you still have a pseudo in there<br>
<kbabbitt> TabAtkins: this entire thing is confusing by default, I know<br>
<kbabbitt> ... if we end up not resolving here, that's fine<br>
<kbabbitt> ... I need to fix this problem somehow<br>
<miriam> the first becomes :is(.foo:hover)::before<br>
<kbabbitt> ... I tried another way and everyone hated it<br>
<kbabbitt> lea: any cases where an is through nesting does something different based on nesting?<br>
<miriam> the second becomes :is(.foo::before):hover<br>
<kbabbitt> TabAtkins: sometimes hopefully not often<br>
<kbabbitt> lea: that's worrying<br>
<kbabbitt> ... second example<br>
<lea> `.foo, .bar { &:hover, &:focus { &::before, &::after {} } }`<br>
<kbabbitt> ... based on answer to the first, does that change?<br>
<kbabbitt> TabAtkins: no, it's valid today and does what you expect, won't change<br>
<kbabbitt> ... will only give new results to selectors that don't select pseudos<br>
<kbabbitt> ... i.e. pseudo in middle of nesty<br>
<kbabbitt> lea: problem is once we do this we can't make them work right way<br>
<kbabbitt> TabAtkins: trying to find *a* way to make them work<br>
<emilio> q+<br>
<emilio> ack astearns<br>
<plinss> q+<br>
<kbabbitt> astearns: is the motivation for this entirely nesting and the bare is behavior just a side effect?<br>
<kbabbitt> TabAtkins: yes<br>
<kbabbitt> astearns: no use case for bare is?<br>
<kbabbitt> TabAtkins: there's use cases but not solving for this solving for nesting<br>
<kbabbitt> astearns: any back compat issues having some of these either nested or bare is things with pseudos in someone's stylesheet doing nothing suddenly working?<br>
<kbabbitt> TabAtkins: maybe, hopefully not<br>
<kbabbitt> astearns: does this fall out of the fact that we defined nesting by referencing is?<br>
<kbabbitt> ... and if so, can we instead redefine nesting to use an ish-is like thing<br>
<kbabbitt> ... but sever the tight connectoin between them?<br>
<lea> +1 astearns, was wondering about this too<br>
<ntim> :almost-is()<br>
<kbabbitt> TabAtkins: does somewhat fall out of the semantics defined in terms of is<br>
<kbabbitt> ... don't thnk we can define in other terms to get around this iwhtout either getting back to cominatorial problem<br>
<lea> q+<br>
<kbabbitt> astearns: wondering whetehr we can say, for purpose of nesting, this is the extra behavior you get with pseudos<br>
<kbabbitt> TabAtkins: maybe<br>
<kbabbitt> ... would be very frustrating if you could only express certain selectors via nesting<br>
<kbabbitt> astearns: that's fair<br>
<plinss> q-<br>
<romain> `.foo:is(*, ::before, ::after)`<br>
<astearns> ack romain<br>
<kbabbitt> romain: bit confused about one example, in irc<br>
<kbabbitt> ... don't see why that doesn't work<br>
<romain> `.foo:is(.bar, ::before, ::after)`<br>
<kbabbitt> .. I do but also worry that this second example won't work<br>
<kbabbitt> ... is it wildcards, or anything in pseudo won't work?<br>
<kbabbitt> TabAtkins: first one with wildcard totally works<br>
<kbabbitt> ... will match .foo elements only<br>
<kbabbitt> ... second one will match .foo.bar elements only<br>
<kbabbitt> romain: none of the pseudos will match?<br>
<kbabbitt> TabAtkins: correct ,because no pseudo matches .foo<br>
<kbabbitt> romain: think that's surprising<br>
<kbabbitt> ... mixing pseudos in doesn't work<br>
<kbabbitt> TabAtkins: agree, this is my second try to fix this<br>
<kbabbitt> romain: that's my main issue with this proposal, it's also very surprising<br>
<kbabbitt> miriam: this proposal fixes this?<br>
<TabAtkins> my previous idea was `.foo = (.bar, ::before, ::after)`<br>
<kbabbitt> emilio: it's meant to<br>
<kbabbitt> miriam: my understanding was that's the initial problem & what we're trying to fix<br>
<kbabbitt> romain: what TabAtkins was saying & what I was understanding, you can use pseudos in is, can't mix them<br>
<kbabbitt> TabAtkins: no right now pseudos in is are dropped<br>
<kbabbitt> romain: with proposal they become valid<br>
<kbabbitt> TabAtkins: yes<br>
<kbabbitt> romain: but only match with only pseudos or only classes<br>
<kbabbitt> TabAtkins: yes<br>
<kbabbitt> ... [another case that works I missed]<br>
<kbabbitt> romain: like astearns's thinking, if we let go of is, is there more we can do?<br>
<kbabbitt> ... cases written with nesting aren't ambiguous<br>
<kbabbitt> ... but when written with is, become invalid<br>
<kbabbitt> ... maybe there's more there<br>
<kbabbitt> astearns: also not sure<br>
<astearns> ack oriol<br>
<kbabbitt> oriol: also share concerns about implications for :is being a bit confusing<br>
<kbabbitt> ... along lines of what astearns was saying<br>
<kbabbitt> ... first not the case that & in nesting is defined in spec in terms of is<br>
<kbabbitt> ... just that definition happens to match same behavior<br>
<kbabbitt> ... impls use some kind of alias internally<br>
<kbabbitt> ... but that doesn't have to be the case per spec<br>
<kbabbitt> ... could say & will match elements OR pseudos<br>
<kbabbitt> ... don't see that this would introduce any combinatorial explosion<br>
<kbabbitt> ... with just this change ... impls will not be able to reuse is<br>
<lea> +1 oriol<br>
<kbabbitt> ... but at first glance doesn't seem like a big problem to me<br>
<kbabbitt> ... not just asking around this direction, want to propose it, seems simpler<br>
<kbabbitt> TabAtkins: wouldn't cause a combinatorial explosion, correct<br>
<kbabbitt> ... would cause that some selectos could only be written with nesting, would like to avoid<br>
<kbabbitt> ... want a syntax that lets us expres ssame things with and without nesting<br>
<TabAtkins> .foo { ::before, ::after { :hover { color: red; } } }<br>
<kbabbitt> oriol: I htink it's fine if that's the case<br>
<kbabbitt> ... maybe not ideal but preferable to making is very confusing<br>
<kbabbitt> ... could always extend to is in the future<br>
<kbabbitt> ... or some other syntax<br>
<kbabbitt> astearns: agree it would be nice to express same things nesting vs not<br>
<kbabbitt> ... but only if non-nested version is ergonomic and would get use<br>
<kbabbitt> TabAtkins: example I gave earlier would be totally valid to turn on in nesting but not normal selectors<br>
<kbabbitt> astearns: if non-nesting way of expressing it is so weird no one will ever use it. would be okay to have it be expressible nested only<br>
<kbabbitt> miriam: can be expressed without single selector<br>
<kbabbitt> TabAtkins: any nested selector if you want to expand out, it's fine<br>
<astearns> q?<br>
<astearns> ack emilio<br>
<ntim> I think astearns is saying we shouldn't regress the DX for :is() just to solve the nesting problem, if so +1<br>
<kbabbitt> emilio: is there any reason we cannot make is do what I think is expected behavior?<br>
<plinss> q+<br>
<kbabbitt> ... not preserve order but feels most intuitive?<br>
<kbabbitt> ... as long as you're in the rightmost compound, pseudos only match there<br>
<kbabbitt> ... we don't allow combinators past pseudos<br>
<kbabbitt> ... they don't have descendants that way<br>
<kbabbitt> ... from an impl perspective, does complicate stuff quite a bit<br>
<kbabbitt> ... suddenly selector can match a gazillion pseudos<br>
<kbabbitt> ... but feasible to implement<br>
<astearns> ntim: it’s not so much regressing the entire DX of :is(), I just don’t think it’s worth it to create a hard-to-use version of this with :is()<br>
<kbabbitt> ... I think you would still, other than that weirdness of order representing different things<br>
<kbabbitt> ... (gives examples)<br>
<kbabbitt> ... to me that seems more intuitive for authors<br>
<kbabbitt> ... it's not impossible to implement<br>
<kbabbitt> TabAtkins: the issue becomes that we don't have a concept in selectors ... would lose group of selectors that covers an element<br>
<kbabbitt> ... we rely on the fact that compound selectors can't change subject in a few places e.g. :not<br>
<kbabbitt> emilio: negations and such become tricky, yeah<br>
<kbabbitt> TabAtkins: we rely on the fact thaqt something in CSS lets us only filter, not filter and change<br>
<kbabbitt> ... would no longer have that to reach for at syntactical level<br>
<kbabbitt> ... unfortunate but not killer<br>
<kbabbitt> emilio: not thing is weird ,agree<br>
<kbabbitt> ... any use case?<br>
<kbabbitt> TabAtkins: not pseudo elements, but if pseudos are allowed inside is and can change subject<br>
<kbabbitt> ... why not relative selectors<br>
<kbabbitt> ... (examples)<br>
<kbabbitt> ... at that point we're working on some really shaky foundations<br>
<kbabbitt> ... a before pseudo is a child of an element<br>
<kbabbitt> ... if is can change to child, it should be able to change to any child<br>
<kbabbitt> ... not syntactically ambiguous, would run on same restrictions as nesting<br>
<kbabbitt> ... need combinator at start to trigger<br>
<kbabbitt> ... but if we're going in for a penny, might as well go in for a pound<br>
<kbabbitt> ... use cases for selecting an element and one of its children<br>
<miriam> q?<br>
<kbabbitt> ... can do with nesting<br>
<TabAtkins> .foo { &, & > .bar {...}}<br>
<kbabbitt> emilio: thinking about ...<br>
<kbabbitt> TabAtkins: this nesting example is totally fine<br>
<astearns> ack lea<br>
<kbabbitt> ... being able to express that with is, why not?<br>
<kbabbitt> lea: I think the top priority is that nesting needs to have expected semantics in evrey case<br>
<kbabbitt> ... nice to have multiple ways to express but lower priority<br>
<kbabbitt> ... if we ship this, will always violate principle of least surprise<br>
<kbabbitt> ... is there a subset of cases where it does what author expects?<br>
<kbabbitt> ... I think I came up with cases where even terminal pseudos didn't work, not sure<br>
<kbabbitt> ... I wonder if there's any subset where what TabAtkins is describing is expected<br>
<kbabbitt> ... maybe scope down to that<br>
<kbabbitt> ... and continue to keep other cases as invalid until we find a way to deal with them correctly<br>
<kbabbitt> ... I was also thinking along the lines of what astearns said<br>
<kbabbitt> ... maybe we can internally rewrite how & works<br>
<kbabbitt> ... maybe another path is to see if some limited expansion would prevent combintorial explosion<br>
<astearns> ack plinss<br>
<kbabbitt> plinss: kind of chasing a red herring and conflating too many things here<br>
<kbabbitt> ... nesting being defined with invisible is, should be considered an implementation detail<br>
<lea> +1 plinss<br>
<kbabbitt> ... nesting should just work as if a simple substitution<br>
<kbabbitt> ... combinational explosions okay, that might be behavior you get<br>
<kbabbitt> TabAtkins: minus specificity<br>
<kbabbitt> ... other than that I agree<br>
<kbabbitt> plinss: if we have a problem here with impl detail of nesting, we shouldn't fix that by changing behavior of is<br>
<kbabbitt> ... don't have a problem with changing behavior with is<br>
<kbabbitt> ... if you allow pseudos, you should allow combinators, since a pseudo is a combinator<br>
<kbabbitt> emilio: if it has the outcome of also fixing nesting ...<br>
<kbabbitt> plinss: if it also fixes a way of impling nesting, awesome<br>
<kbabbitt> ... don't need to redefine<br>
<kbabbitt> TabAtkins: What I'm hearing is decent appetite in WG to make nesting work better<br>
<romain> +1<br>
<kbabbitt> ... even if there's some selectors that can't be written without it<br>
<kbabbitt> ... or causing an explosion<br>
<astearns> +1<br>
<kbabbitt> ... and continue to pursue separately how to write without an explosion<br>
<kbabbitt> ... okay<br>
<kbabbitt> astearns: is this what you wanted miriam?<br>
<kbabbitt> miriam: yes<br>
<kbabbitt> astearns: are we taking back to issue or is there a scoped resolution?<br>
<kbabbitt> TabAtkins: Proposed: Go ahead and fix nesting, don't worry about non-nesting yet<br>
<emilio> q+<br>
<astearns> ack emilio<br>
<ntim> PROPOSED: Go ahead and fix nesting for pseudo-elements, don't worry about :is() yet<br>
<kbabbitt> emilio: this has the issue of effectively getting same semantics as keeping is-like substitution<br>
<kbabbitt> ... and making is be able to change target to pseudo element<br>
<kbabbitt> ... would rather investigate that<br>
<kbabbitt> ... don't think it's hard to prototype, kind of annoying<br>
<kbabbitt> TabAtkins: don't have to tie together, I just want them tied together<br>
<lea> TabAtkins: https://codepen.io/leaverou/pen/ByKKByO?editors=1100<br>
<kbabbitt> emilio: maybe we can start ...<br>
<kbabbitt> astearns: does it change your calculation if you account ofr the fact that some aren't happy with the is behavior change?<br>
<kbabbitt> emilio: want to change is to match what you want for nesting<br>
<kbabbitt> ... so you can do (example)<br>
<kbabbitt> TabAtkins: but then I want relative selectors to work<br>
<kbabbitt> emilio: fair but a bigger extension<br>
<kbabbitt> plinss: that's the part I'm not clear on what the result is<br>
<kbabbitt> emilio: I want this...<br>
<emilio> .foo:is(.bar, ::before, ::after) == .foo.bar, .foo::before, .foo::after<br>
<kbabbitt> ... to be the same as ...<br>
<kbabbitt> ntim: I disagree with that<br>
<kbabbitt> emilio: why?<br>
<kbabbitt> ... isn't that what people want?<br>
<kbabbitt> ntim: .foo is not a before pseudo<br>
<kbabbitt> emilio: don't you want combinators there?<br>
<TabAtkins> (this is the :-webkit-matches() behavior)<br>
<kbabbitt> [crosstalk]<br>
<emilio> .foo:is(.bar, > .baz, > .bar)<br>
<kbabbitt> plinss: if we put a combinator in is, what does that mean?<br>
<kbabbitt> ... does combinator go before thing that is is or after?<br>
<kbabbitt> emilio: what I typed<br>
<kbabbitt> TabAtkins: yeah that should work<br>
<miriam> q+<br>
<kbabbitt> emilio: would be equivalent to...<br>
<emilio> `.foo:is(.bar, > .baz, > .bar) == .foo.bar, .foo > .baz, .foo > .bar`<br>
<kbabbitt> ntim: why do we want to overload is? create a new pseudo class?<br>
<miriam> q-<br>
<kbabbitt> emilio: maybe but if we introduce that concept for nesting may as well<br>
<kbabbitt> TabAtkins: if we do this in pseudo space, no reason not to put it in is<br>
<kbabbitt> ntim: maybe :with?<br>
<kbabbitt> ... would make more sense as you read it<br>
<kbabbitt> ... .foo isn't a before pseudo element<br>
<kbabbitt> ... and isn't whatever overload<br>
<kbabbitt> emilio: is this only about naming of is?<br>
<kbabbitt> ntim: yes<br>
<kbabbitt> emilio: what about where?<br>
<kbabbitt> TabAtkins: :is is not meant to be read as "argments are things before"<br>
<kbabbitt> ... it's "I'm selecting something that's one of these'<br>
<kbabbitt> plinss: if you give me that explanation and write what emilio did<br>
<kbabbitt> ... the thing you're selecting is a .baz that is descendant of something that's also .foo<br>
<kbabbitt> ... so it's .foo.baz, not .foo > .baz<br>
<kbabbitt> TabAtkins: now you're arguing for accepting my idea as stated<br>
<kbabbitt> plinss: trying to get an idea of what combinator means<br>
<kbabbitt> ... emilio's expectation doesn't match mine<br>
<kbabbitt> TabAtkins: what emilio wrote is<br>
<kbabbitt> ... the pseudo element version is what :-webkit-matches did<br>
<kbabbitt> ... if it had a relative selector version as well, it would have same semantics emilio listed<br>
<ntim> I expect: `.foo:is(.bar, > .baz, > .bar)` == `.foo.bar, .baz > .foo , .bar > .foo`<br>
<kbabbitt> ... but we don't have to solve this right now<br>
<kbabbitt> ... could take resolution to fix nesting and figure out how to fix as selector later<br>
<kbabbitt> plinss: want to clarify that fix nesting means nesting does naive substitution and got combinatorial explosion if that's the result<br>
<kbabbitt> TabAtkins: as much as possible yes<br>
<kbabbitt> emilio: I find it weird because then you need to define what specificity of pseudo being there vs not<br>
<kbabbitt> ... right now is will drop pseudos<br>
<kbabbitt> ... nesting will right now drop pseudos<br>
<plinss> s/nesting does/nesting behaves as/<br>
<kbabbitt> ... and not consider their specificity in there<br>
<kbabbitt> TabAtkins: but if you put pseudos as innermost nested it works fine<br>
<ntim> `.foo:is(> .baz)` reads to me as ".foo which is a child of .baz", so `.baz > .foo`<br>
<kbabbitt> emilio: you're adding a selector that can select elements in a pseudo<br>
<kbabbitt> ... would rather make this work in :is<br>
<kbabbitt> ... don't see any reason not to do it if we're going to have this functionality<br>
<kbabbitt> TabAtkins: agree<br>
<kbabbitt> ntim: not saying we shouldn't express it, should be an issue for later<br>
<kbabbitt> astearns: I think people in the room agree that this should be expressible, just disagree on how to get it done<br>
<kbabbitt> ... we have agreement on how to make it work with nesting<br>
<kbabbitt> emilio: would like to preserve the fact that nesting can be expressed in terms of regular selectors<br>
<kbabbitt> ... answers a lot of questions about how selectors work<br>
<kbabbitt> ... if you have .foo:is(*)before after<br>
<kbabbitt> ... .before after don't contribute to specificity<br>
<kbabbitt> ... with nesting now they do<br>
<kbabbitt> TabAtkins: they're valid but pseudo elements don't<br>
<kbabbitt> TabAtkins: do pseudo elements have specificity? I don't think they do<br>
<kbabbitt> emilio: I think they do, but right now it might not be visible since you can only have 1<br>
<kbabbitt> ... and it only competes with 1 other pseudo<br>
<kbabbitt> ... when we implemented nesting, one thing that came up is that browsers do have some kind of ? specificity and they were getting mixed<br>
<kbabbitt> plinss: I get your desire to have a pseudo class that behaves exactly like this, and support it<br>
<kbabbitt> ... not usre it should be is<br>
<kbabbitt> emilio: not sure it should not be is<br>
<kbabbitt> ... extending where is something new<br>
<kbabbitt> plinss: not saying we ahve to invent something new, doesn't have to be is<br>
<kbabbitt> emilio: guess it depends how you read it<br>
<kbabbitt> ... if I select something that is this or that, that makes sense to me<br>
<kbabbitt> plinss: is and notion of combinators starts confusing what is is<br>
<kbabbitt> ... which is th eis<br>
<kbabbitt> ... is the is before the combinator or is the is after the combinator<br>
<kbabbitt> ... not sure is is the right thing here<br>
<kbabbitt> TabAtkins: should be read as thing after combinator, selecting thing matching argument<br>
<kbabbitt> plinss: you're basically lofting the combinator in front of the thing outside is<br>
<kbabbitt> TabAtkins: no<br>
<kbabbitt> plinss: then what does combinator do?<br>
<kbabbitt> TabAtkins: as if you just threw away other args and just removed the is<br>
<kbabbitt> ntim: that's not how I read it<br>
<kbabbitt> TabAtkins: that's how webkit-matches does it<br>
<kbabbitt> plinss: that interpretation may make sense if you call it matches, not if you call it is<br>
<kbabbitt> emilio: something we need to decide on is, what specificity these pseudos have<br>
<kbabbitt> ... some pseudos have class specificity<br>
<kbabbitt> ... should is have class specificity?<br>
<oriol> Issue about the specificity of pseudo-elements in nesting: https://github.com/w3c/csswg-drafts/issues/9600<br>
<kbabbitt> ... something else?<br>
<kbabbitt> ... that selector can now be matched against ?<br>
<kbabbitt> TabAtkins: class specificity, say what they have<br>
<kbabbitt> emilio: only relative ot other v-ts righ tnow<br>
<kbabbitt> ... needs to be defined in terms of global selector space<br>
<kbabbitt> TabAtkins: what is the specificity of an element midway down a pseudo stack<br>
<kbabbitt> ntim: already defined?<br>
<kbabbitt> TabAtkins: not yet but will become<br>
<kbabbitt> plinss: for a long time there was a restriction on pseudos, did we relax?<br>
<kbabbitt> TabAtkins: yes<br>
<kbabbitt> ntim: vt pseudos have specificity<br>
<emilio> emilio: but only against each other right now<br>
<kbabbitt> [missed]<br>
<kbabbitt> TabAtkins: emilio can you raise that as an issue?<br>
<ntim> emilio: I think we should implement this in :is, but fine<br>
<ntim> astearns: consensus by exhaustion?<br>
<ntim> PROPOSED: Resolve on behavior for nesting, and thinking about non-nesting later<br>
<ntim> scribe+<br>
<kbabbitt> RESOLVED: Resolve on behavior for nesting, and thinking about non-nesting later<br>
<emilio> ACTION: Emilio to file issue about specificity<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9702#issuecomment-3531632590 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 14 November 2025 08:47:09 UTC