Re: [w3ctag/design-reviews] User Preference Media Features Client Hints Headers (#632)

Likewise thanks for the review and your time!

> The base problem of this proposal is the exposure of **user state** rather than **client capabilities** of user preference media features. This allows user state handling on the server side which can lead to race conditions and undesired error state and user experience. One that doesn't exist today with media features which are evaluated and handled on the client side. This is not a safe pattern and should be avoided.

In #615, you have reviewed `Sec-CH-Viewport-Height`, which is likewise about user state. Knowing the viewport height on the server _"would enable origins to e.g., inline all the content that’s expected to appear in the viewport"_ ([quote](https://github.com/w3ctag/design-reviews/issues/615#:~:text=This%20would%20enable%20origins%20to%20e.g.%2C%20inline%20all%20the%20content%20that%E2%80%99s%20expected%20to%20appear%20in%20the%20viewport)). This arguably causes the same "race conditions and undesired error state and user experience" if the user resizes their window at a later point after the initial load, comparable to the state change that occurs when the preferred color scheme changes. 
 
> During our call we discussed multi stakeholder interest. You mentioned of few other large Web properties that would be interested and willing to use the feature for similar benefits to those of `google.com`. That isn't surprising. They employ enough engineers and will be able to take the hit of implementation and support. What we don't see is evidence of other browser vendors interested to support the feature.

Well, we asked, but despite friendly pings didn't hear back:

* WebKit thread: https://lists.webkit.org/pipermail/webkit-dev/2021-May/031856.html

* Mozilla Standards Position: [User Preference Media Features Client Hints Headers mozilla/standards-positions#526](https://github.com/mozilla/standards-positions/issues/526)

> We don't see evidence or use cases of user preference media features other than 'prefers-color-scheme'. If this is the only use case, with most benefit to your scenario, consider exposing a hint of such client capability, i.e. "does this device support auto detection of light or dark mode"

This reflects the popularity of the user preference media features. Up next on our list would probably be `prefers-reduced-motion` (i.e., `Sec-CH-Prefers-Reduced-Motion`). This is motivated by observations like the one below, well noting that Apple achieve this with the CSS (`@media (prefers-reduced-motion)`) and JS (`matchMedia('(prefers-reduced-motion)')`) technology available today, but envisioning further possible optimizations by tailoring the JS and CSS on the server-side, which does not even have to mean inlining (which Apple don't do), but leaving away unrelevant things in the initially served bundles, which are currently identical in both cases, but which have a different code coverage (especially [`main.built.js`](https://www.apple.com/v/apple-watch-series-7/c/built/scripts/main.built.js))

Browsing https://www.apple.com/apple-watch-series-7/ by scrolling from top to bottom:

- With `prefers-reduced-motion` set to `reduce`: **18.7 MB**.
   <img width="1792" alt="Screen Shot 2021-12-14 at 09 56 43" src="https://user-images.githubusercontent.com/145676/145966198-58c82270-229b-4750-976d-46020e0f715a.png">
- With `prefers-reduced-motion` set to `no-preference`: **45.5 MB**.
   <img width="1792" alt="Screen Shot 2021-12-14 at 09 58 25" src="https://user-images.githubusercontent.com/145676/145966225-935baefb-8af8-404e-af32-c955e8d85e1e.png">

All that being said, we respect your resolution and thank you again for your time!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/632#issuecomment-993339833