Re: [csswg-drafts] Allow specifying the "accent color" of a form control element (#5187)

@mfreed7 is there a reason that we aren't using primary, secondary, tertiary for names? As we discussed on the call and @fantasai correctly pointed out:

> fantasai gave example of radio button, where Chrome 83 and Safari differ in whether the accent color is used for foreground or background, but both are using the accent color reasonably

This would allow the UAs to follow their design systems as they will have defined these colors. Also, I think that accent-color makes OS/UAs map it to their accent color that can be adjusted by the user and may propagate into an aspect of the control replacing the primary/secondary of their own brand for user benefit.

Ultimately, I'm fine with the above general consensus about not needing every part defined and which gets which color. My only other question then however is how can we test this? For this specific feature it seems that the definition of interoperability will be that it is implemented and the "spirit" is followed. Not sure how to make that work outside of render tree tests (since the parts may not be accessible early on) to determine if the accent color is leveraged.

Finally, I'd be curious if the wording is adjusted to ensure that spirit and provide a few concrete examples (as you've already done) if that won't be sufficient. I think that will address @hober concerns and if we can determine an agreed way of testing which will effectively determine spec compliance that will ease my concerns. (basically, I'm trying to avoid @mfreed7 from having to do even more research if it won't move us towards resolution).

-- 
GitHub Notification of comment by gregwhitworth
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5187#issuecomment-676557578 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 19 August 2020 17:23:39 UTC