Re: [blink-dev] Intent to Ship: Used color scheme root scrollbars

[Mike Taylor]

LGTM2

On 3/26/24 1:25 PM, Yoav Weiss (@Shopify) wrote:
LGTM1 once the fix 
 to 
the above issue lands.


On Monday, March 18, 2024 at 7:56:52 PM UTC+1 yshal...@microsoft.com 
wrote:


Yes, I believe the bug [1] is a blocker.

[1] https://issues.chromium.org/issues/328102503
.

On Monday, March 18, 2024 at 1:51:43 AM UTC-7 yoav...@chromium.org
wrote:

Great to see a positive position from Mozilla on this.

Is the above mentioned bug a blocker here?

On Friday, March 8, 2024 at 12:52:58 AM UTC+1
yshal...@microsoft.com wrote:

Thanks for taking a look and your feedback! Please let me
know if you have any other questions or concerns.
On Thursday, March 7, 2024 at 3:23:02 PM UTC-8 William
Smith wrote:

Thank you! And just to be clear, I personally don't
see it as a problem at all, I was only curious. I
actually think this should have shipped along with
dark mode back in 2019, but better late than never.

On Thursday, March 7, 2024 at 5:22:14 PM UTC-5
Yaroslav Shalivskyy wrote:

Hello William! Thank you for selfhosting the feature!

For the pages you mentioned, the feature is
working as indented. If you enable the dark mode
in OS settings (e.g., refer to the screenshot
attached from the Windows device), root scrollbars
will follow the OS settings unless page authors
have explicitly specified page’s supported color
schemes.

However, I recently discovered a bug related to
Chrome browser Appearance > Mode setting. The
setting doesn't impact the calculation of web
contents' used color scheme, resulting in
inconsistent behavior. For more details, please
see: [UsedColorSchemeRootScrollbars] Root
scrollbars are dark when the browser color theme
setting is "Light" and the OS theme settings is
"Dark" [328102503] - Chromium
. I
am currently prioritizing work on the CL to fix
this issue.
On Wednesday, March 6, 2024 at 8:54:37 PM UTC-8
William Smith wrote:

Apologies if this isn't the correct place to
ask this but I have this working in Chrome
Canary and as fantastic as it is, they
behavior on some websites has me confused: on
https://en.wikipedia.org/wiki/Main_Page
 and
amazon.com  the scrollbar
is dark, but neither of those webpages have a
dark mode in any way. Is this a bug in the
feature or is it working as intended?

On Tuesday, March 5, 2024 at 5:33:33 PM UTC-5
Yaroslav Shalivskyy wrote:

Mike and Daniel, thank you for the
suggestions!

I requested browser vendor positions as
well as reviews for chromestatus entry.

Mozilla: [css-color-adjust-1] Root
non-overlay scrollbars used color scheme ·
Issue #995 · mozilla/standards-positions
(github.com)


WebKit: [css-color-adjust-1] Root
non-overlay scrollbars used color scheme ·
Issue #326 · WebKit/standards-positions
(github.com)



I updated the chromestatus entry with
these links as well.

On Monday, March 4, 2024 at 12:08:23 PM
UTC-8 mike...@chromium.org wrote:

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
  

Re: [blink-dev] Intent to Ship: Used color scheme root scrollbars

[Yoav Weiss (@Shopify)]

LGTM1 once the fix 
 to the 
above issue lands.

On Monday, March 18, 2024 at 7:56:52 PM UTC+1 yshal...@microsoft.com wrote:

