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

> But... that's totally wrong. The proposed spec (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.

That's not correct, unless you really mean that Chrome is going to be changing its form rendering further.

Currently (with a default accent color of blue), Chrome does a blue-bg/white-check *when the checkbox is checked*. It does a white bg *when the checkbox is unchecked*.

On the other hand, all other browsers currently default to a white bg *in all cases*, with a check colored black (or possibly according to 'color').

This is an issue! If I say "accent-color: black white" and get a black-bg in Chrome, but a white bg everywhere else, that's a *huge* rendering difference that renders the feature unusable.

I've said it a few times already, but if Chrome's UA stylesheet *explicitly* reversed the 'accent-color' ordering on `[checked]`, *then* it would be ok, like:

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

This would mean that if an author just wrote `input { accent-color: black white; }`, they'd get a white-bg checkbox with a black check, in either mode. That's good! It's predictable now, so an author can actually use the feature and match it against their page background, without having to defensively add a mid-colored border because *some* browsers would display it black and *others* would display it white.

>  The proposed spec (one of the many possible A camp proposals),

In the call you defined "Option A" as "what's currently in the spec", and then framed the options as just "keep the spec" or "remove all normative text and let it mean whatever". Both of those are unusable, is what I'm saying.

If by "option A" you mean "some variety of reasonably explicit specification, a la the current spec but not necessarily matching it in details", then yes, that's the exact thing I've been saying we needed for this to be a feature *at all* this entire time. It becomes a false choice, because B is just "not defining the feature at all".

I highly suspect this is why you're running into such trouble on the calls! Your "Option A" occupies an uncertain shadow zone between "exactly this text" and "something in this direction", and people don't want to vote for "something in this direction" if it's gonna end up being interpreted as "exactly this text", particularly if their actual vote wants to be "something in this direction, assuming it turns out good, which we haven't seen yet".

I will make my position as clear as possible, tho: if we undefine the entire feature (your "Option B") I will object to the feature. I won't allow CSSWG to accept something that will end up useless because of browser differences; we haven't gone without form styling for two decades for this exact reason to just shrug and poison the well for future attempts. I strongly believe there *is* a usable, interoperable set of definitions that don't unduly restrict browser variation, and the current spec is *nearly there*, but not quite yet.

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


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

Received on Friday, 2 October 2020 22:26:19 UTC