- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 08 Oct 2025 16:54:36 +0000
- To: public-css-archive@w3.org
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> <emilio> masonf: this is about a pseudo named TBD that can be used to show interest by tapping on it<br> <emilio> ... typical use case would be to show this on touchscreens<br> <emilio> ... we've talked about other things but the open question is about what to do about pointer events and other events<br> <emilio> ... there's a footgun if the click event bubbles to the main element<br> <emilio> ... there is some precedent about events not bubbling in some sub-elements / pseudos<br> <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> <emilio> ... personally the last one scares me a bit<br> <emilio> ... seems very footgunny<br> <flackr> q+<br> <emilio> ... personal preference would be do the right thing, don't propagate any discrete mouse events, and propagate move<br> <astearns> ack flackr<br> <emilio> ... if there's a need to do that you can use the interest events<br> <emilio> q+<br> <emilio> flackr: why is that the right thing?<br> <emilio> ... usually if you made your own dialog events would still bubble<br> <emilio> masonf: it's true<br> <lea> q+<br> <astearns> q+<br> <emilio> ... right now it's hard to disambiguate what the click hit<br> <emilio> ... maybe there's an API expansion for that<br> <emilio> flackr: more worried about events going into a black hole over particular content<br> <emilio> ... specially given lots of people do event delegation<br> <emilio> masonf: part of the problem is that you forget this is on touchscreens<br> <emilio> flackr: I could see an argument to prevent the default behavior perhaps?<br> <astearns> ack emilio<br> <fantasai> emilio: First, I agree that it's not the right thing to do<br> <fantasai> emilio: as Olli commented in the issue<br> <fantasai> emilio: wrt [missed] can you programmatically build this?<br> <fantasai> emilio: can we expose a way to programattically show interest?<br> <fantasai> emilio: It's a bit of letting authors experiment with this pattern before committing to this pseudo-element<br> <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> <fantasai> <fantasai> +1<br> <fantasai> emilio: regarding events, I agree wouldn't want to special-case them<br> <fantasai> emilio: maybe preventDefault, like an author would do<br> <emilio> masonf: there's current no imperative API like showInterest() but it's a good idea<br> <astearns> ack lea<br> <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> <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> <astearns> generating the button<br> <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> <emilio> masonf: the special thing is the connection with interest invokers<br> <emilio> ... so that it shows interest on the originating element<br> <emilio> lea: doesn't that do the same on ::before and ::after?<br> <emilio> masonf: right, if a link has ::before and you click then you navigate rather than show interest<br> <emilio> lea: I see so this is something you can tap and you get the interest<br> <emilio> ... like the parent could do something else like a command<br> <emilio> dbaron: or put it in another way it's kind of like a button for hovering the element<br> <emilio> lea: does it actually trigger hover?<br> <emilio> masonf: no<br> <flackr> q+<br> <emilio> ... I think that's a separate thing<br> <lea> +1 astearns<br> <emilio> astearns: we should likely determine what we're going to do with events and pseudos generally before adding a version of it<br> <emilio> ack astearns<br> <astearns> ack astearns<br> <emilio> ack flackr<br> <astearns> ackfl<br> <astearns> ack flackr<br> <emilio> flackr: sounds analogous like if you had a button-within-a-button<br> <emilio> ... you wouldn't want the outer button to trigger<br> <emilio> ... maybe we can do that in a way that isn't preventing the propagation<br> <emilio> ... maybe there's precedent somewhere?<br> <emilio> +q<br> <emilio> q-<br> <emilio> +1<br> <lea> Indeed, that seems to be a broader issue, use cases abound for buttons within interactive controls (summaries, radio labels etc)<br> <emilio> masonf: I haven't investigated that, good question<br> <emilio> astearns: so back to the isue?<br> <emilio> s/isue/issue<br> <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