> Yes, I believe the bug [1] is a blocker.
>
> [1] https://issues.chromium.org/issues/328102503.
>
> On Monday, March 18, 2024 at 1:51:43 AM UTC-7 yoav...@chromium.org wrote:
>
>> Great to see a positive position from Mozilla on this.
>>
>> Is the above mentioned bug a blocker here?
>>
>> On Friday, March 8, 2024 at 12:52:58 AM UTC+1 yshal...@microsoft.com 
>> wrote:
>>
>>> Thanks for taking a look and your feedback! Please let me know if you 
>>> have any other questions or concerns.
>>> On Thursday, March 7, 2024 at 3:23:02 PM UTC-8 William Smith wrote:
>>>
 Thank you! And just to be clear, I personally don't see it as a problem 
 at all, I was only curious. I actually think this should have shipped 
 along 
 with dark mode back in 2019, but better late than never. 

 On Thursday, March 7, 2024 at 5:22:14 PM UTC-5 Yaroslav Shalivskyy 
 wrote:

> Hello William! Thank you for selfhosting the feature!
>
> For the pages you mentioned, the feature is working as indented. If 
> you enable the dark mode in OS settings (e.g., refer to the screenshot 
> attached from the Windows device), root scrollbars will follow the OS 
> settings unless page authors have explicitly specified page’s supported 
> color schemes.
>
> However, I recently discovered a bug related to Chrome browser 
> Appearance > Mode setting. The setting doesn't impact the calculation of 
> web contents' used color scheme, resulting in inconsistent behavior. For 
> more details, please see: [UsedColorSchemeRootScrollbars] Root 
> scrollbars are dark when the browser color theme setting is "Light" and 
> the 
> OS theme settings is "Dark" [328102503] - Chromium 
> . I am currently 
> prioritizing work on the CL to fix this issue.
> On Wednesday, March 6, 2024 at 8:54:37 PM UTC-8 William Smith wrote:
>
>> Apologies if this isn't the correct place to ask this but I have this 
>> working in Chrome Canary and as fantastic as it is, they behavior on 
>> some 
>> websites has me confused: on https://en.wikipedia.org/wiki/Main_Page 
>> and amazon.com the scrollbar is dark, but neither of those webpages 
>> have a dark mode in any way. Is this a bug in the feature or is it 
>> working 
>> as intended?  
>>
>> On Tuesday, March 5, 2024 at 5:33:33 PM UTC-5 Yaroslav Shalivskyy 
>> wrote:
>>
>>> Mike and Daniel, thank you for the suggestions!
>>>
>>> I requested browser vendor positions as well as reviews for 
>>> chromestatus entry.
>>>
>>> Mozilla: [css-color-adjust-1] Root non-overlay scrollbars used 
>>> color scheme · Issue #995 · mozilla/standards-positions (github.com) 
>>> 
>>> WebKit: [css-color-adjust-1] Root non-overlay scrollbars used color 
>>> scheme · Issue #326 · WebKit/standards-positions (github.com) 
>>> 
>>>
>>> I updated the chromestatus entry with these links as well.
>>>
>>> On Monday, March 4, 2024 at 12:08:23 PM UTC-8 mike...@chromium.org 
>>> wrote:
>>>
 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. :))
 On 3/2/24 1:10 PM, Daniel Bratell wrote:

 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
 On 2024-03-01 21:10, 'Yaroslav Shalivskyy' via blink-dev wrote:

 Hello Mike,

 Thank you for taking a look!

Re: [blink-dev] Intent to Ship: Used color scheme root scrollbars

['Yaroslav Shalivskyy' via blink-dev]

Yes, I believe the bug [1] is a blocker.

[1] https://issues.chromium.org/issues/328102503.

On Monday, March 18, 2024 at 1:51:43 AM UTC-7 yoav...@chromium.org wrote:

