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;zcorpan> mfreed: This has been discussed a couple of times within csswg. This is a general-purpose pseudo for interest invokers<br>
&lt;zcorpan> mfreed: after the element for interestfor<br>
&lt;zcorpan> mfreed: e.g. for a button, next to it is a question mark that you can tap<br>
&lt;zcorpan> mfreed: dev opt-in<br>
&lt;zcorpan> mfreed: we discussed, might be better to use the command api... A11y folks thought it was a bad idea. The correct accessible pattern is a span with an onclick handler, because the accessibility information is already available. Should be something that can be clicked but not focusable<br>
&lt;lwarlow> q+<br>
&lt;astearns> q+<br>
&lt;zcorpan> mfreed: question about the name<br>
&lt;zcorpan> mfreed: question about position (after ::after)<br>
&lt;zcorpan> mfreed: questions in the issue<br>
&lt;astearns> ack lwarlow<br>
&lt;masonf> summary here: https://github.com/w3c/csswg-drafts/issues/12437#issuecomment-3211111439<br>
&lt;zcorpan> lwarlow: We don't want it to be tabbable right?<br>
&lt;zcorpan> mfreed: correct<br>
&lt;zcorpan> lwarlow: appearance: base-able<br>
&lt;zcorpan> lwarlow: button-like in user experience<br>
&lt;zcorpan> lwarlow: was there a conclusion about whether to have a command?<br>
&lt;ntim> q+<br>
&lt;zcorpan> mfreed: extensibility issue. Weird to make it not keyboard-focusable and not appear in the a11y tree<br>
&lt;zcorpan> mfreed: button with a command, points to an interestfor<br>
&lt;zcorpan> mfreed: subtly different pattern<br>
&lt;zcorpan> lwarlow: is there an example of another pseudo where you interact with ::before/::after<br>
&lt;zcorpan> mfreed: picker<br>
&lt;zcorpan> s/picker/picker-icon/<br>
&lt;zcorpan> mfreed: where does the thing fit in logically. Child, sibling?<br>
&lt;zcorpan> lwarlow: comes down to styling<br>
&lt;zcorpan> mfreed: I think near ::after<br>
&lt;zcorpan> lwarlow: I think after the after because it should be a sibling<br>
&lt;zcorpan> astearns: are there other instances of an interactive thing that we deliberately exclude from the a11y tree? seems weird to me<br>
&lt;zcorpan> lwarlow: number spin buttons<br>
&lt;zcorpan> lwarlow: file input button is technically not focusable<br>
&lt;zcorpan> lwarlow: same with range input<br>
&lt;ntim> number spin buttons don't provide extra context though, unlike the interest icon which might<br>
&lt;zcorpan> astearns: sounds like there are some assumptions that may or may not be true. The thing that you're showing interest in should already be in the a11y tree<br>
&lt;zcorpan> astearns: how much is it relying on authors doing the right thing?<br>
&lt;zcorpan> mfreed: I guess rely on not doing the wrong thing<br>
&lt;zcorpan> mfreed: addition of pseudo shouldn't change the rest of the a11y tree<br>
&lt;zcorpan> astearns: worry a bit about authors doing the wrong thing<br>
&lt;zcorpan> mfreed: agreed. I opened an a11y review with the w3c<br>
&lt;astearns> ack ntim<br>
&lt;astearns> ack astearns<br>
&lt;zcorpan> ntim: agree there are ways it can be misused<br>
&lt;zcorpan> ntim: maybe use it just to get the icon<br>
&lt;zcorpan> ntim: what happens if you have an invoker button, and generate interest icon. What happens when you click the interest icon?<br>
&lt;zcorpan> mfreed: Can have a button with a command the points to something, and interestfor for something else (showing what happens when you click the button)<br>
&lt;zcorpan> mfreed: the interest icon will only show the interest<br>
&lt;zcorpan> ntim: what if there's a click handler<br>
&lt;zcorpan> ntim: the pseudo is part of the button<br>
&lt;zcorpan> mfreed: good q. Haven't thought of that<br>
&lt;zcorpan> zcorpan: maybe if it's a sibling, it doesn't need to go through the owner element?<br>
&lt;zcorpan> ntim: usually for pseudos they do though<br>
&lt;zcorpan> mfreed: not just click, other events too<br>
&lt;zcorpan> mfreed: hover?<br>
&lt;zcorpan> lwarlow: can use css for special styling<br>
&lt;zcorpan> ntim: if you want to use JS for mouse over<br>
&lt;zcorpan> mfreed: need to think about this<br>
&lt;astearns> some cross-talk about tether<br>
&lt;zcorpan> zcorpan: video controls might not propagate click to the video<br>
&lt;zcorpan> mfreed: I can look at the examples luke gave and see what they do with clicks<br>
&lt;lwarlow> q+<br>
&lt;zcorpan> ntim: dependent on what webkit thinks of the interest proposal in general<br>
&lt;zcorpan> mfreed: one of the questions previously is whether it's more general than interestfor or if it's specific to interestfor<br>
&lt;astearns> ack lwarlow<br>
&lt;zcorpan> lwarlow: does this work well for the elements that accept interestfor<br>
&lt;zcorpan> lwarlow: button, anchor in HTML, anchor in SVG, and area element<br>
&lt;zcorpan> lwarlow: area is weird<br>
&lt;zcorpan> zcorpan: for svg anchor, would a sibling break positioning?<br>
&lt;zcorpan> mfreed: it's a child tho<br>
&lt;zcorpan> zcopran: ok I thought that wasn't decided<br>
&lt;zcorpan> mfreed: existing pseudos are children<br>
&lt;zcorpan> mfreed: will try to summarize, bring back to csswg<br>
&lt;lwarlow> q+<br>
&lt;zcorpan> astearns: may be useful to break out into subissues<br>
&lt;zcorpan> mfreed: click handler, general ordering question<br>
&lt;astearns> ack lwarlow<br>
&lt;zcorpan> lwarlow: re positioning, if this is position via anchor-positioning instead of static positioning, would that solve for SVG?<br>
&lt;zcorpan> ntim: not ideal, requires the icon to be out of flow<br>
&lt;zcorpan> lwarlow: makes sense<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-3254252906 using your GitHub account


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

Received on Thursday, 4 September 2025 15:31:49 UTC