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``, and agreed to the following:

* `RESOLVED: leave the pseudo element as a child in the layout tree. And position it after ::after.`

<details><summary>The full IRC log of that discussion</summary>
&lt;jarhar> masonf: *summarizes issue*<br>
&lt;lwarlow> q+<br>
&lt;astearns> ack lwarlow<br>
&lt;jarhar> lwarlow: do you have screenshots of the proposed ua styles?<br>
&lt;jarhar> masonf: i will do that<br>
&lt;jarhar> lwarlow: i feel like this would look nicer outside of the buttons border but thats not doable with css<br>
&lt;jarhar> masonf: im glad you brought that up, i agree, but i also dont know how to do it<br>
&lt;astearns> ack fantasai<br>
&lt;jarhar> fantasai: we probably want to make this look circular rather than potentially a rounded rectangle, so i would say border-radius:50% even though thats not what buttons do<br>
&lt;fantasai> https://www.fileformat.info/info/unicode/char/24d8/index.htm<br>
&lt;jarhar> fantasai: or you could not use a border and just use this character<br>
&lt;lwarlow> Can we do layout siblings via pseudo-elements?<br>
&lt;jarhar> masonf: i tried border-radius:50%, and you get an oval instead of a circle depending on the character you use<br>
&lt;jarhar> fantasai: aspect-ratio:1?<br>
&lt;jarhar> masonf: i tried that too<br>
&lt;jarhar> fantasai: or size it as a 1em square<br>
&lt;jarhar> masonf: thats probably the solution<br>
&lt;jarhar> astearns: yes except i wonder if theres any localization people might want to do, where question mark isnt the appropriate character for the locale, and whatever is used in another language might not work<br>
&lt;lwarlow> q+<br>
&lt;jarhar> fantasai: most characters fit in a 1em square<br>
&lt;jarhar> masonf: if its a unicode character, presumably thats internationalized already<br>
&lt;astearns> ack lwarlow<br>
&lt;jarhar> lwarlow: 1em will that be enough for touch screens?<br>
&lt;jarhar> lwarlow: i think the button already has a minimum sizing in appearnace base, but that doesnt affect the font size<br>
&lt;bkardell> s/appearnace/appearance<br>
&lt;jarhar> lwarlow: in appearance:auto you wont get that. we probably want to make this minimum 24x24px<br>
&lt;jarhar> astearns: right now it has max of 1lh<br>
&lt;keithamus> q+<br>
&lt;jarhar> lwarlow: 1lh is for empty select<br>
&lt;astearns> ack keithamus<br>
&lt;lwarlow> q+<br>
&lt;jarhar> keithamus: is there any criteria about it being close to other buttons and given that its inside a button<br>
&lt;jarhar> keithamus: theres some criteria about intersecting targets, it might need a margin for intersecting targets<br>
&lt;jarhar> keithamus: worth looking at more closely<br>
&lt;jarhar> masonf: there is a margin, but this pseudo button thing is inside of the existing button in the case of the button invoker. if theres a way to fix that, thats great<br>
&lt;jarhar> masonf: it is effectively a button inside of a button right now<br>
&lt;jarhar> lwarlow: is there a css spec way to do sibling pseudo elements?<br>
&lt;jarhar> lwarlow: rather than child<br>
&lt;jarhar> lwarlow: ideally this is a sibling and would be outside of the buttons padding border box etc<br>
&lt;jarhar> lwarlow: that to me is what this would look like in my head<br>
&lt;jarhar> lwarlow: i think that helps you with the spacing and nesting buttons<br>
&lt;jarhar> lwarlow: it feels to me like you need to handle the activation behavior on this thing so it doesnt bubble<br>
&lt;jarhar> masonf: yes that has to happen either way, but i like what youre saying about a sibling instead of a child<br>
&lt;jarhar> keithamus: i guess you could position:absolute and use anchor, but maybe thats too messy for a ua sheet<br>
&lt;jarhar> masonf: that is one thing that crossed my mind in the existing box structure, i think it would work<br>
&lt;jarhar> masonf: its a lot more css to override if you want to change that stuff<br>
&lt;jarhar> masonf: is there a way that could happen? make it a sibling instead of a child?<br>
&lt;jarhar> fantasai: we havent done that yet. even ::marker is a child even though its positioned outside of the box<br>
&lt;jarhar> masonf: how is it outside the box?<br>
&lt;jarhar> fantasai: magic<br>
&lt;jarhar> ntim: i think thats linked to list-style-type outside<br>
&lt;jarhar> ntim: marker is a child in the tree, list style type outside has some magic to it. list style type inside makes it normal<br>
&lt;jarhar> astearns: perhaps we should use list style type outside for this?<br>
&lt;jarhar> ntim: i dont know if that would behave as expected. its more like a negative margin<br>
&lt;jarhar> fantasai: pulled it out of flow which might be suprising for inline content like this<br>
&lt;bkardell> ack no<br>
&lt;jarhar> fantasai: we did discuss having list style type inside for inline markers<br>
&lt;lwarlow> The out of flow would be the case for anchor positioning too so same issue<br>
&lt;bkardell> that sounds better to _me_<br>
&lt;jarhar> fantasai: which would take it out of the box and put it in front, but we didnt end up pursuing it<br>
&lt;jarhar> masonf: between the magics, is there a preference? pseudo that is a sibling or list style magic? ill go down both paths, im just curious whats more amenable<br>
&lt;emilio> q+<br>
&lt;jarhar> fantasai: good question for emilio<br>
&lt;jarhar> fantasai: are you sure you want to take it out of the thing? lets say you have a colored button and this is the tapped target for hover checking, how would the author know its associated? how do you actually want to style this<br>
&lt;jarhar> fantasai: if its a sibling, lets say its a heading<br>
&lt;jarhar> fantasai: you would want the little icon to be associated with the heading attached o it<br>
&lt;jarhar> masonf: these are only present on links and buttons. in that example the heading would have to be a link<br>
&lt;astearns> ack lwarlow<br>
&lt;jarhar> lwarlow: the problem with the ancohr positioning thing and the currently style outside is that it takes it out of document flow, and i dont think thats what we want<br>
&lt;bkardell> no that sounds icky<br>
&lt;jarhar> lwarlow: we want this to create a box around the button plus this, so that it takes up space that is otherwise outside of the box itself<br>
&lt;jarhar> fantasai: like the way that the caption it outside of the table box?<br>
&lt;jarhar> lwarlow: i think so yes<br>
&lt;jarhar> lwarlow: we want it to take up space on the page, we dont want it to be overlapped, but we also dont want it to be inside of the buttons layout<br>
&lt;jarhar> lwarlow: if there isnt a way to do that then maybe we have to create it<br>
&lt;jarhar> lwarlow: i dont know how to do that in such a way that the colors still inherit<br>
&lt;jarhar> lwarlow: maybe this gets too complicated<br>
&lt;jarhar> lwarlow: if you have a link thats styled like a heading then youd want the button to be bigger<br>
&lt;jarhar> fantasai: if you inherit the color then it will match and thats nice, but if you inherit and the button has inverted color scheme, then you could have white text on white background<br>
&lt;keithamus> q+<br>
&lt;jarhar> fantasai: probably the simplest thing is just to make it stay inside and let the author do any manipulation they want<br>
&lt;astearns> ack emilio<br>
&lt;jarhar> emilio: i agree with keeping it in flow<br>
&lt;jarhar> emilio: authors know how to style ::after pseudo element<br>
&lt;jarhar> emilio: the only potential drawback for in flow is that links have text decoration. if you have trailing whitespace on the link then you get whitespace that is underlined<br>
&lt;jarhar> emilio: if you have ?? that blocks propagation<br>
&lt;jarhar> emilio: authors can remove the space and take it out of flow if they want<br>
&lt;astearns> s/??/display:inline-block/<br>
&lt;jarhar> emilio: i think saying it defaults to display inline block and it goes at whatever point in the subtree i think thats the easiest suggestion<br>
&lt;jarhar> emilio: otherwise it has to be a sibling and that is bad<br>
&lt;jarhar> emilio: making it regular generated content is simplest<br>
&lt;astearns> ack keithamus<br>
&lt;jarhar> keithamus: we need to think about a11y tree in relation to this, the role might need to change. maybe youve already had that conversation<br>
&lt;jarhar> masonf: thats why were doing a pseudo element, its not in the a11y tree, its aria hidden<br>
&lt;jarhar> keithamus: thank you<br>
&lt;lwarlow> Yeah I buy that argument. Provided the a11y folks are onboard with styles we come up with.<br>
&lt;jarhar> astearns: we could resolve the ua style list that mason proposed and bring up other issues about looking like a sibling or the roundness<br>
&lt;jarhar> astearns: or we could have mason generate some screenshots and make a few changes and come back to this issue again<br>
&lt;jarhar> masonf: i heard agreement on after ::after, and leave it inside the button and leave it to the author to position it out<br>
&lt;masonf> Proposed resolution: leave the pseudo element as a child in the layout tree. And position it after ::after.<br>
&lt;lwarlow> +1<br>
&lt;bkardell> +1<br>
&lt;masonf> RESOLVED: leave the pseudo element as a child in the layout tree. And position it after ::after.<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-4354054738 using your GitHub account


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

Received on Thursday, 30 April 2026 16:01:48 UTC