LGTM3 On 9/21/22 11:44 AM, Chris Harrelson wrote:
LGTM2On 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 <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 GoogleGroups "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 <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8QU%3D_HqT1arznt6oSc5qbfeShZfKGkU-db5ybXvZ4KLA%40mail.gmail.com?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/6ef1c3fd-c87d-eb92-fa53-6d9e9a7e1c72%40chromium.org.
