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

Re: [csswg-drafts] Allow specifying the "accent color" of a form control element (#5187)

From: Mason Freed via GitHub <sysbot+gh@w3.org>
Date: Thu, 27 Aug 2020 23:01:02 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-682233339-1598569261-sysbot+gh@w3.org>
Ok, at the last [teleconference](https://github.com/w3c/csswg-drafts/issues/5187#issuecomment-680996476), there was significant discussion about encouraging interoperability while not constraining innovation, and the inherent conflict therein. I also heard a suggestion from @astearns that it might help to include more prose explaining the motivation and intent for the spec, because it will aid in interpreting the specification. So I've gone ahead and done that - please see the [new section of the proposal](https://github.com/mfreed7/accent-color/blob/master/proposal.md#motivation-and-intent). I also copied it inline below.

Separately, I heard a recommendation that separate issues be opened for the sub-questions being debated here:
 1. Should we go forward with `accent-color`? This was [resolved](https://github.com/w3c/csswg-drafts/issues/5187#issuecomment-680996476) yesterday.
 2. Should we constrain browser vendor innovation of form control elements? I have not heard anyone argue that we should, so I'm going to just take it as a given that we shouldn't.
 3. Should interoperability be a goal for the `accent-color` spec? I [filed an issue](https://github.com/w3c/csswg-drafts/issues/5480) for this question.

While there are additional issues, I think <span>#</span>3 is a key question. A decision there will guide the rest of the process.

Here is a copy/paste from the new proposal section:

---

# Motivation and Intent

This section is non-normative.

In implementing `accent-color`, there are two competing/conflicting goals:
1. **Encourage interoperability** among browsers. It is important that developers be able to expect similar, if not the same, behavior across browsers.
2. **Encourage** (and do not constrain) browser vendors' **innovation** of form control elements.

The goal of interoperability pushes this solution towards a more strict specification of exactly how to use each `accent-color` value on each form control element. However, the goal of allowing innovation pushes this solution **away** from strict specifications for how each form control looks or acts. This specification attempts to provide a good middle ground, which maximizes interoperability while minimizing constraints to innovation.

The general methodology for achieving the above compromise is to examine the set of existing form control elements ([as of 2020](https://github.com/mfreed7/accent-color/blob/master/proposal.md#existing-control-examples-as-of-2020)), and agree on the *basics* of the way `accent-color` is applied to each of those existing controls. It is *explicitly* recognized that each browser provides different implementations of each form control, with their own look and feel. This spec does not try to eliminate those differences. However, it does try to provide some level of uniformity and interoperability, where commonalities exist.

This will require judgement when applying the recommendations to new or existing form controls. The goal would be to adhere to the *spirit* of this spec as much as possible. For example, if the guidance states that an `accent-color` value should apply to a particular accent part, and the browser implementation of that part uses a gradient fill rather than a single color, then there may be multiple ways to "use" the `accent-color` value to affect the gradient rendering of that part. The goal would be to match the guidance where it makes sense, and when possible. That might mean replacing the gradient with a solid fill, or it might mean changing the endpoint values of the gradient to match the `accent-color` value *in aggregate*. Or it might mean another behavior entirely. The point is that the guidance should be consulted and used as input in determining how to proceed.

Further, this spec is careful to not **require** exact conformance of each form control with the `accent-color` spec. It merely encourages browsers to follow the guidance for form controls elements that are "close enough" to the existing set of controls. For brand new paradigms, input surfaces, control types, etc., this spec does not attempt to limit innovation. If there are similar **parts** of these new-paradigm controls, then as much as possible/reasonable, those parts should be guided by this spec. But this should not be seen as any limitation on innovation.

To assist in characterizing "close enough" as it relates to the accent parts of form control elements, the [Existing Control Examples](https://github.com/mfreed7/accent-color/blob/master/proposal.md#existing-control-examples-as-of-2020) section of this document includes many examples of several control types, pulled from different browsers, operating systems, and time periods. Except where noted, each of the control examples within each group should be considered "close enough" to the group that the guidance for that group should apply.




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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 27 August 2020 23:01:05 UTC

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