LGTM1 I agree with your analysis of the ergonomics of the feature. Thanks for pushing this!
On Tuesday, September 20, 2022 at 5:34:10 PM UTC+2 Thomas Steiner wrote: > TAG review >> >> https://github.com/w3ctag/design-reviews/issues/632 >> >> TAG review status >> >> Unsatisfied >> > > To add some more nuance to the unsatisfied TAG review, here's the TAG's > summary, with our reactions: > > > *As you mentioned - ...this is not aimed at the average website.. Not > all Web platform features are aimed or used by all websites. However, Web > features must be predictable and possible for use by anyone, safely.* > > This feature *predictably* reveals the *current* state of > prefers-color-scheme and now prefers-reduced-motion. It is comparable > with client hints like sec-ch-viewport-height ( > https://github.com/w3ctag/design-reviews/issues/615) which changes, for > example, when the user switches to a different monitor (a scenario quite > common with laptops being used stationary with fixed screens in clamshell > mode and the built-in screen in on-the-go mode). If the user loads a page > with a small screen and then switches to a larger screen and the server has > based the loading of assets on the height of the viewport, the server is > now responsible for loading the rest of the content. (This can be testing > in a demo, courtesy of François Beaufort: https://client-hints.glitch.me/ > ). > > Everyone capable of modifying the headers of their web server can use this > feature. > > > *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.* > > The mentioned race conditions cannot really occur, since the client hint > is evaluated exactly once by the server at request time. In the worst case, > the change in conditions would be handled by the next reload. This is > comparable to existing client-side code that deals with this problem: If a > site uses matchMedia() to either show the one form of the page or the > other, but at the same time doesn't register a change listener for the > media query, we are in exactly the same boat: the page won't update > immediately when the user changes their preferences, but only upon the next > request. Improvements upon this are possible by adding said change > listener, which would be applicable to the client hint and the > matchMedia() approach alike. > > > *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 > <http://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.* > > Position requests were filed, with no final response so far: > > Mozilla: https://github.com/mozilla/standards-positions/issues/526 > > WebKit: https://lists.webkit.org/pipermail/webkit-dev/2021-May/031856.html > now migrated to https://github.com/WebKit/standards-positions/issues/15. > > A classic chicken-egg problem: the more web properties want to use this, > the more relevant it will become for browser vendors to implement this. > > > *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"* > The pure presence of the current proposal for > sec-ch-prefers-reduced-motion demonstrates the need for additional hints > than the previous color scheme hint ( > https://groups.google.com/a/chromium.org/g/blink-dev/c/tEZ4RVsP1ms/m/lDufAyPPFAAJ). > > The stakeholder is Google Search in both cases. > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/49cb057f-a31e-447f-bec4-337a44fb1850n%40chromium.org.