> Great to see a positive position from Mozilla on this.
>
> Is the above mentioned bug a blocker here?
>
> On Friday, March 8, 2024 at 12:52:58 AM UTC+1 yshal...@microsoft.com 
> wrote:
>
>> Thanks for taking a look and your feedback! Please let me know if you 
>> have any other questions or concerns.
>> On Thursday, March 7, 2024 at 3:23:02 PM UTC-8 William Smith wrote:
>>
>>> Thank you! And just to be clear, I personally don't see it as a problem 
>>> at all, I was only curious. I actually think this should have shipped along 
>>> with dark mode back in 2019, but better late than never. 
>>>
>>> On Thursday, March 7, 2024 at 5:22:14 PM UTC-5 Yaroslav Shalivskyy wrote:
>>>
 Hello William! Thank you for selfhosting the feature!

 For the pages you mentioned, the feature is working as indented. If you 
 enable the dark mode in OS settings (e.g., refer to the screenshot 
 attached 
 from the Windows device), root scrollbars will follow the OS settings 
 unless page authors have explicitly specified page’s supported color 
 schemes.

 However, I recently discovered a bug related to Chrome browser 
 Appearance > Mode setting. The setting doesn't impact the calculation of 
 web contents' used color scheme, resulting in inconsistent behavior. For 
 more details, please see: [UsedColorSchemeRootScrollbars] Root 
 scrollbars are dark when the browser color theme setting is "Light" and 
 the 
 OS theme settings is "Dark" [328102503] - Chromium 
 . I am currently 
 prioritizing work on the CL to fix this issue.
 On Wednesday, March 6, 2024 at 8:54:37 PM UTC-8 William Smith wrote:

> Apologies if this isn't the correct place to ask this but I have this 
> working in Chrome Canary and as fantastic as it is, they behavior on some 
> websites has me confused: on https://en.wikipedia.org/wiki/Main_Page 
> and amazon.com the scrollbar is dark, but neither of those webpages 
> have a dark mode in any way. Is this a bug in the feature or is it 
> working 
> as intended?  
>
> On Tuesday, March 5, 2024 at 5:33:33 PM UTC-5 Yaroslav Shalivskyy 
> wrote:
>
>> Mike and Daniel, thank you for the suggestions!
>>
>> I requested browser vendor positions as well as reviews for 
>> chromestatus entry.
>>
>> Mozilla: [css-color-adjust-1] Root non-overlay scrollbars used color 
>> scheme · Issue #995 · mozilla/standards-positions (github.com) 
>> 
>> WebKit: [css-color-adjust-1] Root non-overlay scrollbars used color 
>> scheme · Issue #326 · WebKit/standards-positions (github.com) 
>> 
>>
>> I updated the chromestatus entry with these links as well.
>>
>> On Monday, March 4, 2024 at 12:08:23 PM UTC-8 mike...@chromium.org 
>> wrote:
>>
>>> 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. :))
>>> On 3/2/24 1:10 PM, Daniel Bratell wrote:
>>>
>>> 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
>>> On 2024-03-01 21:10, 'Yaroslav Shalivskyy' via blink-dev wrote:
>>>
>>> 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 

Re: [blink-dev] Intent to Ship: Used color scheme root scrollbars

[Yoav Weiss (@Shopify)]

Great to see a positive position from Mozilla on this.

Is the above mentioned bug a blocker here?

On Friday, March 8, 2024 at 12:52:58 AM UTC+1 yshal...@microsoft.com wrote:

