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;fantasai> masonf: This is a pseudo-element tentatively called ::interest-button, related to interest invokers<br>
&lt;fantasai> masonf: It follows the originating element<br>
&lt;fantasai> masonf: created when has interestfor attribute<br>
&lt;fantasai> masonf: when you click that button, it will show interest in the originating element<br>
&lt;fantasai> masonf: normally will be used with media queries<br>
&lt;fantasai> masonf: Example might be the little info mark that gives you more info<br>
&lt;fantasai> masonf: wrt accessibility, it should not be a focusable button. It should just be a tap target<br>
&lt;fantasai> masonf: there are other ways to trigger interest<br>
&lt;fantasai> masonf: Only open discussion point was what happens with click event<br>
&lt;fantasai> masonf: that click will propagate up to originating element<br>
&lt;fantasai> masonf: but you don't want to activate it<br>
&lt;fantasai> masonf: So that's the proposal, to preventDefault on this pseudo element<br>
&lt;TabAtkins> Reading back over the issue, I'm happy with the suggested changes<br>
&lt;fantasai> Rossen3: Not seeing Lea on the call, but comment at end of issue<br>
&lt;fantasai> masonf: She proposed rather than a pseudo-element, a new CSS property, that when you set to a value, means the same thing<br>
&lt;fantasai> masonf: so you could add your own button that's a child of the element, and it would indicate interest in the parent element<br>
&lt;fantasai> masonf: I was hoping she would behere<br>
&lt;TabAtkins> q+<br>
&lt;fantasai> masonf: concern is that it would be a real button, but a11y folks find it problematic because don't want to have this extra button<br>
&lt;emilio> q+<br>
&lt;Rossen3> ack TabAtkins<br>
&lt;Rossen3> ack emilio<br>
&lt;fantasai> TabAtkins: agreed with mason, applying to elements that already have significant a11y behaviors, makes it complicated to add something like that<br>
&lt;fantasai> emilio: I'm not objecting, but it does seem like a very over-specific thing<br>
&lt;fantasai> emilio: seems weird to add fixed cost of needing to resolve the style to add the invoker etc.<br>
&lt;fantasai> emilio: Each magic pseudo-element we add has a cost<br>
&lt;fantasai> emilio: back when we discussed earlier, my suggestion was to create a programmatic API to indicate interest to see what kinds of patterns emerge<br>
&lt;fantasai> +1 to emilio<br>
&lt;TabAtkins> I would use it on Bikeshedded specs *immediately*<br>
&lt;fantasai> emilio: you hit the issue of "you're using a button to trigger interest in something else"<br>
&lt;fantasai> emilio: seems fine<br>
&lt;TabAtkins> Like, I manually do both the popup and the interest *badly* today<br>
&lt;fantasai> emilio: Author should be responsible for building interface and what should trigger interest<br>
&lt;fantasai> masonf: I thought they were great suggestions, and we discussed a lot, but caveats<br>
&lt;fantasai> masonf: One idea was, build this into the command system. Chains invokers.<br>
&lt;fantasai> masonf: Issue was that it was confusing in practice, to have chains of invokers<br>
&lt;fantasai> masonf: but bigger issue was a11y thing, having multiple ways to trigger same action with a button in AT was a problem<br>
&lt;fantasai> masonf: Other one, a JS API showInterest(), has the same caveats wrt a11y<br>
&lt;emilio> q+<br>
&lt;fantasai> masonf: Another use case was well you can polyfill this behavior<br>
&lt;fantasai> masonf: but the comment from Keith was, you'd polyfill the entire feature, why polyfill just the interest part<br>
&lt;fantasai> masonf: So what's the point<br>
&lt;fantasai> masonf: One follow-up -- you said generated content has a fixed cost?<br>
&lt;fantasai> emilio: In this case, I guess it would be conditional on thing being an interest target, but for every interest target thing, you need to resolve an extra style, track changes to it, etc. even if the author doesn't use this<br>
&lt;fantasai> masonf: it is limited to elements with interestfor, but would be all of them yes<br>
&lt;fantasai> emilio: I wouldn't object to adding it if everyone else thinks it's the right shape, but ...<br>
&lt;fantasai> emilio: I'm not sure I get the a11y concerns. you need somehting that doesn't show up in the a11y tree but authors do that all the time<br>
&lt;Rossen3> ack emilio<br>
&lt;fantasai> masonf: Shouldn't show up in keyboard navigation either<br>
&lt;fantasai> masonf: generally that's an anti-pattern, but in this case it's desired<br>
&lt;emilio> ack emilio<br>
&lt;Rossen3> ack fantasai<br>
&lt;kbabbitt> fantasai: emilio asked if this is the right api shape, I think it's not, uncomfortable with the proposal overall<br>
&lt;kbabbitt> ... get what masonf is saying about a11y, maybe it could be handled in HTML?<br>
&lt;kbabbitt> ... button that does interestfor thing with appropriate a11y bindings<br>
&lt;kbabbitt> ... share a number of emilio's concerns and have others<br>
&lt;kbabbitt> ... regarding interaction model<br>
&lt;fantasai> masonf: IIRC your concerns were about the overall API shape of interestfor, and this was intended to get around one of the main concerns which was how to handle touchscreens<br>
&lt;fantasai> masonf: this pseudo-element is a way to make that easy for the user<br>
&lt;bkardell> it would be good to link this to where the original objection was and see if the same people (annevk maybe?) can reevaluate<br>
&lt;bkardell> I think maybe it was from the standards position?<br>
&lt;fantasai> Rossen3: Is this concern already captured, or is it new?<br>
&lt;fantasai> masonf: That objection is the genesis of this issue.<br>
&lt;emilio> I mean this would be a `&lt;span onclick="this.parentElement.showInterest(); return false">Content&lt;/span>`, right?<br>
&lt;fantasai> masonf: I would love if someone with Apple with context could comment on it. Maybe I can summarize after the meeting notes get posted.<br>
&lt;fantasai> Rossen3: Sounds like a reasonable way forward<br>
&lt;smfr> q+<br>
&lt;fantasai> Rossen3: would also allow others like Lea and Emilio to articulate their thoughts<br>
&lt;fantasai> smfr: I think there's a procedural issue. OpenUI resolutions are not binding. Idk that CSSWG has agreed to work on interest invokers.<br>
&lt;fantasai> masonf: Stuff in the CSS spec were added based on CSS resolutions.<br>
&lt;fantasai> smfr: I think we need to go back. Anne probably also has opinions.<br>
&lt;fantasai> masonf: sounds good<br>
&lt;Rossen3> ack smfr<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-3666467438 using your GitHub account


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

Received on Wednesday, 17 December 2025 17:43:32 UTC