- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 08 Jan 2026 16:50:07 +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> <jarhar> masonf: *explains new pseudo-element*<br> <jarhar> masonf: i havent heard pushback on the mechanics and name etc.<br> <jarhar> astearns: you said this was ok for a11y because theres a different way to get to it via keyboard, but you just said that the touch screen affordance would not invoke the same click of the elemenet<br> <jarhar> masonf: with keyboard, keyboard focus is the thing to show interest in something<br> <jarhar> masonf: the thing i mentioned about the click is that you dont want the click to navigate the page, you want the click to just show interest<br> <masonf> q?<br> <jarhar> astearns: any webkit objection to this?<br> <jarhar> annevk: our objections: one is that this far we dont like interest invokers, i think thats clearly documented<br> <jarhar> annevk: were also concerned about the new pattern or at least the pseudo elements being proposed that have behavior that was before restricted to ordinary elements<br> <jarhar> annevk: as we go down that path, there will be more and more special cases such as the event handling that mason mentioned, but other things people will want to do<br> <jarhar> annevk: ordinary elements give people flexibility and pseudos do not<br> <jarhar> annevk: people will gradually get more and more requests for pseudo elements which theyre not designed for<br> <jarhar> masonf: first point about not liking interest invokers, i thought the stated reason for that was that they dont support touch or ar, and the entire proposal is a simple way to support those<br> <jarhar> masonf: if so, can we talk about this as a solution to that problem?<br> <jarhar> masonf: for the new pattern, the css resolution was to create a new element to do this, and we talked about that a lot, and after discussion with a11y is that its a footgun in most cases, but its not supposed to be a button<br> <jarhar> masonf: it should behave like a span with an onclick handler<br> <jarhar> masonf: their feeling is that a magic pseudo which does the right thing in this one case was much better for the developer<br> <jarhar> masonf: thats why we came back to css and talked about it 3 more times<br> <jarhar> lwarlow: the button not being a real button is not completely unique to this scenario. the increment decrement button in number inputs are essentially that. its a pattern that does exist in other pseudo elements. i am in agreement that we shouldnt try to make pseudo elements become real. if someone wants to know if they pressed this, theres<br> <jarhar> probably another mechanism<br> <jarhar> q+<br> <jarhar> lwarlow: i think css carousels and those pseudo elements i think are bad and would be bad if we try to do that again<br> <jarhar> lwarlow: i think it very much is, heres a click handler you can touch<br> <astearns> q+<br> <jarhar> lwarlow: in css you can decide what you want to do with media queries<br> <jarhar> lwarlow: i think that aspect is ok. this is just a little pseudo element that do what pseudo elements do<br> <jarhar> lwarlow: on that thing of people wanting to do more interesting things, they can already make command invokers which do what this button does<br> <jarhar> lwarlow: if they need something more complicated they can do it that way<br> <jarhar> lwarlow: i dont think this is a particularly weird pseudo element<br> <emilio> q+<br> <jarhar> masonf: increment decrement buttons are a great example, a11y reasons are the same<br> <astearns> ack jarhar<br> <emilio> jarhar: re the event path and pseudo elements we have text to detect whether the ::backdrop is clicked using the coordinates<br> <jarhar> astearns: not having followed the html discussions<br> <smaug> q+<br> <jarhar> astearns: is it possible that discussion got hung up on a button element being the wrong affordance for this? can we take this back to html and talk about another element that has this click handler but was not in other ways like a button?<br> <lwarlow> q+<br> <jarhar> masonf: we did not talk about a new element<br> <astearns> ack astearns<br> <jarhar> masonf: the pushback would likely be that this is a very specialized element<br> <jarhar> masonf: my question would i guess be, theres one use case<br> <jarhar> masonf: theres up and down buttons on a number input<br> <jarhar> masonf: it would not be a good idea to make a number step up element and number step down element<br> <astearns> ack emilio<br> <jarhar> emilio: my concern with the argument is that the number pseudo apply only to input type number<br> <jarhar> emilio: it does feel really weird to add a very generic pseudo element which has its own performance and such implications, just for this specific thing which can be handled - i think we should add an imperative api for this<br> <jarhar> emilio: the pseudo has two issues: its very limited in what you can do with it, only use the content property. im sure authors will want to do more. we also have to define what do to with the contenet property, since it behaves differently for before and after<br> <jarhar> emilio: this is both limited and general, and to me it feels like the wrong thing to do for this very specific thing<br> <jarhar> emilio: i just dont agree that this is parallel to the number spinners<br> <jarhar> masonf: my mental model of pseudo elements is that they are the special cases<br> <jarhar> masonf: there are pseudos for those buttons because they are special, just for the number input. theres picker-icon which only applies to select in base mode<br> <jarhar> masonf: this is another one of those special cases just for interest invokers<br> <jarhar> masonf: it feels very similar to the other pseudo elements, its a part of another control which does somethign special in a special case<br> <jarhar> emilio: the layout of select and button are not always in control of the developer<br> <jarhar> emilio: i know we are changing it actively, but the - on one hand, i wasnt aware that this would only apply to buttons and links, but this is generated content<br> <jarhar> emilio: generated content pseudos are different from spinners. you need to resolve style for them regardless<br> <jarhar> emilio: links and buttons are pretty common<br> <jarhar> emilio: i still feel like its not the right thing<br> <jarhar> masonf: its only on links and buttons which have the interestfor attribute<br> <jarhar> astearns: whether this is special case enough may be a rabbit hole that isnt necessary to resolve this<br> <astearns> ack annevk<br> <jarhar> annevk: i just wanted to know if there is some updated explainer for the whole idea around interest invokers that includes these new aspects<br> <jarhar> masonf: yes<br> <masonf> explainer: https://open-ui.org/components/interest-invokers.explainer/<br> <jarhar> annevk: maybe mason is right and there is something to re-evaluate, i want to make sure that we do that<br> <astearns> ack smaug<br> <lwarlow> Does that explainer have the pseudo element in it though?<br> <masonf> (search for ::interest-hint, the name hasn't been updated)<br> <smaug> let me ask here<br> <smaug> yeah, sure<br> <smaug> My worry is the special click event handling<br> <smaug> Inconsistencies will bite us later, always<br> <jarhar> masonf: yeah it is special. its special in order to get the behavior right, but it is special<br> <astearns> ack lwarlow<br> <jarhar> lwarlow: should this be html element or not: i think making a new element to do this thing is not the correct idea<br> <jarhar> lwarlow: i think we would be much better off giving a js api<br> <annevk> masonf, that doesn't mention ::interest-button anywhere<br> <jarhar> lwarlow: its opt in, so its not something we need necessarily to be always available<br> <jarhar> lwarlow: the html elemnt would get misused<br> <jarhar> lwarlow: the input up down buttons, its quite nice to have those on touch screen<br> <jarhar> lwarlow: if we did want some way for users to do this themselves, we already have js apis for step up step down<br> <jarhar> lwarlow: if we want an escape hatch, they can go build it<br> <masonf> annevk, see my comment above: (search for ::interest-hint, the name hasn't been updated)<br> <jarhar> lwarlow: we could do something special which is commnand invokers. we could set up commands for step up step down, we could make those command invokers not focusable<br> <jarhar> lwarlow: we could do the same thing here for showing interest<br> <jarhar> lwarlow: could be a special new command<br> <jarhar> lwarlow: do we want this special keyboard behavior being triggered by commands, and the answer is probably no<br> <masonf> q+<br> <jarhar> lwarlow: but that is a possibility<br> <jarhar> lwarlow: commandfor changes the submission behavior for implicit submit buttons<br> <jarhar> lwarlow: making them not focusable would be quite a big difference but not impossible<br> <jarhar> lwarlow: still preferrable to have a js api though<br> <astearns> ack masonf<br> <jarhar> masonf: we did talk about command invokers for a number of reasons you mentioned, they sounded like a good idea at first but theyre very confusing because it would be a 2 step command invoker<br> <jarhar> masonf: the reason im proposing it the way i am now is that i want it to be easy for developers to use and therefore good for users<br> <jarhar> masonf: putting it in html and adding a new command invokers, either involve a lot more magic - if you made this a command it would be a button element that is not focusable and has different activation behavior - its a lot more work and some fraction will get it wrong and users will be harmed<br> <jarhar> masonf: doing it in css makes it trivial to use, so most users will be happy. thats what i think we should be focusing on<br> <astearns> ack fantasai<br> <jarhar> fantasai: question for luke: what do you think the js api would do? is it for generating an element? do you have to create your own element?<br> <jarhar> lwarlow: it would be an api on either the interest invoker or the thing youre showing interest in. we have showpopover which kind of does what interest invokers are doing. interest has the concept of gaining and losing interest, but it might be that its just show popover and we already have them<br> <masonf> I think the idea is `<span onclick=anchor.showInterest()> ? </span><br> <jarhar> lwarlow: yeah what mason put<br> <jarhar> lwarlow: the actual element itself is fairly meaningless, should potentially be hidden from AT<br> <jarhar> lwarlow: the increment decrement buttons are tabindex=-1 and aria hidden<br> <jarhar> lwarlow: thats essentially what youd want it to be<br> <masonf> q+<br> <jarhar> lwarlow: thats a possibility<br> <jarhar> lwarlow: in the same way that today you can make stylable up down buttons<br> <masonf> yes a span, no not a button<br> <jarhar> fantasai: we would add a show interest js api which seems reasonable, and that the solution to the problem is that authors would have to create a span or button, add a click handler, hook it up to the correct element that is the thing youre showing interest in using IDs, and then also set the aria correctly and the tabindex correctly in order to<br> <jarhar> get the a11y behavior correct. is that right?<br> <emilio> `<span onclick="this.parentNode.triggerInterest(); return false">Your thing</span>`<br> <jarhar> lwarlow: yes. i didnt say it was a good idea, just an idea<br> <jarhar> fantasai: having a js api seems like a good idea, but not sure if its going to solve the problem mason is trying to solve<br> <masonf> q-<br> <jarhar> lwarlow: the pseudo element idea here is probably the best solution for this problem based on goingn through the iterations on the ideas<br> <jarhar> lwarlow: that depends on whether you think this is a problem that needs solving<br> <jarhar> fantasai: or creating a new html element<br> <emilio> q+<br> <jarhar> fantasai: if you put that new element inside an interest invoker, then it does the right thing<br> <jarhar> lwarlow: fairly niche element, but make it not do anything else elsewhere<br> <jarhar> astearns: anne you had asked for an explainer and noticed that the interest thing wasn't showing up there, its called interest hint<br> <jarhar> masonf: i am going to rename it<br> <astearns> ack emilio<br> <jarhar> emilio: depending on how we build the js api, it might not be all that terrible<br> <jarhar> emilio: if you add the api to button or showpopover, you would have showinterest on the button or the link, wouldn't it just be a one liner?<br> <masonf> q+<br> <jarhar> masonf: the code snippets would work<br> <jarhar> masonf: the issue is that a developer might decide to use a button instead, or they have to weigh the span against a11y documentatin that makes it look bad<br> <jarhar> emilio: to me it feels like you can add a comment, thats one more line<br> <jarhar> emilio: the js api does solve this, and were sure that we see it everywhere, then maybe that warrants adding more stuff<br> <lwarlow> Or it's long press<br> <jarhar> masonf: this is the only pattern you see on touch today. what we found in our searching is that this behavior is not available to touch screen users, but when it is this is the way they do it<br> <jarhar> masonf: long press exists in native but yeah not on the web because people like the native context menu<br> <astearns> ack masonf<br> <astearns> ack fantasai<br> <jarhar> fantasai: i want to emphaisze masons point that we have to make this so straightforwards that authors wont get it wrong<br> <jarhar> fantasai: i dont know what the right answer is here, but build it from primitives and not get confused and get it right - we need to make sure that theres one obvious path<br> <jarhar> fantasai: what theyre breaking is not something that theyre aware of<br> <jarhar> fantasai: they might not be thinking about it at all<br> <jarhar> fantasai: what masons trying to do is to funnel them down this route<br> <masonf> well said, thank you<br> <jarhar> fantasai: idk if pseudo element is the right answer or not, but i think build it out of js and span and make sure etc. is not going to work from a developer education<br> <fantasai> s/make sure/make sure not to use <button> or links, and don't forget tabindex/<br> <smaug> FWIW, special click event handling is rather major concern from my side.<br> <jarhar> astearns: we've had a good discussion, anne will read explainer. emilio, what would it take to get past your concerns?<br> <jarhar> emilio: i dont think it would be a hard objection, but if we add this pseudo to buttons and links<br> <jarhar> emilio: people on the web do a lot of complex stuff without adding pseudos for everything<br> <jarhar> emilio: i dont think i would have a strong objection, i just think its the more complicated approach, somewhat unnecessarily complicated<br> <jarhar> fantasai: i agree, using a pseudo does feel awkward for other reasons you brought up<br> <jarhar> fantasai: when you have a pseudo element, you have a specific place in the tree and it cant move from there<br> <jarhar> fantasai: authors might want to put something after instead of before<br> <jarhar> fantasai: with the pseudo element approach they might not have that flexibility<br> <jarhar> fantasai: i also sympathise with implementation complexity<br> <jarhar> fantasai: im not convinced this is the right solution, but i do think that mason has described the problem well, and that we cant make people build this out of primitives because they'll get it wrong<br> <jarhar> fantasai: something with more flexibility in where you put it makes sense<br> <jarhar> fantasai: i think form controls theyre a little bit different from a lot of this stuff that we're doing. the pseudos there represent part of - form controls were originally pseudo replaced elements, and its not a real css tree that is transparent to the document, even with appearance base, and very structured. form element has these parts and<br> <jarhar> theyre organized like this. for something like this, its more fluid and flowing to the content. having it be a psuedo element that is always in this part of the tree<br> <jarhar> fantasai: what is it capable of doing is also i think going to be a problem<br> <jarhar> astearns: perhaps the solution could be an attribute on the span element<br> <jarhar> astearns: that gives you this special behavior for this span thats in the right place in the tree<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-3724751701 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 8 January 2026 16:50:08 UTC