> Thanks for taking a look and your feedback! Please let me know if you have 
> any other questions or concerns.
> On Thursday, March 7, 2024 at 3:23:02 PM UTC-8 William Smith wrote:
>
>> Thank you! And just to be clear, I personally don't see it as a problem 
>> at all, I was only curious. I actually think this should have shipped along 
>> with dark mode back in 2019, but better late than never. 
>>
>> On Thursday, March 7, 2024 at 5:22:14 PM UTC-5 Yaroslav Shalivskyy wrote:
>>
>>> Hello William! Thank you for selfhosting the feature!
>>>
>>> For the pages you mentioned, the feature is working as indented. If you 
>>> enable the dark mode in OS settings (e.g., refer to the screenshot attached 
>>> from the Windows device), root scrollbars will follow the OS settings 
>>> unless page authors have explicitly specified page’s supported color 
>>> schemes.
>>>
>>> However, I recently discovered a bug related to Chrome browser 
>>> Appearance > Mode setting. The setting doesn't impact the calculation of 
>>> web contents' used color scheme, resulting in inconsistent behavior. For 
>>> more details, please see: [UsedColorSchemeRootScrollbars] Root 
>>> scrollbars are dark when the browser color theme setting is "Light" and the 
>>> OS theme settings is "Dark" [328102503] - Chromium 
>>> . I am currently 
>>> prioritizing work on the CL to fix this issue.
>>> On Wednesday, March 6, 2024 at 8:54:37 PM UTC-8 William Smith wrote:
>>>
 Apologies if this isn't the correct place to ask this but I have this 
 working in Chrome Canary and as fantastic as it is, they behavior on some 
 websites has me confused: on https://en.wikipedia.org/wiki/Main_Page 
 and amazon.com the scrollbar is dark, but neither of those webpages 
 have a dark mode in any way. Is this a bug in the feature or is it working 
 as intended?  

 On Tuesday, March 5, 2024 at 5:33:33 PM UTC-5 Yaroslav Shalivskyy wrote:

> Mike and Daniel, thank you for the suggestions!
>
> I requested browser vendor positions as well as reviews for 
> chromestatus entry.
>
> Mozilla: [css-color-adjust-1] Root non-overlay scrollbars used color 
> scheme · Issue #995 · mozilla/standards-positions (github.com) 
> 
> WebKit: [css-color-adjust-1] Root non-overlay scrollbars used color 
> scheme · Issue #326 · WebKit/standards-positions (github.com) 
> 
>
> I updated the chromestatus entry with these links as well.
>
> On Monday, March 4, 2024 at 12:08:23 PM UTC-8 mike...@chromium.org 
> wrote:
>
>> 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. :))
>> On 3/2/24 1:10 PM, Daniel Bratell wrote:
>>
>> 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
>> On 2024-03-01 21:10, 'Yaroslav Shalivskyy' via blink-dev wrote:
>>
>> 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 

Re: [blink-dev] Intent to Ship: Used color scheme root scrollbars

['Yaroslav Shalivskyy' via blink-dev]

Thanks for taking a look and your feedback! Please let me know if you have 
any other questions or concerns.
On Thursday, March 7, 2024 at 3:23:02 PM UTC-8 William Smith wrote:

> Thank you! And just to be clear, I personally don't see it as a problem at 
> all, I was only curious. I actually think this should have shipped along 
> with dark mode back in 2019, but better late than never. 
>
> On Thursday, March 7, 2024 at 5:22:14 PM UTC-5 Yaroslav Shalivskyy wrote:
>
>> Hello William! Thank you for selfhosting the feature!
>>
>> For the pages you mentioned, the feature is working as indented. If you 
>> enable the dark mode in OS settings (e.g., refer to the screenshot attached 
>> from the Windows device), root scrollbars will follow the OS settings 
>> unless page authors have explicitly specified page’s supported color 
>> schemes.
>>
>> However, I recently discovered a bug related to Chrome browser Appearance 
>> > Mode setting. The setting doesn't impact the calculation of web contents' 
>> used color scheme, resulting in inconsistent behavior. For more details, 
>> please see: [UsedColorSchemeRootScrollbars] Root scrollbars are dark 
>> when the browser color theme setting is "Light" and the OS theme settings 
>> is "Dark" [328102503] - Chromium 
>> . I am currently 
>> prioritizing work on the CL to fix this issue.
>> On Wednesday, March 6, 2024 at 8:54:37 PM UTC-8 William Smith wrote:
>>
>>> Apologies if this isn't the correct place to ask this but I have this 
>>> working in Chrome Canary and as fantastic as it is, they behavior on some 
>>> websites has me confused: on https://en.wikipedia.org/wiki/Main_Page 
>>> and amazon.com the scrollbar is dark, but neither of those webpages 
>>> have a dark mode in any way. Is this a bug in the feature or is it working 
>>> as intended?  
>>>
>>> On Tuesday, March 5, 2024 at 5:33:33 PM UTC-5 Yaroslav Shalivskyy wrote:
>>>
 Mike and Daniel, thank you for the suggestions!

 I requested browser vendor positions as well as reviews for 
 chromestatus entry.

 Mozilla: [css-color-adjust-1] Root non-overlay scrollbars used color 
 scheme · Issue #995 · mozilla/standards-positions (github.com) 
 
 WebKit: [css-color-adjust-1] Root non-overlay scrollbars used color 
 scheme · Issue #326 · WebKit/standards-positions (github.com) 
 

 I updated the chromestatus entry with these links as well.

 On Monday, March 4, 2024 at 12:08:23 PM UTC-8 mike...@chromium.org 
 wrote:

