LGTM2 On Wed, Sep 21, 2022 at 8:43 AM Yoav Weiss <yoavwe...@chromium.org> wrote:
> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/49cb057f-a31e-447f-bec4-337a44fb1850n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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/CAOMQ%2Bw8QU%3D_HqT1arznt6oSc5qbfeShZfKGkU-db5ybXvZ4KLA%40mail.gmail.com.
