- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 06 Aug 2025 16:21:45 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``Add a `::interest-hint` pseudo element to interest invokers``, and agreed to the following: * `RESOLVED: Pursue this functionality in HTML. Close this issue.` <details><summary>The full IRC log of that discussion</summary> <emilio> masonf: re. interest invokers, we have some props to control the delay, pseudo classes (open issue)<br> <emilio> ... the idea here is to add a pseudo-element as a `<button>` with invokers, only for interestfor and when the element has `content`<br> <emilio> ... this is generically useful but specially useful for touchscreens<br> <emilio> ... so you can just tap on it<br> <emilio> ... should be styled like a button<br> <emilio> ... tentative name is `::interest-hint` or `::interest-button`<br> <emilio> ... number of open questions<br> <emilio> ... one is name<br> <emilio> ... another is what kind of pseudo-element is it (tree abiding, fully stylable, something else?)<br> <emilio> ... should there be a way to put it before the originating element rather than ::after<br> <emilio> ... some others after prototyping this<br> <emilio> ... this is a button that can be originated by a button<br> <emilio> ... so button-in-button which is a no-no in a few questions<br> <emilio> ... another is focusability<br> <emilio> ... similar to those there's a question about how to handle click of them<br> <fantasai> ::interest-button seems clearer, ::interest-hint feels like it could be the hint card<br> <emilio> ... because of all these questions<br> <emilio> ... maybe this is an html feature<br> <emilio> ... so you have a button with a toggleinterest command or so<br> <emilio> ... not sure how much time we have to dig into it<br> <emilio> q+<br> <fantasai> scribe+<br> <emilio> astearns: may be better to start with html?<br> <fantasai> emilio: Was going to ask about that, this feels like a feature that is more generically useful.<br> <lea> +1<br> <lea> (to emilio)<br> <fantasai> emilio: A pseudo-element for this feels oddly specific, especially if conditional on the element. What triggers creation, is it all elements, only elements that can trigger a popover, something else?<br> <fantasai> emilio: Feels like an HTML solution that can toggle interest feels more generic to me, and less open questions.<br> <lea> q?<br> <astearns> ack lea<br> <emilio> scribe+<br> <TabAtkins> q+<br> <emilio> lea: agree with emilio, this feels overfit to me, I'd rather expose the right primitive to authors rather than special-casing that particular interaction<br> <fantasai> lea: I agree with Emilio. This kind of thing is over-fitting, better to expose primitives to authors rather than special-casing that interaction.<br> <astearns> ack TabAtkins<br> <lea> q+<br> <emilio> TabAtkins: having tried to implement, it's very difficult to get right<br> <emilio> ... don't want to put the burden on authors<br> <emilio> ... bikeshed specs do it badly<br> <masonf> q+<br> <astearns> ack lea<br> <emilio> ... so fixing it properly seems worth it<br> <emilio> lea: agree it should be easier, not sure we should special-case it for interest invokers like that<br> <emilio> ... but yeah let's figure out what's making it so hard<br> <emilio> TabAtkins: the difficulty is that there's tons of things that can interact with this transient interest<br> <lea> q+<br> <emilio> ... plus all the a11y tree interactions<br> <emilio> ... not sure there are primitives that we could make much easier<br> <emilio> ... for something that's so common and so useful<br> <astearns> ack masonf<br> <emilio> ... it's worthwile to special-case<br> <emilio> masonf: command/commandfor feels pretty easy for an author<br> <emilio> ... the ua could know the right relations from that<br> <emilio> ... so should be easy<br> <astearns> ack lea<br> <TabAtkins> (My big fear is that when we try to genericize these sorts of interactions too much, we run into the issues that CSS Toggles had - they're just *too* generic, and actually need pretty specific handling to do right.)<br> <emilio> ... almost dropped the issue from the agenda, seems like the prevailing sentiment is that it belongs in html<br> <emilio> lea: related, we have a parallel issue to make ::tooltip easier<br> <emilio> ... many of these use cases are covered by that<br> <emilio> ... also we see over and over that any ua-generated ui needs to be customizable<br> <emilio> ... I understand the pseudo makes it styleable but limits what you can do<br> <emilio> ... e.g. can't do inline svg<br> <emilio> ... if we add this feature I can see many cases that it should serve but shouldn't<br> <emilio> ... that's why I suggested decomposing it<br> <fantasai> +1 to emilio / lea / masonf<br> <emilio> masonf: should we resolve on this not being in CSS?<br> <lea> s/lea: related, we have a parallel issue to make ::tooltip easier/lea: related, we have a parallel issue to make ::tooltip stylable/<br> <emilio> astearns: would like to see html solution, but you file it?<br> <emilio> masonf: anyone would object against this?<br> <masonf> +1<br> <fantasai> PROPOSED: Pursue this functionality in HTML<br> <fantasai> RESOLVED: Pursue this functionality in HTML. Close this issue.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12437#issuecomment-3160804211 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 6 August 2025 16:21:45 UTC