> 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. :))
> On 3/2/24 1:10 PM, Daniel Bratell wrote:
>
> 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
> On 2024-03-01 21:10, 'Yaroslav Shalivskyy' via blink-dev wrote:
>
> 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
>
> On Friday, March 1, 2024 at 5:52:55 AM UTC-8 mike...@chromium.org 
> wrote:
>
>> Hi there,
>>
>>
>> Would you mind requesting reviews 

Re: [blink-dev] Intent to Ship: Used color scheme root scrollbars

[William Smith]

Thank you! And just to be clear, I personally don't see it as a problem at 
all, I was only curious. I actually think this should have shipped along 
with dark mode back in 2019, but better late than never. 

On Thursday, March 7, 2024 at 5:22:14 PM UTC-5 Yaroslav Shalivskyy wrote:

> Hello William! Thank you for selfhosting the feature!
>
> For the pages you mentioned, the feature is working as indented. If you 
> enable the dark mode in OS settings (e.g., refer to the screenshot attached 
> from the Windows device), root scrollbars will follow the OS settings 
> unless page authors have explicitly specified page’s supported color 
> schemes.
>
> However, I recently discovered a bug related to Chrome browser Appearance 
> > Mode setting. The setting doesn't impact the calculation of web contents' 
> used color scheme, resulting in inconsistent behavior. For more details, 
> please see: [UsedColorSchemeRootScrollbars] Root scrollbars are dark when 
> the browser color theme setting is "Light" and the OS theme settings is 
> "Dark" [328102503] - Chromium 
> . I am currently 
> prioritizing work on the CL to fix this issue.
> On Wednesday, March 6, 2024 at 8:54:37 PM UTC-8 William Smith wrote:
>
>> Apologies if this isn't the correct place to ask this but I have this 
>> working in Chrome Canary and as fantastic as it is, they behavior on some 
>> websites has me confused: on https://en.wikipedia.org/wiki/Main_Page and 
>> amazon.com the scrollbar is dark, but neither of those webpages have a 
>> dark mode in any way. Is this a bug in the feature or is it working as 
>> intended?  
>>
>> On Tuesday, March 5, 2024 at 5:33:33 PM UTC-5 Yaroslav Shalivskyy wrote:
>>
>>> Mike and Daniel, thank you for the suggestions!
>>>
>>> I requested browser vendor positions as well as reviews for chromestatus 
>>> entry.
>>>
>>> Mozilla: [css-color-adjust-1] Root non-overlay scrollbars used color 
>>> scheme · Issue #995 · mozilla/standards-positions (github.com) 
>>> 
>>> WebKit: [css-color-adjust-1] Root non-overlay scrollbars used color 
>>> scheme · Issue #326 · WebKit/standards-positions (github.com) 
>>> 
>>>
>>> I updated the chromestatus entry with these links as well.
>>>
>>> On Monday, March 4, 2024 at 12:08:23 PM UTC-8 mike...@chromium.org 
>>> wrote:
>>>
 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. :))
 On 3/2/24 1:10 PM, Daniel Bratell wrote:

 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
 On 2024-03-01 21:10, 'Yaroslav Shalivskyy' via blink-dev wrote:

 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

 On Friday, March 1, 2024 at 5:52:55 AM UTC-8 mike...@chromium.org 
 wrote:

