Intent to Prototype: Sec-CH-Prefers-Reduced-Transparency User Preference Media Features Client Hints Header

191 views
Skip to first unread message

Luke

unread,
Jul 20, 2023, 8:20:04 AM7/20/23
to blin...@chromium.org

Contact emails

lukewa...@gmail.comlu...@warlow.dev

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-transparency

Summary

User Preference Media Features Client Hints Header defines a set of HTTP Client Hints headers around user preference media features as defined by Media Queries Level 5. If used as Critical Client Hints, these headers allow servers to make smart choices regarding, e.g., CSS inlining. Sec-CH-Prefers-Reduced-Transparency reflects the user's prefers-reduced-transparency preference.



Blink component

Blink>CSS

Motivation

CSS media queries, and specifically user preference media features like `prefers-reduced-transparent` or `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. Focusing on `prefers-color-scheme`—but highlighting that the reasoning applies to other user preference media features as well—it is a best practice to not load CSS for the particular non-matching color scheme in the critical rendering path, and instead to initially only load the currently relevant CSS. 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-color-scheme` and that inline CSS for performance reasons, need to know about the preferred color scheme (or other user preference media features respectively) ideally at request time, so that the initial HTML payload already has the right CSS inlined.



Initial public proposal

https://github.com/w3c/csswg-drafts/issues/4162

Search tags

client hintssec-ch-prefers-reduced-transparencyprefers-reduced-transparency

TAG review



TAG review status

Pending

Risks



Interoperability and Compatibility



Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?



Debuggability



Is this feature fully tested by web-platform-tests?

No

Flag name on chrome://flags



Finch feature name



Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1466423

Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6242983812268032

Links to previous Intent discussions



This intent message was generated by Chrome Platform Status.

Mike Taylor

unread,
Jul 24, 2023, 2:23:06 PM7/24/23
to Luke, blin...@chromium.org


On 7/20/23 8:19 AM, Luke wrote:

Contact emails

lukewa...@gmail.comlu...@warlow.dev

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-transparency

Summary

User Preference Media Features Client Hints Header defines a set of HTTP Client Hints headers around user preference media features as defined by Media Queries Level 5. If used as Critical Client Hints, these headers allow servers to make smart choices regarding, e.g., CSS inlining. Sec-CH-Prefers-Reduced-Transparency reflects the user's prefers-reduced-transparency preference.



Blink component

Blink>CSS

Motivation

CSS media queries, and specifically user preference media features like `prefers-reduced-transparent` or `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. Focusing on `prefers-color-scheme`—but highlighting that the reasoning applies to other user preference media features as well—it is a best practice to not load CSS for the particular non-matching color scheme in the critical rendering path, and instead to initially only load the currently relevant CSS. 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-color-scheme` and that inline CSS for performance reasons, need to know about the preferred color scheme (or other user preference media features respectively) ideally at request time, so that the initial HTML payload already has the right CSS inlined.



Initial public proposal

https://github.com/w3c/csswg-drafts/issues/4162

Search tags

client hintssec-ch-prefers-reduced-transparencyprefers-reduced-transparency

TAG review



TAG review status

Pending

Risks



Interoperability and Compatibility



Gecko: No signal

WebKit: No signal

Have we asked for signals?


Web developers: No signals
If Google Search is asking for this, it seems like we have some signal, no?


Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?



Debuggability

Anything to note here?



Is this feature fully tested by web-platform-tests?

No
Why not?


Flag name on chrome://flags



Finch feature name

Presumably we have a base::Feature, non?


Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1466423

Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6242983812268032

Links to previous Intent discussions



This intent message was generated by Chrome Platform Status.
--
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/B1ED49A6-31BF-4D28-89B3-D2973F9F12DA%40gmail.com.

Luke

unread,
Jul 24, 2023, 2:36:18 PM7/24/23
to blink-dev, mike...@chromium.org, Luke
> Have we asked for signals?

I haven't filed position requests yet. I will do before submitting an intent to ship however.


> If Google Search is asking for this, it seems like we have some signal, no?

To clarify Google Search aren't asking for this client hint specifically. But they were a use case for the color scheme preference client hint. The Motivation section was largely a copy from previous preference client hints as a general explanation for the system. This feature is mainly just for completeness of the `prefers-reduced-transparency` implementation.

Some of the other sections I hadn't filled out on the chromestatus page apologies. I have addressed your specific questions below and will update the status page.

> Debuggability

Developers can change this client hint header value by emulating prefers-reduced-transparency via Devtools in the Rendering Panel.

> Web Platform Tests

This feature will be tested as much as possible in WPT tests.

> FInch Feature

My understanding of the exact feature mechanics is a bit lacking here. But a kClientHintsPrefersReducedTransparency feature has been added to blink/public/common/features.h I believe this is togglable via finch? (It's disabled by default for now)

This intent message was generated byᅠChrome Platform Status.

Luke

unread,
Jul 24, 2023, 2:47:08 PM7/24/23
to blink-dev, Luke, mike...@chromium.org
Just to follow up on the position request. A position request was filed as part of the original user preference client hint implementation and neither have had a response.

Mozilla Position request https://github.com/mozilla/standards-positions/issues/526

WebKit Position request https://github.com/WebKit/standards-positions/issues/15




Is this feature fully tested byᅠweb-platform-tests? No
Why not?


Flag name on chrome://flags

Finch feature name
Presumably we have a base::Feature, non?

Mike Taylor

unread,
Jul 25, 2023, 11:20:33 AM7/25/23
to Luke, blink-dev

Thanks for the links - when you get to the I2S stage, it's probably a good idea to add a comment to each letting them know that there's a proposal to ship this new one.

Reply all
Reply to author
Forward
0 new messages