Re: [csswg-drafts] [css-ui] Should interoperability be a goal for the `accent-color` spec? (#5480)

A vs B is not the important part of this; it's a vague question about the style of specification, and has little to no actual importance to the feature. The important question that keeps getting brought up and (unknowingly) skipped around is *what the colors mean*.

As I said earlier, if the property does not define what the colors mean, it's worthless. It's not a feature that people can actually use; it's entirely browser-specific.  *In particular*, if `accent-color: blue white` leads to Chrome's implementation (white bg when unchecked, blue bg when checked) in Chrome and a more "traditional" coloring (white bg all the time) in other browsers, the property is worthless and cannot be used by authors.

As I've said in the meetings, a "semantic" meaning for the colors ("primary accent", "secondary accent", etc) is worthless here, since it allows those colors to map to entirely different presentations depending on browser, preventing authors from actually controlling the colors of the controls.

The colors *must* be specified with (necessarily vague) *functional roles* - at bare minimum, "foreground" vs "background". This means that Chrome's implementation of checkboxes is, effectively:

```css
input[type=checkbox] { accent-color: blue white; }
input[type=checkbox]:checked { accent-color: white blue; }
/* assuming a "fg bg" ordering */
```

(fantasai's proposal in #5544 is thus a no-go as well; i don't think it's possible for such a semantic/contrasting definition to result in Chrome's "white, then blue" behavior.)

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


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

Received on Wednesday, 30 September 2020 16:23:53 UTC