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: Mason Freed via GitHub <sysbot+gh@w3.org>
Date: Tue, 18 Aug 2020 23:19:11 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-675765798-1597792750-sysbot+gh@w3.org>
@atjn thanks for the detailed input!

> Some feedback from a developer trying to create this design in Chromium:
> ...but with the clock icon also pink.
> In my head, the clock icon is a `primary` color, the same way the text color is `primary` and the black background is `secondary`/`contrasting the primary`. By that logic, i should write `accent-color: currentColor`.

I definitely see your point. I had trouble defining which element comes first/second here. And again my goal was to allow `accent-color: blue` (single color only) to make the most "visible" part of each control blue. With that goal in mind, my concern with the clock input, which (in **current implementations**) has just a glyph but no background "panel" behind it, is: what happens if new implementations would like to have a background color behind **just** the glyph? E.g. similar to some implementations of `<select>`:

<img width="83" alt="Screen Shot 2020-08-18 at 2 58 52 PM" src="https://user-images.githubusercontent.com/29559695/90570013-c61ca780-e163-11ea-90a6-3e8ad3112716.png">

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? I.e. the blue in the `<select>` above, **not** the white glyph. The canonical example is the checkbox, where typically you would want `accent-color: blue` to give you this:

<img width="26" alt="Screen Shot 2020-08-18 at 4 17 05 PM" src="https://user-images.githubusercontent.com/29559695/90574649-4fd17280-e16e-11ea-9d30-fb7589716aaa.png">

where the **background** is blue, not the checkmark glyph. 

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. As currently defined in the proposal, your [example](https://timewarp.atjn.dk/) could be perfectly achieved with `accent-color: #171717 #ff67bd`. Right?

> > It would also be good to get input on whether there is a need to provide the "contrasting" color at all, or if it would be good enough to just control the "primary" color and always leave the contrasting elements to the UA.
> For this specific usecase, i just need primary. But i am certainly looking forward to having full control over checkboxes and radio buttons. Only having a primary color would be limiting to me in that case.

Thanks for the input here.

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 18 August 2020 23:19:14 UTC

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