W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2020

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

From: Mason Freed via GitHub <sysbot+gh@w3.org>
Date: Thu, 15 Oct 2020 19:25:28 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-709542140-1602789927-sysbot+gh@w3.org>
I'm going to close this issue.

In trying to nudge the `accent-color` discussion forward, I may have inadvertently gotten the discussion off on the wrong foot. This is an early stage proposal, and I have been actively trying to be wide-open to feedback and community discussion. **I want help getting to a good solution here, and I'm not trying to push one particular approach.** At the same time, I'm excited at the possibility of moving form control styling just a little bit forward, so I've been trying to ***focus*** the discussion and build stepping stones toward a good solution. As part of that approach, I opened [this issue](https://github.com/w3c/csswg-drafts/issues/5480) to try to clarify how much "precision" this new feature needs. I chose an unfortunate title that represented my personal bias, which is toward more precision. It also seems that some people took what I said as asking for a simple choice between two concrete proposals. That could not be further from the truth, and I'm sorry for the misunderstanding. I've also heard that some people may have thought I'm advocating for "Chrome's current behavior", which I don't believe I wrote or implied, but to be clear: this is not what I was trying to advocate. I believe we need to specify this feature in such a way that browser individuality and innovation are not hampered.

At this point, though it definitely requires reading between many lines, it seems that most people think it will be too difficult to specify `accent-color` with as much **precision** as I was going for in [my proposal](https://github.com/mfreed7/accent-color/blob/master/proposal.md). I think most people seem to agree that I was biting off too much functionality (too much control of element parts) - we're not ready or able to do that much right now, and perhaps not with a feature like `accent-color`. There are many comments to this effect, e.g. [1](https://github.com/w3c/csswg-drafts/issues/5480#issuecomment-701567648), [2](https://github.com/w3c/csswg-drafts/issues/5480#issuecomment-705194441), [3](https://github.com/w3c/csswg-drafts/issues/5480#issuecomment-704322971), and several others. I don't see much objection to *wanting* to open up more control of form control styling, just the general feeling that it'll be tough, given the current state of form controls, to do it with `accent-color`. I definitely understand that position, and I'm (slowly) coming around to agree with it. To allow more specific, precise control over the pieces of form controls will require the addition of pseudo-elements, and/or efforts like [Open UI](https://www.w3.org/2020/10/12-css-minutes.html), and/or other features.

In the meantime, I **know** that we all want to maximize the interoperability and usefulness of this feature. The main problem is how to also do so while recognizing the complex situation of form control design past & future. Pixel-perfect or other more prescriptive approaches to the specification of this feature seem unworkable.

Again, for the reasons above, I'm going to close this issue. But hopefully we can continue the discussion back on the [main issue](https://github.com/w3c/csswg-drafts/issues/5187) with alternative proposals.

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 15 October 2020 19:25:30 UTC

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