- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 15 Sep 2023 11:01:26 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[mediaqueries-5] Script control of (prefers-*) queries`, and agreed to the following: * `ACTION(fremy): Look at the proposal, see whether there's an issue to be filed` * `ACTION(TabAtkins): Determine if prefers-reduce-data is handled` <details><summary>The full IRC log of that discussion</summary> <myles> Topic: [mediaqueries-5] Script control of (prefers-*) queries<br> <myles> github: https://github.com/w3c/csswg-drafts/issues/6517<br> <myles> TabAtkins: some time ago i opened this issue so it would be useful to allow script control of the prefers media queries. simple case: if you were doing a dark mode toggle on your site (explicit switch) independent of their UA/OS, it's awkward to style<br> <myles> TabAtkins: you want to be able to pay attention to people's OS styles when their OS preferences when they haven't indicated a preference, but use the toggle when they have.<br> <myles> TabAtkins: Writing styles based on when a class in HTML exists is awkward. The examples are terrible, you have to repeat yourself<br> <myles> TabAtkins: The most straightforward way to fix this is to allow people to directly control the media query<br> <myles> TabAtkins: There are some routes to address some aspects of this problem<br> <myles> TabAtkins: Another option: a media pseudoclass. so you could name that in the block. But that would just solve one problem<br> <myles> TabAtkins: A person posted a proposal for the API for controlling this. He gives a great example of multiple problems we solve by this.<br> <astearns> https://github.com/WICG/proposals/issues/117<br> <myles> TabAtkins: Namely: IF you want to a dark mode toggle by the user, it would be great if you could use this for stylesheet loading. right now, that wouldn't work.<br> <TabAtkins> https://github.com/lukewarlow/web-preferences-api/blob/main/README.md<br> <myles> TabAtkins: Any of the media matches API, it would be good to have it respond appropriately<br> <myles> TabAtkins: I think this looks good<br> <myles> TabAtkins: I think what's in the proposal is good<br> <myles> TabAtkins: It can be iterated on<br> <myles> TabAtkins: We should take it to any group to iterate and adopt it appropriately<br> <bramus> q+<br> <myles> TabAtkins: The main question: Does solveing this problem sound sufficiently useful to the group? Is the rough shape (a JS API where you explicitly control the media queries for your site and descendent frames) reasonable?<br> <myles> TabAtkins: There's an implied persistence model here: Once you set the toggle, it stays toggled (so you don't have re-up the toggle on the next load)<br> <emilio> q+<br> <myles> TabAtkins: _how_ persistent it should be is worthy of discussion. But it's should be able to toggle and keep it toggled for future visits<br> <myles> TabAtkins: is this the right direction? Should we take it? Should we send it to webapps?<br> <astearns> ack bramus<br> <myles> bramus: I'm a big fan of this proposal. Authors are having this problem.<br> <myles> bramus: Right now authors need to duplicate a bunch of their CSS<br> <myles> bramus: They also need more blocking JS on page load<br> <myles> bramus: it would be really nice to get this<br> <myles> bramus: For the CSS-only type of approach where you have your setting and your override, setting the preference inside the browser ... <missed> already has this, it has an override built in<br> <astearns> ack emilio<br> <myles> emilio: I see a point to override the color scheme. At the end of the day that's a user preference but it's not a hard preference. I'm not sure I agree overriding things like contrast-preference, reduced-motion, etc.<br> <ntim> +1 to emilio<br> <astearns> +1 to emilio<br> <myles> emilio: Those don't seem equally useful. Those are a11y preferences we expose so the page can react to that. There's no use case<br> <bramus> q+<br> <myles> TabAtkins: Remember these media queries are optional to pay attention to. The author can not look at them and do whatever they want. There is nothing that does a dang thing if the author doesn't want it. Nothing here reduces the ability for the user to communicate to the page or for the page to render different things. This is just for letting the user have a per-page toggle<br> <myles> TabAtkins: "This page is extra-wiggly" and let the user opt-into lower motion even if the user wouldn't have the global value set<br> <myles> emilio: Some other preferences (reduced-data) affect stuff like what headers the browsers send<br> <myles> emilio: there's no mention of that stuff<br> <myles> TabAtkins: Reduced-data isn't in the proposal<br> <myles> emilio: yeah it is<br> <myles> TabAtkins: i missed that<br> <myles> TabAtkins: i'm happy to iterate on this for what ones will apply<br> <myles> TabAtkins: That is not unreasonable bit of feedback<br> <myles> emilio: it feels sketchy to override prefers-reduced motion<br> <jasew1> Is there an option to keep this API shape but with reduced preferences? It seems we all agree about colorScheme for example but maybe not some others<br> <astearns> ack dbaron<br> <ntim> q+<br> <astearns> jasew1 yes, there is definitely time/space to iterate and refine<br> <myles> dbaron: it seems like with a bunch of these things, there's potentially a user-agent is doing other things with these things. things like prefers-reduced-motion, the UA does things that are not queryable.<br> <emilio> q+<br> <myles> dbaron: one thing that should be clear in the proposal is "is this about only affecting the reflection of these preferences to the site, or is this also about affecting other things"<br> <myles> dbaron: A) if it's just about reflection of the preferences to the site, there isn't a problem with things that use data. it just doesn't have the other effecets. But if it IS about changing other things, thn it's more complicated<br> <myles> TabAtkins: we've discussed these things, like automatically reducing motion if the prefence is enabled.<br> <vmpstr> q+<br> <fremy> q+<br> <myles> TabAtkins: I thought we were not going to do that, or reflect it in a forced media query<br> <dbaron> s/things that use data/prefers-reduced-data/<br> <jasew1> q+<br> <bramus> q-<br> <myles> myles: My recollection is that we decided not to automatically try to reduce motion<br> <myles> dbaron: There may actually be value for the site to provide a setting that's easier to get to than the OS setting<br> <astearns> ack ntim<br> <myles> ntim: are the overrides persistent?<br> <myles> TabAtkins: They are persistent. next time you visit the page, they will be applied<br> <myles> ntim: if you clear storage, will that clear the override?<br> <myles> TabAtkins: That is a question that we should answer.<br> <myles> TabAtkins: it's an open question.<br> <myles> TabAtkins: By default, when there's no clearing going on, the user is going to want the same setting<br> <myles> ntim: i don't think we should make it persistent<br> <myles> q+<br> <myles> TabAtkins: if it's not persistent, you have to have a blocking script at the top of the page, and store it somewhere (in a cookie)<br> <nicole_> q+<br> <myles> TabAtkins: defeats most of the difficulty of doing this<br> <astearns> ack emilio<br> <astearns> ack vmpstr<br> <myles> vmpstr: i think defining exactly who can see this change is important. can UA style sheets see this?<br> <emilio> q+ to say that reduced-motion has various side effects in Firefox<br> <myles> vmpstr: i'm questioning the persistence. How you define this ... <missed><br> <myles> vmpstr: there needs to be some signal to say "yes ... <missed>"<br> <myles> TabAtkins: We should give a consistent answer for what value a media query's answer is, regardless of what's querying it. otherwise it's weird.<br> <myles> TabAtkins: For iframes, exactly what the passdown behavior is needs to be iterated on. But if you already have a communicatino channel (or if there isn't one), then we pass the preference down. otherwise, it sees the user's origial preference<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to react to vmpstr to comment that UA stylesheets should be reflecting color-scheme not prefers-color-scheme<br> <myles> TabAtkins: Goal: Don't open new communication channels, but respect the ones that exist<br> <myles> fantasai: i don't think there are places in the UA stylesheet where we are or should be making it conditional on prefers-color-scheme. Rather we should be doing it based on the color-scheme property<br> <myles> TabAtkins: Yeah but the other prefers-* are still fair game<br> <astearns> ack fremy<br> <myles> TabAtkins: a UA animation could conditionalize on prefers-reduced-motion<br> <myles> fremy: i have 2 comments<br> <vmpstr> s/this ... <missed>/what "the page is", if the page changes that there is a dark mode, it persists forever/<br> <myles> fremy: 1. I am of the opinion that if a user wants to use a dark mode on a website, they should communicate that to the UA<br> <ntim> +1 to fremy<br> <myles> +1 to fremy<br> <vmpstr> s/yes ... <missed>/I'm still dark mode/<br> <myles> fremy: If you want ot have a UA in chrome that applies dark mode to different pages, do it<br> <myles> fremy: I'd prefer that<br> <myles> fremy: If the website changes, and don't provide the feature any more, how is the user going to get the behavior any more?<br> <astearns> q?<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <myles> fremy: It would make more sense. It's fine if there's an API the site can poll to popup the browser's UI or something, but at least as the user you are basically interacting with the user agent. that makes more sense.<br> <myles> fremy: Another way of doing this is to add a custom media query. If you don't want to say this is a UA behavior, why not just create a custom media query whose value is based on the OS's MQ, but you can change it<br> <myles> fremy: But we should make the UA in control of this.<br> <myles> TabAtkins: Regarding to UA: No user-agent has seen fit to stuff it into the UI. I don't want to rely on that being a thing they do. I suspect they won't want to. (Maybe i'm wrong.) But i don't think browsers are interested in offering more UI to expose preference toggles. In the absence of that, letting pages control it (which they do already) is straightforward and easy.<br> <myles> TabAtkins: For the persistence issue: There will be a way to clear the preference. It's an open question exactly which question. Please stop assuming that<br> <myles> TabAtkins: custom media query: MQs aren't suitable for this. It's awkward to do in the first place. There are mutliple features of the web that rely on various media queries that wouldn't work by default. 3rd party content wouldn't know to pay attention to your custom dark mode MQ. Manipulating the real MQ works more interoperably<br> <myles> jasew1: I've hearing concerns of preferences exposed and persistence.<br> <myles> jasew1: We can discuss outside of this. Assuming we can continue to discuss which preferences go into this, are there concerns with the API shape itself? Assuming we can make changes with the overall API<br> <myles> fremy: What I just mentioned. The UA should be more involved.<br> <fremy> @TabAtkins: If there is a way for the user to make this "non-persistent", how do you tell the user that?<br> <myles> ntim: Persistence is a big one<br> <emilio> myles: I wanted to jump on the bandwagon and say that persistence is super scary<br> <emilio> ... and also agree with ntim and fremy that the UA should be in charge of this<br> <astearns> ack nicole_<br> <astearns> ack jasew1<br> <astearns> ack myles<br> <TabAtkins> The same way users know to clear *any* page-specific data. "clear cookies" is a bit advanced but not unknown<br> <astearns> ack jasew<br> <fremy> q+<br> <myles> nicole_: I think there's a complicated relationship between the OS, UA, and site setting. That needs to be worked out to make sure the user's intent is happening<br> <myles> nicole_: To add to persistence, with a multi-page app, it will be hard if it's page by page. Maybe there's a way to do that, but i maybe haven't understood it<br> <myles> nicole_: Usually single page apps actually have multiple pages. Something about that could be weird where part is on wordpress and part is a react app ... figuring out how to make sure the user's intent was following through what the website owner determined as their ... all the sites that make up their actual site. I do wonder if it's complex enough that we need to have another mechanism if it was to be done this way for site authors actually need<br> <myles> to be able to say "all these pieces are one site and the setting should persist across across all of them"<br> <myles> nicole_: But I agree it's best done at a UA level<br> <fremy> fremy was on the queue to say that Chrome already had a page for "site settings" with tons of toggles, I don't see why a switch could not be provided for site-specific accessibility settings<br> <myles> TabAtkins: For the multi-page site, th question of "do we need control over the scope". My feedback was "this should just apply to the origin" We don't need to offer a toggle. But it was in the earlier version of the API. If needed, we could put it back. For all the new UI people, there browser developers<br> <myles> TabAtkins: Are y'all saying "y'all committing to adding browser UI to allow per-site preference changes"? If you think it's a good idea, but you don't want to do it, i'd like to proceed<br> <myles> myles: i cannot comment on future produces or releases<br> <myles> emilio: 1. some of these preferences... i want concrete examples. some preferences have side effects apart from MQs. reduce-motion markes marquees not scroll in firefox. Disables smooth scrolling. The API should be explicit about whether that's effected<br> <myles> emilio: For color-scheme, you already have a resolution to inherit used color scheme for SVG images (and maybe iframes).<br> <florian> q+<br> <myles> emilio: Browsers do expose per-sites settings for this, but not to the site, but they do for extensions. Firefox does have per-site setting override that extensions and users can use.<br> <ntim> This is what emilio is referring to: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/browserSettings/overrideContentColorScheme<br> <myles> emilio: I'm not sure how that should work together with the site ... the site being able to override the user decision both ath the UA level and extension level seems confusing. The user can tell the exttension to be dark ... there are like 4 different switches now can effect the page. The user has to figure out which is the one that actually is effecting the rendering<br> <myles> TabAtkins: SVGs - you're right. Already handled. For iframes, they should see the override<br> <myles> fantasai: We already resolved iframes inherit from color-scheme<br> <myles> TabAtkins: We still want to apply them when necessary<br> <myles> astearns: We are at time<br> <myles> astearns: We should take this as "hey, this as an introduction of an interesting proposal"<br> <myles> ACTION(fremy): Look at the proposal, see whether there's an issue to be filed<br> <TabAtkins> vmpstr, no, eTLD+1<br> <myles> ACTION(TabAtkins): Determine if prefers-reduce-data is handled<br> <myles> astearns: Anyone else, please comment in the issue<br> <myles> <general discussion about breakout sessions for unrelated topics><br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6517#issuecomment-1721083701 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 15 September 2023 11:01:29 UTC