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

> * The only solution to this that I can see is to stop the propagation of pointer up/down type events at this pseudo element. It seems (?) like other events like `mouseover` or `mousemove` should continue to function, since those don't typically trigger actions.  Are there other ideas? I do note that other built-in pseudo elements like this (e.g. the spin buttons on `<input type=number>` or the file picker button on `<input type=file>`) all continue to propagate all events to the originating element.

I thought a bit more about this, and did an exploration of browser behavior for built-in HTML elements that have internal "buttons". I think that's the most similar situation to try to follow. Note that many of these don't actually have pseudo elements, but I don't think that changes the fact that these are models of elements that have contained button widgets, whether or not the widget can be styled via a pseudo element.

My test page: https://jsbin.com/dapidep/edit?html,output

Results:

- All three engines bubble pointer events (e.g. mousedown, mouseup, click) for clicks on these things:
    - `<input type=number>` up/down buttons
    - `<input type=file>` chooser button
    - `<input type=date>` picker icon
    - `<input type=color>` button
    - `<details>` toggle widget
- Blink and Gecko do *not* bubble any pointer events for clicks on these things, while WebKit *does*:
    - `<video>` play/pause button, scrubber, mute, nested menus, etc.
    - `<audio>` play/pause button, scrubber, mute, nested menus, etc.
- Gecko does *not* bubble any pointer events for clicks on these things, while Blink and WebKit *do*:
    - `<video>` interactions within the video playback area
- All three engines do *not* bubble any pointer events for clicks on these things:
    - `<input type=date>` all interactions with the popup date picker
    - `<input type=color>` all interactions with the popup color picker
    - `<input type=file>` all interactions with the popup file picker

Given the above mix of behaviors, which seem to choose the appropriate behavior (bubbling or not bubbling) to fit the use case, my conclusion is that we're free to decide whether or not to bubble pointer events up from the `::interest-button` pseudo element. And it seems to me that since the point of the `::interest-button` is to provide a direct way to show interest in the originating element, in as transparent and easy-to-use way as possible, the best would be to **not** bubble any pointer events up from the pseudo element. That keeps click handlers (on the underlying link or button) from accidentally firing, or requiring added (potentially tricky) logic to disambiguate clicks. And it makes the behavior for `<button interestfor=foo popovertarget=bar>` straightforward to understand and implement. 

Thoughts?

> 2\. How does this work with an SVG-`<a>` element?
>     2b. How about the `<area>` element? 

For SVG's `<a>` I think we can wait, since that's not even in the HTML spec PR. And for `<area>`, it's a weird enough case that I think perhaps the best thing might just be to *not* support `::interest-button` for that element. In that specific case, the positioning of the pseudo element would be pretty hard to define in a generally useful way. But open to suggestions!




-- 
GitHub Notification of comment by mfreed7
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12437#issuecomment-3357097230 using your GitHub account


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

Received on Wednesday, 1 October 2025 16:02:50 UTC