- From: Luke Warlow via GitHub <sysbot+gh@w3.org>
- Date: Fri, 15 Sep 2023 11:40:31 +0000
- To: public-css-archive@w3.org
I'll reply to comments inline here. > emilio: I'm not sure I agree overriding things like contrast-preference, reduced-motion, etc. 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 I would disagree on the statement that there's no use case. For two reasons, I don't have an issue on the whole with motion but some sites really do overdo it. If they provided a way to disable them per-site (origin) then that would benefit me. Also it's common place for sites specifically ones focussed on accessibility to provide a high contrast theme. Currently this has to be done manually by swapping out the stylesheet. This API proposal would allow for that to just use the media query. > emilio: Some other preferences (reduced-data) affect stuff like what headers the browsers send emilio: there's no mention of that stuff It is intended that the header reflects the preference. I do mention user preference client hint headers but you are correct I should make it more explicit and include the Save-Data header. > it feels sketchy to override prefers-reduced motion I'd be keen to here why you think this? If a site want's to be obnoxious and override it to no-preference well they can largely already do this by just ignoring the preference. Excepting the question of UA styles which they don't contro currentlyl so that is a valid concern. > 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 Absolutely, I copied all the mq5 preferences by default but I'm more than happy to discuss removal of some. I do think that more than colorScheme are useful though. > There may actually be value for the site to provide a setting that's easier to get to than the OS setting I think this is a key point I'd like to emphasise. There's some OSs that don't even offer certain preferences, for example Chrome and Firefox for Android only very very recently got the ability to honour a contrast preference. Due to platform limitations I ended up having to implement them using "High Contrast Text" setting which isn't a 1 : 1 match. It's also worth bearing in mind that there's only 1 platform that allows a "(prefers-contrast: less)" state and that's Windows. Aside from Firefox's forced colors palette in the browser which does offer this capability on other platforms. This API is intended to allow sites to offer a more comprehensive accessibility experience. > If you clear storage will that clear the override? Yes, if you clear site data the override will be cleared. The exact clearing mechanism is obviously ultimately down to the UA but I don't see this as being much different from offering a reset preferences option like you get with permissions. On top of also being cleared when site data as a whole is cleared. > i don't think we should make it persistent Why? That's largely the whole basis for the API. We can spec it to have the same bahaviour as any other user controlled storage for UAs that are concerned such as Safari's 7 day storage eviction. But part of the benefit is this could survive that. On the basis it's not really useful for tracking. If it's not persistent you also get the flash of unstyled content issue if the OS theme and user preference don't match. e.g a flash of white as the page loads and the preference is set. > i think defining exactly who can see this change is important. can UA style sheets see this? I completely agree and UA styles is a great example of where the spec needs clarification. My intention is that it would apply to UA styles (for a given origin). However, I'm unsure on the exact implementation problems that could come from that. It's worth being aware Chromium actually doesn't support media feature queries in UA styles at all currently.) > If the website changes, and don't provide the feature any more, how is the user going to get the behavior any more? Resetting the preference overrides in the site settings of the browser, or clearing all site data depending on the UA's implementation (again I don't think the mechanism for clearing can be specced as it's UA dependent but I'm happy to put that the UA MUST provide a way to reset) > Another way of doing this is to add a custom media query. Tab already answered this but just to emphasise custom media queries are not the answer. They don't support color-scheme changes, they don't work with third party content, they don't integrate with user preference client hint headers, they don't integrate with conditional resource loading (using the standard queries at least). They are a brilliant idea and I think a much needed addition to the platform but for the specifics of this they do not solve the problem. > I wanted to jump on the bandwagon and say that persistence is super scary Again I'm keen to hear the reasoning for this? What "attacks" could persistence of this setting lead to. If it's purely about sites removing this functionality down the road and the user being stuck. While that's valid and I hope addressed by the fact UAs can clear this, it's worth noting that well sites can already completely ignore the user preferences so from the users perspective it's not all that different? > 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 This is the key of my thoughts. If you're willing to commit to adding per site (or heck even a browser level toggle which some don't offer atm) settings then great. But until we all get that we're stuck with a rather poor status quo. I really don't want this to become the password toggle button over again. To be completely frank put your money where you mouth is and implement this ability in the browser, or give us web developers the ability to do it ourselves. Not to mention the fact that I highly doubt browser UI will stop sites doing their own for color scheme and being stuck in the same place as before. I also don't think browser UI and this API need be mutually exclusive. > 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 Completely valid I'll make an issue on the spec to address this, thanks for the specific on what needs looking at! Fwiw these should all be affected too. (again completely open to discussion) > 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. Again thanks for bringing this to my attention I wasn't aware such a feature existed. Again I'll raise an issue to discuss which should take precedence. I don't actually have answer off the top of my head to this one. My gut says the precedence should be OS < Browser < Site < Extension but needs discussion. -- GitHub Notification of comment by lukewarlow Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6517#issuecomment-1721134674 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:40:33 UTC