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: Anton via GitHub <sysbot+gh@w3.org>
Date: Wed, 19 Aug 2020 08:43:21 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-675960139-1597826600-sysbot+gh@w3.org>
@mfreed7 no problem, this spec is great work!
I would like to make it clear that i understand your approach to the design system, and if that's the way the final spec lands, that would be fine :)

> As currently defined in the proposal, your example could be perfectly achieved with accent-color: #171717 #ff67bd. Right?

That is correct, but in that case i am defining a color that does nothing. It is only there to fill the first space so i can set the second value. That doesn't seem like a robust solution to me. If the order was swtiched, i would be able to define only the necessary color:
`accent-color: #ff67bd`

i understand that this would mean you would have to define `accent-color: auto blue` in order to set the background of a checkbox to blue, but the difference is that `auto` actually refers to something that will be displayed on the page (the checkmark glyph), so it makes more sense to have to define that IMO.

I think most of these problems could also be solved if we just had direct access to the primary and contrasting colors:
`accent-color-primary: <color>`
`accent-color-contrasting: <color>`
`accent-color-extra: <color>+`   (or something like that)

So there is definetely and argument to be made for direct access to the values, but the way i subjectively see it, the system would be most elegant with just the shorthand, but the order flipped. My argument can be summed up into:

|                             | if `primary` is background     | if `primary` is glyph   | either version, using direct access to values     |
| :------------------------------------------------------------------------------------ | ---: | ---: | ---: |
| accepts single value for inputs with background as primary (checkbox, radio) | ✔️ | ❌ | ✔️ |
| accepts single value for inputs that don't have backgrounds (textarea, time)   | ❌ | ✔️ | ✔️ |
| does not force the use of filler colors that don't exist                                        | ❌ | ✔️ | ✔️ |

> [...] what happens if new implementations would like to have a background color behind just the glyph? [...]
> In that case, it would seem that the "primary" color, which you would like to match with the rest of the site, would be that background fill, not the glyph, right?

Yes, that is probably true for many websites, but in [the design i posted earlier](#issuecomment-675141914), the glyph would still be the primary accent color, and i would want the background to be fully transparent.
What ends up being the primary accent color is dependent on the design choices on every page, which is also why i find it more intuitive to call them `glyph`/`foreground` and `background` accent-colors, or to base the `primary` assignment on the fact that glyphs are usually always the `primary` color.

> Again, these are all reasons why I think it is important to be able to specify both colors, and to have an agreed upon set of definitions for these controls - so you can always achieve your desired clock colors.

I completely agree.

GitHub Notification of comment by atjn
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5187#issuecomment-675960139 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 08:43:22 UTC

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