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

[Luke]

Contact emails

lukewa...@gmail.com, lu...@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 hints, sec-ch-prefers-reduced-transparency, prefers-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]

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

Contact emails

lukewa...@gmail.com, lu...@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 hints, sec-ch-prefers-reduced-transparency, prefers-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]

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

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]

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.