Intent to ship: Sec-CH-Prefers-Reduced-Motion client hint header
Thomas Steiner
Contact emails
fbea...@chromium.org, to...@chromium.org
Explainer
https://github.com/wicg/user-preference-media-features-headers/blob/main/README.md
Specification
https://wicg.github.io/user-preference-media-features-headers/#sec-ch-prefers-reduced-motion
API spec
Yes
Summary
The Sec-CH-Prefers-Reduced-Motion client hint is modeled after the prefers-reduced-motion user preference media feature as defined in Media Queries Level 5. This headers follows Sec-CH-Prefers-Color-Scheme, which was described in https://groups.google.com/a/chromium.org/g/blink-dev/c/tEZ4RVsP1ms.
Blink component
Blink>CSS
Motivation
CSS media queries, and specifically user preference media features like prefers-reduced-motion, have a potentially significant impact on the amount of CSS that needs to be delivered by a page, and on the experience the user is going to have when the page loads.
It is a best practice to not load CSS responsible for animations in the critical rendering path if the user prefers reduced motion, but to instead only load said CSS if the user doesn't mind motion. One way of doing so is via <link media>. However, high-traffic sites like Google Search that wish to honor user preference media features like prefers-reduced-motion and that inline CSS for performance reasons, need to know about the motion preferences (or other user preference media features respectively) ideally at request time, so that the initial HTML payload already has the right CSS inlined.
TAG review
https://github.com/w3ctag/design-reviews/issues/632
TAG review status
Unsatisfied
Demo link
https://sec-ch-prefers-reduced-motion.glitch.me/
Debuggability
Developers can change the Sec-CH-Prefers-Reduced-Motion client hint header value by emulating motion preferences via DevTools in the Rendering panel like they can do with the Sec-CH-Prefers-Color-Scheme client hint header today.
Measurement
The kClientHintsPrefersReducedMotion WebFeature tracks Sec-CH-Prefers-Reduced-Motion client hint usage.
Risks
Interoperability and Compatibility
There are no particular compatibility risks.
Interoperability is still pending on other browser vendors replying. Support for Client Hints in general is not enthusiastic though.
Signals from other implementations (Gecko, WebKit):
Gecko: Pending (https://github.com/mozilla/standards-positions/issues/526)
WebKit: Pending (https://lists.webkit.org/pipermail/webkit-dev/2021-May/031856.html, now migrated to https://github.com/WebKit/standards-positions/issues/15)
Web / Framework developers: Positive (WICG proposal Issue: https://github.com/WICG/proposals/issues/30 with feedback from developers working for Facebook and Magento. Twitter: https://twitter.com/kilianvalkhof/status/1392404416335056896. The proposal was initially discussed in https://github.com/w3c/csswg-drafts/issues/4162 and received positive feedback via 16 Likes and 3 supportive comments: https://github.com/w3c/csswg-drafts/issues/4162#issuecomment-621047333, https://github.com/w3c/csswg-drafts/issues/4162#issuecomment-631400330, and https://github.com/w3c/csswg-drafts/issues/4162#issuecomment-645742958). Google Search is interested in this header, too.
Ergonomics:
N/A
Activation:
Developers will include Sec-CH-Prefers-Reduced-Motion in the response headers Accept-CH and Critical-CH to let the browser know that they’re interested in the motion preferences. If supported, the request header Sec-CH-Prefers-Reduced-Motion will be populated with the appropriate value.
Is this feature fully tested by web-platform-tests?
Yes. https://wpt.fyi/results/client-hints.
Tracking bug
Link to entry on the Chrome Platform Status
Yoav Weiss
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgRrL%3DgTkCO%3DmZErYjf1BCyQAPFNNMv3KJFPpFEFV3Ev6%3DrtA%40mail.gmail.com.
François Beaufort
On Fri, Sep 9, 2022 at 4:21 PM 'Thomas Steiner' via blink-dev <blin...@chromium.org> wrote:It seems worthwhile to properly specify that the hints in question are high-entropy hints that are not sent without an opt-in.Based on https://github.com/WebKit/standards-positions/issues/15, it doesn't seem like that is clear.
I've updated the spec to make it clear. See https://github.com/WICG/user-preference-media-features-headers/pull/7
Yoav Weiss
On Fri, Sep 9, 2022 at 5:49 PM Yoav Weiss <yoav...@chromium.org> wrote:On Fri, Sep 9, 2022 at 4:21 PM 'Thomas Steiner' via blink-dev <blin...@chromium.org> wrote:It seems worthwhile to properly specify that the hints in question are high-entropy hints that are not sent without an opt-in.Based on https://github.com/WebKit/standards-positions/issues/15, it doesn't seem like that is clear.Thank you!
I've updated the spec to make it clear. See https://github.com/WICG/user-preference-media-features-headers/pull/7
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
François Beaufort
On Sunday, September 11, 2022 at 7:20:45 AM UTC+2 fbea...@google.com wrote:On Fri, Sep 9, 2022 at 5:49 PM Yoav Weiss <yoav...@chromium.org> wrote:On Fri, Sep 9, 2022 at 4:21 PM 'Thomas Steiner' via blink-dev <blin...@chromium.org> wrote:It seems worthwhile to properly specify that the hints in question are high-entropy hints that are not sent without an opt-in.Based on https://github.com/WebKit/standards-positions/issues/15, it doesn't seem like that is clear.Thank you!
I've updated the spec to make it clear. See https://github.com/WICG/user-preference-media-features-headers/pull/7Thanks, but that doesn't define that the hint is a high entropy one.Talking to Mike Taylor, it seems we can improve the CH Infra spec to make it clearer that any hint that's not low-entropy is a high entropy hint.Then your spec can get that definition for free.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Thomas Steiner
TAG review
https://github.com/w3ctag/design-reviews/issues/632
TAG review status
Unsatisfied
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. 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"
Thomas Steiner
TAG review
https://github.com/w3ctag/design-reviews/issues/632
TAG review status
Unsatisfied
Yoav Weiss
Chris Harrelson
--
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+...@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.
Mike Taylor
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.