Re: [csswg-drafts] Add an `::interest-button` pseudo element to interest invokers (#12437)

The CSS Working Group just discussed ``Add an `::interest-button` pseudo element to interest invokers``.

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> masonf: this is about a pseudo named TBD that can be used to show interest by tapping on it<br>
&lt;emilio> ... typical use case would be to show this on touchscreens<br>
&lt;emilio> ... we've talked about other things but the open question is about what to do about pointer events and other events<br>
&lt;emilio> ... there's a footgun if the click event bubbles to the main element<br>
&lt;emilio> ... there is some precedent about events not bubbling in some sub-elements / pseudos<br>
&lt;emilio> ... question is is this fine to do, does it also work for mousemove etc and also whether this is a more general feature<br>
&lt;emilio> ... personally the last one scares me a bit<br>
&lt;emilio> ... seems very footgunny<br>
&lt;flackr> q+<br>
&lt;emilio> ... personal preference would be do the right thing, don't propagate any discrete mouse events, and propagate move<br>
&lt;astearns> ack flackr<br>
&lt;emilio> ... if there's a need to do that you can use the interest events<br>
&lt;emilio> q+<br>
&lt;emilio> flackr: why is that the right thing?<br>
&lt;emilio> ... usually if you made your own dialog events would still bubble<br>
&lt;emilio> masonf: it's true<br>
&lt;lea> q+<br>
&lt;astearns> q+<br>
&lt;emilio> ... right now it's hard to disambiguate what the click hit<br>
&lt;emilio> ... maybe there's an API expansion for that<br>
&lt;emilio> flackr: more worried about events going into a black hole over particular content<br>
&lt;emilio> ... specially given lots of people do event delegation<br>
&lt;emilio> masonf: part of the problem is that you forget this is on touchscreens<br>
&lt;emilio> flackr: I could see an argument to prevent the default behavior perhaps?<br>
&lt;astearns> ack emilio<br>
&lt;fantasai> emilio: First, I agree that it's not the right thing to do<br>
&lt;fantasai> emilio: as Olli commented in the issue<br>
&lt;fantasai> emilio: wrt [missed] can you programmatically build this?<br>
&lt;fantasai> emilio: can we expose a way to programattically show interest?<br>
&lt;fantasai> emilio: It's a bit of letting authors experiment with this pattern before committing to this pseudo-element<br>
&lt;fantasai> emilio: There's lots of UI that you could use for this, and I'm not sure that a pseudo-element is covering them all<br>
&lt;fantasai> &lt;fantasai> +1<br>
&lt;fantasai> emilio: regarding events, I agree wouldn't want to special-case them<br>
&lt;fantasai> emilio: maybe preventDefault, like an author would do<br>
&lt;emilio> masonf: there's current no imperative API like showInterest() but it's a good idea<br>
&lt;astearns> ack lea<br>
&lt;lea> lea: We are discussing event propagation and other specifics for this new pseudo-element, does that mean we have a resolution to add the pseudo-element and what remains is the details? Apologies if I missed it, but I didn’t see it in the issue?<br>
&lt;lea> lea: in ::picker-icon, the icon is there anyway, so the pseudo-element lets us target that. However, this is about *generating* the icon, if I understand it correctly.<br>
&lt;astearns> generating the button<br>
&lt;lea> lea: Looking at the code snippets, this looks very similar to how ::before/::after are used. What does this provide that is different?<br>
&lt;emilio> masonf: the special thing is the connection with interest invokers<br>
&lt;emilio> ... so that it shows interest on the originating element<br>
&lt;emilio> lea: doesn't that do the same on ::before and ::after?<br>
&lt;emilio> masonf: right, if a link has ::before and you click then you navigate rather than show interest<br>
&lt;emilio> lea: I see so this is something you can tap and you get the interest<br>
&lt;emilio> ... like the parent could do something else like a command<br>
&lt;emilio> dbaron: or put it in another way it's kind of like a button for hovering the element<br>
&lt;emilio> lea: does it actually trigger hover?<br>
&lt;emilio> masonf: no<br>
&lt;flackr> q+<br>
&lt;emilio> ... I think that's a separate thing<br>
&lt;lea> +1 astearns<br>
&lt;emilio> astearns: we should likely determine what we're going to do with events and pseudos generally before adding a version of it<br>
&lt;emilio> ack astearns<br>
&lt;astearns> ack astearns<br>
&lt;emilio> ack flackr<br>
&lt;astearns> ackfl<br>
&lt;astearns> ack flackr<br>
&lt;emilio> flackr: sounds analogous like if you had a button-within-a-button<br>
&lt;emilio> ... you wouldn't want the outer button to trigger<br>
&lt;emilio> ... maybe we can do that in a way that isn't preventing the propagation<br>
&lt;emilio> ... maybe there's precedent somewhere?<br>
&lt;emilio> +q<br>
&lt;emilio> q-<br>
&lt;emilio> +1<br>
&lt;lea> Indeed, that seems to be a broader issue, use cases abound for buttons within interactive controls (summaries, radio labels etc)<br>
&lt;emilio> masonf: I haven't investigated that, good question<br>
&lt;emilio> astearns: so back to the isue?<br>
&lt;emilio> s/isue/issue<br>
&lt;emilio> masonf: I think I heard general feedback that stopping events isn't quite the right thing, let me summarize it and go back to the 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-3382444205 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:54:37 UTC