> 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) On Monday, 24 July 2023 at 19:23:06 UTC+1 [email protected] wrote: On 7/20/23 8:19 AM, Luke wrote: Contact emails [email protected], [email protected] 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 <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS> 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 <https://chromestatus.com/features#tags:client%20hints>, sec-ch-prefers-reduced-transparency <https://chromestatus.com/features#tags:sec-ch-prefers-reduced-transparency> , prefers-reduced-transparency <https://chromestatus.com/features#tags: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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? 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 <https://chromestatus.com/>. -- 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 [email protected]. 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 <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/B1ED49A6-31BF-4D28-89B3-D2973F9F12DA%40gmail.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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/73d9d549-e1ad-4517-8c3e-0ce3eb040d08n%40chromium.org.
