- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 11 Jun 2026 15:36:12 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``Should `::interest-button` be opt-in, opt-out, or enabled via media query?``, and agreed to the following: * `RESOLVED: use an inline media condition (display: if(media())) to enable the pseudo element on systems where it makes sense, such as touchscreen.` <details><summary>The full IRC log of that discussion</summary> <jarhar> masonf: *summarizes issue*<br> <lwarlow> q+<br> <keithamus> q+<br> <JohnJansen> ack lwarlow<br> <jarhar> lwarlow: tags feedback is its always on or its on on touch screens. the one we dont want is where its off always<br> <jarhar> lwarlow: i think thats fine. i think the spec should give UAs the freedom to enable or disable it<br> <jarhar> lwarlow: on vision os you might not match the thing for touch screens<br> <jarhar> lwarlow: or maybe theres a user setting for this<br> <jarhar> lwarlow: i dont think there is breakage from this<br> <jarhar> lwarlow: the situation where you have this button or link and it gets slightly bigger than you expected and suddenly the whole layout breaks is not realistic<br> <masonf> qq+<br> <jarhar> lwarlow: users can already translate stuff in their browsers, and if the localized text breaks it<br> <jarhar> lwarlow: i wouldnt really care about that<br> <jarhar> lwarlow: at the end of the day if theres a bit of overflow layout the sites still going to be usable<br> <jarhar> lwarlow: i think it being on touch and not desktop is the right balance<br> <jarhar> lwarlow: people testing it will find it and be like oh its on touch screens that makes sense<br> <jarhar> lwarlow: at the end of the day, if people put this in reset stylesheets and it never shows up anywhere, UAs can still force enable it<br> <dbaron> I think websites 20 years ago were mostly that fragile (layout breaking for small size-of-text differences), but I think things are quite a bit better today.<br> <jarhar> lwarlow: the ones that care about users can do what they want behind a pref<br> <jarhar> lwarlow: i think its the right balance<br> <jarhar> lwarlow: i personally dont care if the old website breaks, they should update their website<br> <Zakim> masonf, you wanted to react to lwarlow<br> <JohnJansen> ack masonf<br> <jarhar> masonf: on the tag review, i made a suggestion that we could make the media query a new one. showing interest is hard in certain circumstances<br> <jarhar> masonf: that would be a mechanism to make this developer controllable and observable<br> <jarhar> masonf: 20 year old sites wont use interestfor<br> <jarhar> masonf: the mechanism of breakage depends on the other issue. my latest proposal there is to use absolute positioning with anchor positioning wont break any layout. i hope if theres any breakage it would be minimal<br> <JohnJansen> ack keithamus<br> <jarhar> keithamus: i would be swayed more towards the opt out because i agree opt in is as good as not shipping<br> <jarhar> keithamus: the thing that would be potentialy surprising about the media query is the lack of precedent in media queries appearing in ua sheet<br> <jarhar> keithamus: i dont think we have ones besides print and internal ua ones. i dont think we have anything thats media hover<br> <jarhar> keithamus: were kind of doing somethign new there. i wonder how developers would be able to reconcile with that<br> <lwarlow> q+<br> <jarhar> keithamus: will that be discoverable for developers?<br> <jarhar> keithamus: the counterargument for that is if everyone turns it off then it isnt a sensible default<br> <jarhar> keithamus: we have shipped plenty of things that dont have sensible default or that people change anywawy<br> <jarhar> keithamus: i dont know if thats a sensible counterargument<br> <masonf> We've been doing it badly for decades, let's continue...? :-)<br> <jarhar> keithamus: were not in a world where people ship a website without actually changing any css<br> <jarhar> keithamus: if theyre using this feature its likely theyre going to use css anyway<br> <masonf> q+<br> <jarhar> keithamus: it would be better if they see it on desktop and change it than be surprised when they look at it on a phone<br> <jarhar> keithamus: theres a lot of people who are good developers who manage to do this correctly and develop for all devices, but i think theres a large cohort who only develop on one device, and we do need to cater for them<br> <jarhar> keithamus: in that case, opt out is better<br> <jarhar> keithamus: if they test on mobile and dont have the ability to debug<br> <jarhar> keithamus: maybe this is a thing for devrels<br> <jarhar> keithamus: how easy would this actually be if we have a media query<br> <jarhar> keithamus: the average developer might find it tricky<br> <masonf> display: if(media(hover:hover): none; else: inline-block);<br> <JohnJansen> ack masonf<br> <jarhar> masonf: its very easy to override this, its not an explicit media query<br> <jarhar> masonf: in my view, its very straightforward. if you set display then you get what you want<br> <jarhar> masonf: youre right, majority of developers develop on the screen their on<br> <jarhar> masonf: theres two forms of breakage<br> <jarhar> masonf: on the one scenario, they dont notice that mobile users cant use the thing. in the other scenario, the layout looks a bit funny<br> <jarhar> masonf: we should focus on the user problem, priority of constituencies<br> <jarhar> keithamus: in this scenario, youre imagining a developer opting out and opting out for all devices<br> <jarhar> masonf: an opt out becomes an opt in because of reset stylesheets<br> <jarhar> keithamus: i didnt realize it was a rule rather than a media query<br> <jarhar> keithamus: how settled is the if condition stuff? i know we havent implemented<br> <jarhar> masonf: yes i think we have shipped it<br> <jarhar> masonf: if it was a regular media query then id agree its hard to figure it out<br> <jarhar> masonf: an inline rule like this seems easier to understand<br> <jarhar> lwarlow: yeah i think it shipped in chrome. its in a css spec<br> <jarhar> lwarlow: the if is very nice. it makes it much easier to override<br> <jarhar> lwarlow: the downside is that it does require browsers to have css if<br> <jarhar> lwarlow: i dont know how big of a pull it was for chromium to implement<br> <jarhar> lwarlow: we've done it before. appearance base requires calc size for example<br> <jarhar> keithamus: with the if its definitely more tolerable. its hard to predict, you mentioned the reset - i could see a reset hitting this anyway<br> <jarhar> keithamus: its difficult to know what the right choice is here<br> <JohnJansen> ack lwarlow<br> <jarhar> lwarlow: chrome might not handle the media query in the ua stylesheet, but if youre using the if statement then thats solved. does the if work with user preference media queries?<br> <jarhar> masonf: i imagine yes but idk<br> <jarhar> lwarlow: that might make me be able to ship inverted colors in chrome<br> <jarhar> masonf: i think its perfectly fine to depend on new things<br> <jarhar> masonf: this feature is dependent on another feature that isnt shipped anywhere else either<br> <jarhar> keithamus: is your preference the media query?<br> <jarhar> masonf: yes<br> <jarhar> keithamus: we can resolve on that until we unresolve on that<br> <masonf> Proposed resolution: use an inline media condition (display: if(media())) to enable the pseudo element on systems where it makes sense, such as touchscreen.<br> <lwarlow> +1<br> <jarhar> lwarlow: theres some intelligence with media queries, if you switch between touch and mouse<br> <jarhar> masonf: it is possible on vision os, you can hover but you dont want to - theres another way that makes it easier, so you dont want this button<br> <masonf> RESOLVED: use an inline media condition (display: if(media())) to enable the pseudo element on systems where it makes sense, such as touchscreen.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13980#issuecomment-4682270794 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 11 June 2026 15:36:13 UTC