LGTM2
On 3/26/24 1:25 PM, Yoav Weiss (@Shopify) wrote:
LGTM1 once the fix
<https://chromium-review.googlesource.com/c/chromium/src/+/5386749> 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
<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
<https://issues.chromium.org/issues/328102503>. 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
<https://en.wikipedia.org/wiki/Main_Page> and
amazon.com <http://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)
<https://github.com/mozilla/standards-positions/issues/995>
WebKit: [css-color-adjust-1] Root
non-overlay scrollbars used color scheme ·
Issue #326 · WebKit/standards-positions
(github.com)
<https://github.com/WebKit/standards-positions/issues/326>
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
<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
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELayout%3EScrollbars>
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
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
No
Flag name on chrome://flags
None
Finch feature name
UsedColorSchemeRootScrollbars
Requires code in //chrome?
False
Tracking bug
https://issues.chromium.org/issues/40259909
<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
<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
<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 <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
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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/LV3PR00MB17488611D88C9E41AC6A806BA95F2%40LV3PR00MB1748.namprd00.prod.outlook.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 blink-dev+...@chromium.org.
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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/34e66337-a227-4521-93bc-42317a1659b4n%40chromium.org?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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5f1cf187-dbc3-4b07-a73f-6cdf120aeba7%40chromium.org.
