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

I am somewhat lost here. I know there is some disagreement even on this point, but here's what I believe needs to be decided:

**A**: developers can assume that a given `accent-color` setting will result in *roughly* the same colors going in *roughly* the same place on a given control type, across browsers. We can't get more precise than "roughly" because form control painting is not specified.

**B**: developers can assume that a given `accent-color` setting will be used *in some way*, if possible, but not necessarily in the same place across browsers. On one browser, the **background** of a checkbox might use the `accent-color`, while on another browser, the checkmark **glyph** might instead use the `accent-color`.

I do (strongly!) believe this is a fundamental decision that needs to be made **before** we start debating the details of exactly **how to achieve** that goal, and how to exactly specify the `accent-color` feature. At the moment, we're going in circles because we're simultaneously debating the basic A vs. B question, and also the exact nuances of the definitions of specific proposals for A and B. We need to decide on a general path first, please.

@tabatkins, you are the most vocal critic of the above position. In particular, you said this (emphasis mine):

> > Please disregard questions about how the details of each of the above options are to be specified. Those are great questions. But we first need to decide the basic structure of this feature, by deciding on A or B.
> 
> No, we can't. The question you're trying to ask already has an answer: the property needs to be specified well enough that authors can get reasonable results across browsers (however that happens) and no farther; overspecifying is a no-go because there's too much variation already (and always will be), while underspecifying makes the entire property worthless. So this isn't actually a question needing to be addressed, and answering it anyway doesn't help you advance this spec in any meaningful fashion.
> 
> The question needing to be answered is **precisely what the colors in 'accent-color' are/do**. I've given a proposal that I think actually works. The current proposed spec _does not work_; it will give results - such as `accent-color: black white` giving a checkbox with a white background in some browsers and a black background in others - which make the property effectively useless for authors to actually match the controls to their page in a way that reads properly.

But... that's totally wrong. The [proposed spec](https://github.com/mfreed7/accent-color/blob/master/proposal.md) (one of the many possible **A** camp proposals), when given `accent-color: black white` will **definitely give a checkbox with a black background and a white glyph**. As much as is technically possible to do, it tries to define, for each control, [how to use each of the accent-color values](https://github.com/mfreed7/accent-color/blob/master/proposal.md#per-control-guidance). In any other spec, this would be normative and more precise, but in the land of form controls, where nothing is defined, this is as close as one can come. It tries to, as precisely as possible, specify **what the colors in `accent-color` are/do**. Is there a specific part of the proposal that you believe is missing this mark? And either way, would you not agree that you're firmly in the **A** camp, by striving to define "precisely what the colors...are/do"?

You also said this:

> 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.

Except that, modulo bikeshedding the names (primary vs. secondary), the spec does **not** allow those colors to map to entirely different presentations. It does **exactly the opposite of that**. It says this:

<pre>
...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. ... For that reason, there is a table of form elements
provided below, which serves as guidance on the various accent parts for each
control. While the table is not normative, it is intended to provide some
alignment and uniformity of implementation across user agents.
</pre>

And then the [section for `<input type=checkbox>`](https://github.com/mfreed7/accent-color/blob/master/proposal.md#input-typecheckbox) says:

<pre>
A checkbox is typically composed of a "checkmark" glyph on top of a shaded
background. The glyph should be considered a "contrasting" accent, while the
shaded background behind the glyph should utilize the "primary" accent color.
</pre>

The combination of these two pieces of text mean that the first `accent-color` value should always be the background of the checkbox, and the second `accent-color` value should always be the glyph.

In contrast, @fantasai's proposal **explicitly allows** each UA to independently decide how/where to use `accent-color` values (emphasis mine):

> Expected UA usage would be to take **whatever part of the form control** is in the accent color, and retheme it using a color from accent-color.
> (It would **not give absolute control over which part** uses which color, but that isn't the design goal: replacing the UA's accent color with the author's accent color while ensuring sufficient contrast for usability is the design goal.)

That would seem to indicate that one browser might consider the `<input type=date>` activation **glyph** to be the "accent" part, while another considers the **background** behind that glyph to be the "accent" part. Thus, the same setting of `accent-color:green` could result in either this &nbsp;&nbsp; <img width="33" alt="date1" src="https://user-images.githubusercontent.com/29559695/94761144-2b65da00-0359-11eb-92bb-e2d561eb4b71.png"> &nbsp;&nbsp; or this &nbsp;&nbsp; <img width="33" alt="date2" src="https://user-images.githubusercontent.com/29559695/94761149-2e60ca80-0359-11eb-9b2a-e862d69e61d8.png">. That seems very explicitly in the **B** camp.



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


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

Received on Thursday, 1 October 2020 03:33:01 UTC