System Accent Color scoping change - I2S or PSA?

[Alexander Kyereboah]

Hello Blink API owners!

There's a slight change in available scope for a shipped API where we're wondering whether it requires an I2S, or if a PSA will suffice. 

For context, currently on Chromium form controls (radio buttons, checkboxes, etc.) styled with `accent-color: auto` adopt the user's system accent color as shipped in this Chrome Platform Status. This is the case in all contexts, including PWAs. 

However, with recent CSSWG signals we're looking to scope the availability of form controls using the system accent color to just PWAs. This is to match the available scope of a closely related system accent color feature (AccentColor and AccentColorText keywords) to provide more consistency for developers and align on fingerprinting concerns.

The question here is- do we need the full Blink process for this change? Or just notify the scope has changed with a PSA?

Developers won't have to write or delete any code, and vendors such as Firefox already don't expose the system accent color to form controls so we don't anticipate any developers relying on this behavior. The primary noticeable change is that form controls that were styled with `accent-color: auto` will display the default color instead of the user's system accent color. 

Thanks for your help!
Alex 

[Yoav Weiss (@Shopify)]

Thanks for reaching out!

It sounds to me like there's risk there. Is it possible that the style is relied on in ways that users would perceive sites as broken after this change?

If so, than an I2S is probably the right way to go

 

Thanks for your help!
Alex 

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/2abb03a1-7fc6-4074-810e-c228b4ee418bn%40chromium.org.

[Alexander Kyereboah]

There is a possibility this could appear broken for some users, since the rendered accent color in form controls would change for users that have set a system accent color at the OS level.
However, other changes to system colors in the past haven't generated any user bug reports, so we don't expect this to be obvious for most users.

On the contrary, we were initially getting quite a few bug reports as we rolled this out as users started reporting confusion around hard to see form controls (their system accent color was set to gray/white for example). Firefox decided not to expose the system accent color as a result, so I don't think users or developers have an expectation for their OS colors to be reflected across the web outside of apps. 

If we find that there are somehow issues that pop up, we can definitely use Finch to roll back the scoping change as well.

[Mike Taylor]

My reaction here is "This is probably fine, but I have a few questions" (i.e., understanding vendor positions (in particular what does Safari do?), reading the spec and relevant discussions, do you have a finch feature name, some high-level metrics etc) that are helpfully answered by an I2S.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/a2cc9bd2-d78e-4401-a0d2-82972b2ea426n%40chromium.org.

[Alexander Kyereboah]

I'll follow up in blink-dev with an I2S then, thank you!

[Mike Taylor]

Thank you!

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/2e5f1360-d9e1-4ee6-ac9c-71264fcf6151n%40chromium.org.