Should `no-preference` values be rejected?

[lukewarlow]

One of the concerns that have been raised is it being bad that a site could forcefully disregard user preference for reduced data or accessibility features.

One potential mitigation is to disallow no-preference as an override value. That way if the site wishes to disable a setting it would just clear the override?

That way a site could only Enable a preference rather than force disable?

[lukewarlow]

I can't think of a use case for disabling a preference but it's possible there are legitimate ones?

[FremyCompany]

+1; this sounds like a great way to reduce the risk to the users, and the chance of pushback.

In my opinion, overrides in the opposite directions should be possible but gated on a permission dialog, and this type of behavior can be added later in a v2 if you're afraid requiring it would make implementation progress slower.

[lukewarlow]

Yeah in lieu of anyone coming forwards with any concrete reasons why no-preference is overly important I think for now I'll remove it from the spec with a note that it might be added in future with appropriate guards.

[lukewarlow]

Here's GitHub with an example of UI that would make use of both the reducedMotion preference in general, but also would require a no-preference override.

Having said that I'd be curious if the ability to force enable them is actually used much.

[tabatkins]

As has been argued multiple times, there is literally no attack surface here with regards to "overriding" a user's preference. A site can already ignore all user preferences at will; ignoring the user's preference is in fact the default, and authors have to do extra work (writing @media rules) to pay attention to it in the first place. I don't think we should impose any restrictions on the allowed value space; anything that could be set by the UA, should be settable by the API.

We should continue to push back on feedback of this nature, as it fundamentally misunderstands what the feature is capable of doing.

[lukewarlow]

So while I agree on the whole. There is one thing I do want to clarify, this API is currently intended to have an affect on any UA styles or behaviours applied to a page based on the preference value. So being able to set "no-preference" would be a novel capability there. For example Firefox disables smooth scrolling when reduced motion is enabled (I haven't tested but this is what I've been told), if we allow "no-preference" then the site would be overriding that relationship between the user and UA.

But I agree that it's not that big an issue. Removing no-preference was my attempt at getting a minimal viable API surface that would get consensus.

[lukewarlow]

This API is unfortunately the sort of thing that needs support from all browsers to be effective and I'm concerned that WebKit already closed the position request as rejected.

I fully agree that many of the presented concerns or alternative solutions show a fundamental misunderstanding of the solution and problem area. Do you have any suggestions on how best to proceed with trying to get consensus here?

[lukewarlow]

Coming back to this I'm going to add no-preference back to the spec draft, as mentioned above it doesn't actually allow you as an author to do much that you can't already do. The only novel capablity is if the browser uses this preference to change it's internal functionality but if you wanted to make a page with lots of motion that internal browser CSS or behaviour isn't going to save the user much.

It may be that to achieve cross browser consensus some limitations get applied to no-preference behaviour but that can be achieved with the API shape