W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2020

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

From: Greg Whitworth via GitHub <sysbot+gh@w3.org>
Date: Wed, 19 Aug 2020 00:58:49 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-675791426-1597798728-sysbot+gh@w3.org>
Awesome work on this Mason. Just a few thoughts.

> for example to maintain design guidelines

Isn't this a get out of jail free card?

> Glad you think so! I'd be really interested to hear specific per-control feedback, as I think this process (haggling over each one) might take some time, but it's important to the spec here.

I think this is a **fundamental** contract for this feature to be of value. _You_ note as such in your text above it.

> This is important to ensure good interop of the `accent-color` property. 

You then take this a step further in saying:

> Not all form elements contain “accent” parts, and not all user agents use the same “accent” parts in exactly the same way for the same form control. However, the intention is that if the same or similar accent parts exist on a given form element, it should be associated with the "primary" or "contrasting" colors in the same way across user agents.

This reads to me that you're saying that UAs, if they have the same parts, should then informally standardize through their 
 implementation of accent-color for those overlapping parts. Due to the above two statements I don't think that the definitions of these parts and the application of accent color should be non-normative.

I understand that defining and agreeing on every part is **not an easy** undertaking for form controls. However, I'd prefer for us to begin defining those parts and their associated accent colors. And as each control part definition lands in this spec it allows implementation of that control.

We can have an escape hatch since I know there will be arguments that a UA should be able to implement a part using the accent color provided the user in a way that isn't defined by the spec but that breaks the contract outlined above for interop purposes. We should have the normative definitions that are assigned to standardized parts be required to use the accent color defined *IF* `accent-color` does *not* compute to `auto`.

This will then allow an author to look at any UA and know that the glyph within the checkbox *will* get the contrasting color while the background will receive the primary color. Again, the author can opt into the native design by allowing this to compute to auto.

Ultimately, this discussion and the one in Open UI makes me feel like we need an agreed upon base UA stylesheet to solve the real pain points form controls present to authors while ensuring we don't stifle innovation for UAs.

-- 
GitHub Notification of comment by gregwhitworth
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5187#issuecomment-675791426 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 00:58:51 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:13 UTC