> 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 
> gerc...@microsoft.com, yshal...@microsoft.com
>
> Explainer 
> None
>
> Specification 
> 

Re: [blink-dev] Intent to Ship: Used color scheme root scrollbars

[William Smith]

Apologies if this isn't the correct place to ask this but I have this 
working in Chrome Canary and as fantastic as it is, they behavior on some 
websites has me confused: on https://en.wikipedia.org/wiki/Main_Page and 
amazon.com the scrollbar is dark, but neither of those webpages have a dark 
mode in any way. Is this a bug in the feature or is it working as 
intended?  

On Tuesday, March 5, 2024 at 5:33:33 PM UTC-5 Yaroslav Shalivskyy wrote:

> Mike and Daniel, thank you for the suggestions!
>
> I requested browser vendor positions as well as reviews for chromestatus 
> entry.
>
> Mozilla: [css-color-adjust-1] Root non-overlay scrollbars used color 
> scheme · Issue #995 · mozilla/standards-positions (github.com) 
> 
> WebKit: [css-color-adjust-1] Root non-overlay scrollbars used color 
> scheme · Issue #326 · WebKit/standards-positions (github.com) 
> 
>
> I updated the chromestatus entry with these links as well.
>
> On Monday, March 4, 2024 at 12:08:23 PM UTC-8 mike...@chromium.org wrote:
>
>> 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. :))
>> On 3/2/24 1:10 PM, Daniel Bratell wrote:
>>
>> 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
>> On 2024-03-01 21:10, 'Yaroslav Shalivskyy' via blink-dev wrote:
>>
>> 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
>>
>> On Friday, March 1, 2024 at 5:52:55 AM UTC-8 mike...@chromium.org wrote:
>>
>>> 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 
>>> gerc...@microsoft.com, yshal...@microsoft.com
>>>
>>> Explainer 
>>> None
>>>
>>> Specification 
>>> https://www.w3.org/TR/css-color-adjust-1
>>>
>>> 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 
>>> Blink>Layout>Scrollbars 
>>> 
>>>
>>> TAG review 
>>> None
>>>
>>> TAG review status 
>>> Not applicable
>>>
>>> Any reason you think this is N/A, or have you just not requested TAG 
>>> review?
>>>
>>>
>>> Risks 
>>>
>>> Interoperability and Compatibility 
>>>
>>> None
>>>
>>>
>>> *Gecko*: No signal
>>>
>>> *WebKit*: No signal
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*:
>>>
>>> Could we request signals please?
>>>
>>>
>>> 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?*
>>>
>>> None
>>>
>>>
>>> Debuggability 
>>>
>>> None
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, 

Re: [blink-dev] Intent to Ship: Used color scheme root scrollbars

['Yaroslav Shalivskyy' via blink-dev]

Mike and Daniel, thank you for the suggestions!

I requested browser vendor positions as well as reviews for chromestatus 
entry.

Mozilla: [css-color-adjust-1] Root non-overlay scrollbars used color scheme 
· Issue #995 · mozilla/standards-positions (github.com) 

WebKit: [css-color-adjust-1] Root non-overlay scrollbars used color scheme 
· Issue #326 · WebKit/standards-positions (github.com) 


I updated the chromestatus entry with these links as well.

On Monday, March 4, 2024 at 12:08:23 PM UTC-8 mike...@chromium.org wrote:

