Makes the browser use the user's preferred color scheme to render the viewport scrollbars if the value of "page’s supported color schemes" is 'normal' or not specified, and the computed value of the color-scheme for the root element is 'normal'. Viewport scrollbars can be considered to be outside the web content. Therefore, the user agents should honor the user's preferred color scheme when rendering viewport scrollbars if page authors have not explicitly specified support for color schemes.
None
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
None
Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?
Shipping on desktop
|
124
|
DevTrial on desktop
|
121
|
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
Hi there,
Would you mind requesting reviews for the various review gates in
your chromestatus entry?
On 2/29/24 4:12 PM, 'Yaroslav Shalivskyy' via blink-dev wrote:
Contact emails
Explainer
None
Specification
Summary
Makes the browser use the user's preferred color scheme to render the viewport scrollbars if the value of "page’s supported color schemes" is 'normal' or not specified, and the computed value of the color-scheme for the root element is 'normal'. Viewport scrollbars can be considered to be outside the web content. Therefore, the user agents should honor the user's preferred color scheme when rendering viewport scrollbars if page authors have not explicitly specified support for color schemes.
Blink component
TAG review
None
TAG review status
Not applicable
Risks
Interoperability and Compatibility
None
Gecko: No signal
WebKit: No signal
Web developers: No signals
Other signals:
Non-OSS dependencies
Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?
No.
Estimated milestones
Shipping on desktop 124 DevTrial on desktop 121
Anticipated spec changes
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
None
Link to entry on the Chrome Platform Status
Links to previous Intent discussions
Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PH8PR00MB16366CA3D32D8ECE2C646C54A94D2%40PH8PR00MB1636.namprd00.prod.outlook.com
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 [email protected].
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/LV3PR00MB17488611D88C9E41AC6A806BA95F2%40LV3PR00MB1748.namprd00.prod.outlook.com.
Hello Mike,
Thank you for taking a look!
I am seeking consensus on how to approach the feature from a standardization perspective. I think the feature can be considered a browser UI change, which is why I haven't requested a TAG review or signals from other engines. However, I am open to doing so if necessary.
I apologize for any confusion. We did the general experimentation in Edge (not the "origin trials" as I mentioned in the email). Retention reports were neutral, and we observed no regressions in scorecards. Also, we have not received any negative user feedback thus far.
I am working on requesting reviews for my chromestatus entry. Thanks for pointing this out!
Thanks,
Yaroslav
Mike didn't refer to the TAG review or browser signals, but the review steps in chromestatus. The intent should request, privacy, security, enterprise, and the other steps there.
I agree that this lives in the borderland between user agent UI and a web visible change so some shortcuts might be possible to motivate, but you still need to click the the appropriate buttons in the chromestatus tool.
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/34e66337-a227-4521-93bc-42317a1659b4n%40chromium.org.
Thanks for the summary of the experiment results on Edge - sounds positive.
If this is purely a browser UI change, then we don't really need
the blink-dev process at all. However, if we're relying on
concepts defined in a CSSWG draft, and devs can change the outcome
w/ some CSS (or maybe here, the lack of CSS to result in
non-`normal` computed value...) it would be if there were
interoperability in UI choices across browsers. I don't
necessarily think we should block on the outcome, but requesting
vendor positions could be useful.
(and Daniel, if you scroll down a bit - I did ask about TAG and
browser signals. :))
LGTM2