Re: [csswg-drafts] Combinator to get from `interestfor` invoker to its target (#12436)

The CSS Working Group just discussed ``Combinator to get from `interestfor` invoker to its target``.

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> lea: This is about introducing a combinator with slash syntax like `/interestfor/` to go from invoker to its target<br>
&lt;emilio> ... a combinator allows `:has()` to do the opposite<br>
&lt;emilio> q+<br>
&lt;emilio> masonf: there's another issue that you linked to that is more general (#10970)<br>
&lt;emilio> ... about a combinator that represents an idref<br>
&lt;emilio> lea: ah yeah it could be argued that this is an special case of a general idref<br>
&lt;lea> https://github.com/w3c/csswg-drafts/issues/10970<br>
&lt;emilio> ... there's a discussion about `&lt;label for>` etc<br>
&lt;emilio> ... then it could be argue that this could be generalized even more<br>
&lt;emilio> ... but idref seems reasonable<br>
&lt;masonf> q+<br>
&lt;emilio> ... we have so many of them<br>
&lt;astearns> ack emilio<br>
&lt;lea> and this is the even more general issue (which I think might be _too_ general): https://github.com/w3c/csswg-drafts/issues/12446<br>
&lt;lea> to emilio: As mentioned in the issue, it would be functional, e.g. `label /idref(for)/ input`<br>
&lt;lea> q+<br>
&lt;astearns> ack masonf<br>
&lt;futhark> q+<br>
&lt;emilio> emilio: does idref() take a list of hardcoded attributes or so?<br>
&lt;emilio> ... anyways wanted to say that this is more complicated than it looks like because invalidation becomes quite hard<br>
&lt;emilio> ... also there's another layer of complexity due to shadow DOM and all the things people are actively trying to do to fix idrefs and shadow trees<br>
&lt;emilio> ... so I wanted to be a bit cautions about this<br>
&lt;emilio> ... not sure we need the whole generality of combinators<br>
&lt;emilio> masonf: few things... first there's an spectrum of generality, I think probably it makes sense to generalize a bit and not making it specific<br>
&lt;emilio> ... the concrete usecase we've come across is menus<br>
&lt;emilio> ... popover have a single invoker<br>
&lt;emilio> ... so you'd like to style a menulist differently based on what invoked it<br>
&lt;lea> q?<br>
&lt;emilio> ... so it's not about what points to it but about the thing that actually invoked it<br>
&lt;astearns> ack fantasai<br>
&lt;emilio> fantasai: +1 to emilio and masonf<br>
&lt;astearns> ack lea<br>
&lt;emilio> ... for this specific issue WebKit objects to interestfor so we don't want to see features added for this<br>
&lt;emilio> lea: Multiple things, masonf makes a good point, which element invoked this is different from pointing to it<br>
&lt;emilio> ... so that might deserve some special casing<br>
&lt;emilio> ... to emilio, combinators are the CSS mechanism from going from one element to another<br>
&lt;lea> scribenick+<br>
&lt;lea> lea: masonf made a good point: which element invoked which is not a relationship that can be determined by looking at the DOM, and could warrant a specific combinator (though possibly the same for all three)<br>
&lt;lea> lea: A combinator is the CSS way of going from one element to another element. We use pseudo-elements only for parts of elements, or encapsulated elements, neither of which are the case here.<br>
&lt;lea> lea: The question, as I understand it, isn’t whether it should be a combinator, but whether it should be a more general combinator or hardcoded to interestfor<br>
&lt;lea> lea: A generic combinator also supports custom element attributes, whereas a hardcoded one does not.<br>
&lt;fantasai> +1 to the point about the purpose of combinators vs pseudo-elements<br>
&lt;lea> lea: And how does a hardcoded one work? Is it keyed on specific elements or attr name? idref() sidesteps all that<br>
&lt;astearns> q?<br>
&lt;lea> lea: Re: complexity, I wonder if we could ship it with a whitelist of attributes at first and expand later, rather than adding ad hoc combinators<br>
&lt;dbaron> ScribeNick: emilio<br>
&lt;astearns> ack futhark<br>
&lt;dbaron> s/scribenick+/ScribeNick: lea/<br>
&lt;emilio> futhark: Agree with emilio, a bit surprised that it was a combinator, this is quite similar to `:has()`<br>
&lt;emilio> ... you could argue that `:has` could've been a combinator<br>
&lt;emilio> ... is it expected that you want to then continue to other combinators for that element?<br>
&lt;emilio> masonf: don't know<br>
&lt;emilio> ... only recently came up with the menu use case<br>
&lt;astearns> ack fantasai<br>
&lt;emilio> futhark: I think of combinators as walking the tree and if you can walk arbitrary elements in the tree and then continue selector matching it gets complicated<br>
&lt;emilio> fantasai: for some of these things it's not that there's an attribute, there's other way of creating the association<br>
&lt;emilio> ... e.g. passing an option to showDialog, so it's not just about the attribute<br>
&lt;emilio> ... so I think we do need something custom so that we create the association<br>
&lt;emilio> ... so it works regardless of how you create the association (nesting inside &lt;label>, imperative API...)<br>
&lt;masonf> perhaps ::invokedby(selector)<br>
&lt;emilio> ... so I don't think idref() is what we want here<br>
&lt;fantasai> masonf, that would be a pseudo-class but yeah that could work<br>
&lt;emilio> ... we need to look at the different associations<br>
&lt;lea> +1 fantasai, this does seem to go beyond idref. Though idref could still be useful for "can invoke", which is a distinct relationship to "has invoked"<br>
&lt;lea> q+<br>
&lt;emilio> astearns: so wanted to close the issue and discuss in idref() but we don't have an issue for the non-idref-based bits<br>
&lt;emilio> masonf: maybe we can repurpose this issue<br>
&lt;astearns> ack lea<br>
&lt;lea> lea: this does seem to go beyond idref. Though idref could still be useful for "can invoke", which is a distinct relationship to "has invoked"<br>
&lt;emilio> lea: I think there's value in spec-ing the DOM relationship and the invoked relationship. The former could be idref()<br>
&lt;masonf> +1<br>
&lt;emilio> astearns: I think we have useful input, so we should take it back to the issues<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12436#issuecomment-3382389079 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 8 October 2025 16:41:32 UTC