> 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. :))
> On 3/2/24 1:10 PM, Daniel Bratell wrote:
>
> 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
> On 2024-03-01 21:10, 'Yaroslav Shalivskyy' via blink-dev wrote:
>
> 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
>
> On Friday, March 1, 2024 at 5:52:55 AM UTC-8 mike...@chromium.org wrote:
>
>> 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 
>> gerc...@microsoft.com, yshal...@microsoft.com
>>
>> Explainer 
>> None
>>
>> Specification 
>> https://www.w3.org/TR/css-color-adjust-1
>>
>> 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 
>> Blink>Layout>Scrollbars 
>> 
>>
>> TAG review 
>> None
>>
>> TAG review status 
>> Not applicable
>>
>> Any reason you think this is N/A, or have you just not requested TAG 
>> review?
>>
>>
>> Risks 
>>
>> Interoperability and Compatibility 
>>
>> None
>>
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> Could we request signals please?
>>
>>
>> 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?*
>>
>> None
>>
>>
>> Debuggability 
>>
>> None
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>> Linux, ChromeOS, Android, and Android WebView)? 
>> Yes
>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ? 
>> No
>>
>> Flag name on chrome://flags 
>> None
>>
>> Finch feature name 
>> UsedColorSchemeRootScrollbars
>>
>> Requires code in //chrome? 
>> False
>>
>> Tracking bug 
>> https://issues.chromium.org/issues/40259909
>>
>> Measurement 
>> Added a use counter UsedColorSchemeRootScrollbarsDark. The counter tracks 
>> the number of users who have dark mode root scrollbars due to 

Re: [blink-dev] Intent to Ship: Used color scheme root scrollbars

[Mike Taylor]

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. :))


On 3/2/24 1:10 PM, Daniel Bratell wrote:


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

On 2024-03-01 21:10, 'Yaroslav Shalivskyy' via blink-dev wrote:


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


On Friday, March 1, 2024 at 5:52:55 AM UTC-8 mike...@chromium.org wrote:

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

gerc...@microsoft.com, yshal...@microsoft.com


Explainer

None


Specification

https://www.w3.org/TR/css-color-adjust-1


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

Blink>Layout>Scrollbars




TAG review

None


TAG review status

Not applicable

Any reason you think this is N/A, or have you just not requested
TAG review?



Risks


Interoperability and Compatibility

None



/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/:

Could we request signals please?



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?/

None



Debuggability

None



Will this feature be supported on all six Blink
platforms (Windows, Mac, Linux, ChromeOS, Android, and
Android WebView)?

Yes


Is this feature fully tested by web-platform-tests

?

No


Flag name on chrome://flags

None


Finch feature name

UsedColorSchemeRootScrollbars


Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/issues/40259909


Measurement

Added a use counter UsedColorSchemeRootScrollbarsDark. The
counter tracks the number of users who have dark mode root
scrollbars due to the feature. Adoption in Edge Stable
population based on this metric is approximately 13%.


Availability expectation

Initially available in Chromium browsers.


Adoption expectation

This feature immediately affects specific use cases upon launch.


Adoption plan

This feature has been through origin trials on Edge. Other
browsers adopt this feature to fix specific use cases.

Any details or feedback you can share from the Origin Trial?



Non-OSS dependencies

/Does the 

Re: [blink-dev] Intent to Ship: Used color scheme root scrollbars

[Daniel Bratell]

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

On 2024-03-01 21:10, 'Yaroslav Shalivskyy' via blink-dev wrote:


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


On Friday, March 1, 2024 at 5:52:55 AM UTC-8 mike...@chromium.org wrote:

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

gerc...@microsoft.com, yshal...@microsoft.com


Explainer

None


Specification

https://www.w3.org/TR/css-color-adjust-1


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

Blink>Layout>Scrollbars




TAG review

None


TAG review status

Not applicable

Any reason you think this is N/A, or have you just not requested
TAG review?



Risks


Interoperability and Compatibility

None



/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/:

Could we request signals please?



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?/

None



Debuggability

None



Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, ChromeOS, Android, and Android
WebView)?

Yes


Is this feature fully tested by web-platform-tests

?

No


Flag name on chrome://flags

None


Finch feature name

UsedColorSchemeRootScrollbars


Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/issues/40259909


