- From: Mason Freed via GitHub <sysbot+gh@w3.org>
- Date: Fri, 02 Oct 2020 23:02:37 +0000
- To: public-css-archive@w3.org
@tabatkins thank you for the detailed answer. I finally feel a bit more like I understand the miscommunication. A few responses below.
> > 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.
Yes, if `accent-color` is adopted, and for a control that has a computed value other than `accent-color: auto`, **Chrome would change its rendering to comply with the spec**.
> 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.
Right! This is why I created this issue and have been lobbying for other implementers to say what I'm about to say: if an author says `accent-color: black white` then they should get the **same color background in all browsers**. A.k.a. **option A**.
> 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:
Yes, this is exactly what I'm thinking we'd do. Define the current Chrome behavior in the UA stylesheet by defining both `input` and `input:checked` with colors reversed. And then if a developer set `accent-color` to some other value, we'd respect that instead, and not change the background when checked/unchecked.
> 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.
Yep! Again, *hurray for option A*!
> 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".
Yes. I think the disconnect is that I assumed people had read [my opening comment on this issue thread](https://github.com/w3c/csswg-drafts/issues/5480#issue-687595307). Everything else I have said is **in the context of that comment**, and was just meant to clarify. I think it did the opposite. I just want to ask the very basic question: should `accent-color: red blue` put the red and the blue in roughly the same place across browsers? Or not? The **details** of how to achieve that should **follow** the basic decision about **whether** the spec should be this explicit.
> 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.
Thanks. I'll take that as a vote for **option A**. I suspect others on this thread will vote for **option B**. Hopefully with this clarification, we can debate A vs. B without referring to the specifics of A or B (or "C"!).
--
GitHub Notification of comment by mfreed7
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5480#issuecomment-702992798 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 23:02:39 UTC