- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 09 Apr 2026 15:31:12 +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>
<lwarlow> problem with span is it then becomes opt-in again...<br>
<lwarlow> q+<br>
<cwilso> ack next<br>
<jarhar> masonf: *gives intro*<br>
<jarhar> lwarlow: making it opt in is less than ideal especially if the aria deep dive was leaning opt out<br>
<lea> q+<br>
<jarhar> lwarlow: its a weird api to have this interest button api only apply to span, and then youre telling a span to be a button, which is something we dont want people to do, except in this case because it shouldnt be keyboard focusable<br>
<astearns> +1 to the span is a button concern<br>
<jarhar> lwarlow: pseudo makes more sense here. if someone wants something more complex they can use js<br>
<jarhar> masonf: you could do this yourself with script but thats a bad pattern<br>
<jarhar> masonf: the interest button is like magic<br>
<cwilso> q+ emilio<br>
<jarhar> annevk: i havent been involved in the interst discussion for a while. we have some feedback ,which is that we dont think that the feature for touch screens should be opt in<br>
<jarhar> annevk: maybe mason already mentioned that as well. before with pseudo element you had to make it appear, which we dont think is a good model. the experience of interest should be there for all paltforms by default. maybe you can hide it on some platforms, at least the default should be that way<br>
<jarhar> annevk: i havent given much thought to the shape. one alternative is that instead of a span with an attribute youd have a new element, and maybe that element would also be required to make things happen. if you wanted to make the interest thing happen youd have this interest element that would be a child of a button and that would trigger these<br>
<jarhar> semantics<br>
<jarhar> annevk: that would be a way to force people to include it in the markup<br>
<lwarlow> compat issues with that because Chromium already shipped though.<br>
<jarhar> masonf: we did talk about a new element. the new thing is that it would be required, which might be a good idea.<br>
<cwilso> ack next<br>
<jarhar> lea: luke mentioned that this makes it opt in and thats a problem. do we have consensus that its opt out if possible? it doesnt seem obviously desirable. i think if there is ui thats generated by the ua, since it is unlikely to match the existing website styling, i expect that this is something that authors would remove altogether. its hard to<br>
<jarhar> inject something that works well with any existing ui<br>
<jarhar> lea: to me it seems that it should be opt in, but the opt in should be low friction<br>
<jarhar> lea: i agree that its weird to make it a span. i dont know how much of an issue that is. anything that involves a new element would be a problem in empty elements<br>
<jarhar> lea: i know we resolved that were not adding new empty elements<br>
<lwarlow> We didn't add it to <input type=button> so there's no void element supporting interestfor right now<br>
<jarhar> lea: this interest button, since it doesnt need to be exposed to a11y, it reminds me of generated content. maybe we could add something to css for this generated content. to me seems like a smaller delta than adding a whole new feature specifically for that<br>
<jarhar> masonf: the consensus in aria was to make it opt out to make it a decision a developer has to make. i dont think weve come to a consensus in this group<br>
<cwilso> ack next<br>
<jarhar> emilio: not sure if it should be opt in or out. part of the reason that ? suggested adding a js api for this, if you add a pseudo and you need something more powerful, right now you cant make that happen. theres no programmatic way to show interest<br>
<jarhar> masonf: thats right<br>
<jarhar> emilio: i would also lean towards making it opt in and then the js api is a bear minimum mvp and then we can see if people use it<br>
<lea> q+<br>
<jarhar> emilio: if we want to make it a speudo element that is always there and we figure out the issues that lea mentioned, we still want some sort of api to trigger this manually or you want the button to be positioned elsewhere<br>
<jarhar> masonf: i dont disagree that we need a js api, but i think its orthogonal to this conversation. its a strong anti-pattern to use onclick = some api<br>
<jarhar> masonf: thats bad everywhere else<br>
<lea> q?<br>
<jarhar> masonf: we need something more automatic here even if we add a js api<br>
<fantasai> +1 masonf<br>
<jarhar> emilio: i dont think adding a pseudo is particularly desirable if theres no way to make this work for more complex things<br>
<jarhar> emilio: i agree with lea that most people are just going to hide it because it doesnt match their design<br>
<jarhar> emilio: its like box sizing. now everyone writes * box sizing border box<br>
<lwarlow> q+<br>
<jarhar> emilio: i expect a bunch of people would do ::interest or whatever with display:none<br>
<jarhar> masonf: my hope is that instead of display:none they use a media query, which we could provide a copy pastable thing<br>
<jarhar> masonf: so that your users can still see it on touch<br>
<jarhar> masonf: having it be opt out forces them to at least encounter it<br>
<jarhar> emilio: sure, but i still think all the limitations that pseudos have<br>
<jarhar> emilio: if we add a pseudo then we should also add a js api<br>
<cwilso> ack next<br>
<jarhar> lea: one advantage of making it opt in is that we can ship without it<br>
<lwarlow> ...it already shipped<br>
<jarhar> lea: otherwise we cant add it later<br>
<jarhar> lea: to emilio, i wasnt saying we can just do it with generated content so theres nothign we can do. i meant that we could add a css property for this behavior. i dont know what the right primitive is for that<br>
<jarhar> lea: it means that the design space is different than what weve been figuring out so far<br>
<jarhar> lea: css property can be added on a regular element as well<br>
<jarhar> lea: doesnt force you to use generated content, it just means you can<br>
<jarhar> masonf: chrome has shipped this api, but there is an objection from appple over this corner of the api. were willing to take the compat pain of that<br>
<bkardell> fwiw I agree that opt-out makes the most sense to me<br>
<jarhar> masonf: if the consensus is that you need an opt out, we can figure it out<br>
<jarhar> lea: until its shipped in all browsers, developers have not started to rely on it yet<br>
<cwilso> ack next<br>
<jarhar> lwarlow: for a feature that is about improving a11y, and the aria wg said it should be opt out which they did for various reasons, including voice control not working without an activatable element, i think it should be opt out if thats the pattern that makes sense<br>
<jarhar> lwarlow: yes people may just blanket display none it<br>
<jarhar> lwarlow: but then they are going to find that its less usable<br>
<jarhar> lwarlow: potentially one thing is maybe we dont make it display:block always. maybe the ua can decide<br>
<jarhar> lwarlow: on a touch screen it shows and on desktop it doesnt<br>
<jarhar> lwarlow: maybe people are less likely to display:none it that way<br>
<jarhar> lwarlow: the thing about whether you can do it with js or not. you can strictly speaking do it with js<br>
<lea> q+<br>
<jarhar> lwarlow: lose interst and gain interest is not super important on a touch screen<br>
<jarhar> lwarlow: im not saying we shouldnt add a js api, but i think its still useful without one<br>
<jarhar> lwarlow: i dont think it should be a css property because its quite behavioral<br>
<bkardell> its stylable<br>
<jarhar> lwarlow: it might not fit in with styling of the page<br>
<jarhar> lwarlow: i imagine that ua styles for this are minimal so it can fit in with styles as best as possible<br>
<bkardell> +1<br>
<jarhar> lwarlow: i still lean for psuedo element and i think it should be opt out, but maybe uas can do something more interesting than blanket enable it<br>
<cwilso> ack next<br>
<jarhar> fantasai: i think what luke said makes sense to me. if we want to make this an attribute then making it work on most elements would be possible. you could put it on a button but then it makes it less button-y<br>
<jarhar> fantasai: markup put on the button could be something that makes sense to them but also overrides the existing behavior of that element to make it behave like an interest button<br>
<lwarlow> <button><button interestbutton></button></button> doesn't work with the parser so I don't think that's ideal to encourage btw.<br>
<jarhar> fantasai: if we combine that idea with annes then if there isnt a button then you can generate one automatically<br>
<jarhar> fantasai: then its functionally required, if you dont have it then we create one for you<br>
<masonf> q+<br>
<cwilso> ack next<br>
<jarhar> lea: it was mentioned that uas should be free to display it only sometimes so that its only on touch<br>
<jarhar> lea: if thats what we want to do we dont have to make it ua dependent. we can do it with pointer media query<br>
<jarhar> lea: having a thing that affects layout like that which a developer wont see seems like a footgun<br>
<fantasai> @media (hover) { ::interest-button { content: "\1F6C8"; } }<br>
<lwarlow> Should we maybe timebox this to half past the hour? Just concious of the rest of the agenda<br>
<jarhar> lea: if it could be done with styling that doesnt affect layout that could be better<br>
<jarhar> fantasai: i think youre missing the point. this is about having a way to trigger the hover thing<br>
<lwarlow> Problem with the media query is that it's actually not as simple as it seems<br>
<jarhar> fantasai: this button actually has a behavior where you click on it then it reveals the panel<br>
<jarhar> lea: yes sorry i forgot that<br>
<cwilso> ack next<br>
<jarhar> masonf: theres a big question about whats the overall shape of the api<br>
<fantasai> s/the point/the point, this is not about styling/<br>
<lwarlow> Samsung Internet for example fails the simple media queries on some devices because of the pens and what not<br>
<jarhar> masonf: and then theres all the little questions<br>
<jarhar> masonf: i wonder if it would be possible to do a straw poll<br>
<jarhar> masonf: and then go back to figure out the little questions<br>
<bkardell> đź‘Ť<br>
<jarhar> masonf: is it too early for that?<br>
<lea> Perhaps we can do a straw poll about opt-in vs opt-out as that affects API shape a lot<br>
<masonf> https://www.irccloud.com/pastebin/Ma0ntgbv/<br>
<fantasai> Mason wrote:<br>
<fantasai> 1: ::interest-button<br>
<fantasai> 2: <span interestbutton><br>
<fantasai> 3: <interestbutton><br>
<fantasai> 4: <span onclick=”invoker.showInterest()”><br>
<jarhar> masonf: weve talked today about ways to make it opt in or opt out<br>
<jarhar> masonf: the other 3 could be made more easiliy opt in or opt out<br>
<lwarlow> I don't understand how to vote for this but 1<br>
<jarhar> masonf: its sort of obvious for the pseudo. for the elements, its less obvious<br>
<keithamus> 1 & 3<br>
<bkardell> 1 or 3 are both good<br>
<jarhar> masonf: how does the developer go about turning it off<br>
<jarhar> masonf: its a little weird to do that with a media query but you can do it<br>
<lea> 1 though not a huge fan of either<br>
<fantasai> not 4<br>
<castastrophe> 1 or 4<br>
<astearns> 1 or 3<br>
<fantasai> 1 + 2 or 3<br>
<lwarlow> To throw a spanner in the works perhaps we shouldn't do an `<interestbutton>` but `<action>` and that will hook into aria-actions too? But that's probably off topic<br>
<bkardell> 1 wins<br>
<jarhar> anne says 1/3<br>
<lea> `<button type=interest">` was also mentioned<br>
<bkardell> nobody didn't vote for 1<br>
<jarhar> anne says 1 OR 3<br>
<emilio> 1 + 4 | 2 | 3 :)<br>
<keithamus> I am saying 1 _and_ 3.<br>
<lwarlow> Using button doesn't work either because you can't nest buttons at the parser level btw<br>
<lea> Could it be a command type? Then the natural fit is `<button>`<br>
<bkardell> !1<br>
<lea> But again, that makes it opt-in, before we have consensus on whether that's desirable<br>
<jarhar> masonf: im going to conclude that pseudo element wins<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-4215452595 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 9 April 2026 15:31:13 UTC