Measurement

Added a use counter UsedColorSchemeRootScrollbarsDark. The
counter tracks the number of users who have dark mode root
scrollbars due to the feature. Adoption in Edge Stable population
based on this metric is approximately 13%.


Availability expectation

Initially available in Chromium browsers.


Adoption expectation

This feature immediately affects specific use cases upon launch.


Adoption plan

This feature has been through origin trials on Edge. Other
browsers adopt this feature to fix specific use cases.

Any details or feedback you can share from the Origin Trial?



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

Re: [blink-dev] Intent to Ship: Used color scheme root scrollbars

['Yaroslav Shalivskyy' via blink-dev]

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

On Friday, March 1, 2024 at 5:52:55 AM UTC-8 mike...@chromium.org wrote:

> 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 
> gerc...@microsoft.com, yshal...@microsoft.com
>
> Explainer 
> None
>
> Specification 
> https://www.w3.org/TR/css-color-adjust-1
>
> 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 
> Blink>Layout>Scrollbars 
> 
>
> TAG review 
> None
>
> TAG review status 
> Not applicable
>
> Any reason you think this is N/A, or have you just not requested TAG 
> review?
>
>
> Risks 
>
> Interoperability and Compatibility 
>
> None
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Could we request signals please?
>
>
> 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?*
>
> None
>
>
> Debuggability 
>
> None
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, ChromeOS, Android, and Android WebView)? 
> Yes
>
> Is this feature fully tested by web-platform-tests 
> 
> ? 
> No
>
> Flag name on chrome://flags 
> None
>
> Finch feature name 
> UsedColorSchemeRootScrollbars
>
> Requires code in //chrome? 
> False
>
> Tracking bug 
> https://issues.chromium.org/issues/40259909
>
> Measurement 
> Added a use counter UsedColorSchemeRootScrollbarsDark. The counter tracks 
> the number of users who have dark mode root scrollbars due to the feature. 
> Adoption in Edge Stable population based on this metric is approximately 
> 13%.
>
> Availability expectation 
> Initially available in Chromium browsers.
>
> Adoption expectation 
> This feature immediately affects specific use cases upon launch.
>
> Adoption plan 
> This feature has been through origin trials on Edge. Other browsers adopt 
> this feature to fix specific use cases.
>
> Any details or feedback you can share from the Origin Trial?
>
>
> 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 
> https://chromestatus.com/feature/5089486318075904
>
> 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 blink-dev+...@chromium.org.
> 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
>  
> 

Re: [blink-dev] Intent to Ship: Used color scheme root scrollbars

[Mike Taylor]

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

gerch...@microsoft.com , 
yshalivs...@microsoft.com 



Explainer

None


Specification

https://www.w3.org/TR/css-color-adjust-1 




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

Blink>Layout>Scrollbars 




TAG review

None


TAG review status

Not applicable

Any reason you think this is N/A, or have you just not requested TAG review?



Risks


Interoperability and Compatibility

None



/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/:

Could we request signals please?



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?/


None



Debuggability

None



Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes


Is this feature fully tested by web-platform-tests

?

No


Flag name on chrome://flags

None


Finch feature name

UsedColorSchemeRootScrollbars


Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/issues/40259909 




Measurement

Added a use counter UsedColorSchemeRootScrollbarsDark. The counter 
tracks the number of users who have dark mode root scrollbars due to 
the feature. Adoption in Edge Stable population based on this metric 
is approximately 13%.



Availability expectation

Initially available in Chromium browsers.


Adoption expectation

This feature immediately affects specific use cases upon launch.


Adoption plan

This feature has been through origin trials on Edge. Other browsers 
adopt this feature to fix specific use cases.

Any details or feedback you can share from the Origin Trial?



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

https://chromestatus.com/feature/5089486318075904 




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 blink-dev+unsubscr...@chromium.org.
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 
.


--
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+unsubscr...@chromium.org.
To view this discussion on the web visit