- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 08 Oct 2025 16:41:32 +0000
- To: public-css-archive@w3.org
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> <emilio> lea: This is about introducing a combinator with slash syntax like `/interestfor/` to go from invoker to its target<br> <emilio> ... a combinator allows `:has()` to do the opposite<br> <emilio> q+<br> <emilio> masonf: there's another issue that you linked to that is more general (#10970)<br> <emilio> ... about a combinator that represents an idref<br> <emilio> lea: ah yeah it could be argued that this is an special case of a general idref<br> <lea> https://github.com/w3c/csswg-drafts/issues/10970<br> <emilio> ... there's a discussion about `<label for>` etc<br> <emilio> ... then it could be argue that this could be generalized even more<br> <emilio> ... but idref seems reasonable<br> <masonf> q+<br> <emilio> ... we have so many of them<br> <astearns> ack emilio<br> <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> <lea> to emilio: As mentioned in the issue, it would be functional, e.g. `label /idref(for)/ input`<br> <lea> q+<br> <astearns> ack masonf<br> <futhark> q+<br> <emilio> emilio: does idref() take a list of hardcoded attributes or so?<br> <emilio> ... anyways wanted to say that this is more complicated than it looks like because invalidation becomes quite hard<br> <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> <emilio> ... so I wanted to be a bit cautions about this<br> <emilio> ... not sure we need the whole generality of combinators<br> <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> <emilio> ... the concrete usecase we've come across is menus<br> <emilio> ... popover have a single invoker<br> <emilio> ... so you'd like to style a menulist differently based on what invoked it<br> <lea> q?<br> <emilio> ... so it's not about what points to it but about the thing that actually invoked it<br> <astearns> ack fantasai<br> <emilio> fantasai: +1 to emilio and masonf<br> <astearns> ack lea<br> <emilio> ... for this specific issue WebKit objects to interestfor so we don't want to see features added for this<br> <emilio> lea: Multiple things, masonf makes a good point, which element invoked this is different from pointing to it<br> <emilio> ... so that might deserve some special casing<br> <emilio> ... to emilio, combinators are the CSS mechanism from going from one element to another<br> <lea> scribenick+<br> <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> <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> <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> <lea> lea: A generic combinator also supports custom element attributes, whereas a hardcoded one does not.<br> <fantasai> +1 to the point about the purpose of combinators vs pseudo-elements<br> <lea> lea: And how does a hardcoded one work? Is it keyed on specific elements or attr name? idref() sidesteps all that<br> <astearns> q?<br> <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> <dbaron> ScribeNick: emilio<br> <astearns> ack futhark<br> <dbaron> s/scribenick+/ScribeNick: lea/<br> <emilio> futhark: Agree with emilio, a bit surprised that it was a combinator, this is quite similar to `:has()`<br> <emilio> ... you could argue that `:has` could've been a combinator<br> <emilio> ... is it expected that you want to then continue to other combinators for that element?<br> <emilio> masonf: don't know<br> <emilio> ... only recently came up with the menu use case<br> <astearns> ack fantasai<br> <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> <emilio> fantasai: for some of these things it's not that there's an attribute, there's other way of creating the association<br> <emilio> ... e.g. passing an option to showDialog, so it's not just about the attribute<br> <emilio> ... so I think we do need something custom so that we create the association<br> <emilio> ... so it works regardless of how you create the association (nesting inside <label>, imperative API...)<br> <masonf> perhaps ::invokedby(selector)<br> <emilio> ... so I don't think idref() is what we want here<br> <fantasai> masonf, that would be a pseudo-class but yeah that could work<br> <emilio> ... we need to look at the different associations<br> <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> <lea> q+<br> <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> <emilio> masonf: maybe we can repurpose this issue<br> <astearns> ack lea<br> <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> <emilio> lea: I think there's value in spec-ing the DOM relationship and the invoked relationship. The former could be idref()<br> <masonf> +1<br> <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