In the discussion about the accent-color spec, the question of interoperability is central. Should interoperability be a goal for this feature? Or is it ok for different implementations to interpret/use the accent-color value(s) in different ways?

For example, is it ok for some implementations to use the accent-color to paint the background of a glyph, and other implementations to use it instead for the foreground glyph image? Or should we attempt to use accent-color in the same general way, across implementations, where possible?

In my opinion, interoperability is very important. It should not be pursued at all costs, and there should be few limits placed on browser innovation. But in general, we should strive for interoperability. Without this, developers will not be able to depend on the accent-color feature giving compatible results across browsers. For example, a developer might use a page with a blue background, and might therefore use accent-color: white to turn the background of a checkbox to white, for contrast. If some browsers instead use the white accent-color value to paint the checkmark itself, leaving the background defaulted to blue, there will be no contrast, and the site will be "broken". This developer might understandably abandon the builtin checkbox entirely, and "roll their own" checkbox from scratch. One of my primary motivations for pushing the accent-color spec forward is to allow more developers to use the built-in form controls.

The goal should be only and exactly enough specification to ensure that authors can use the property without browser-specific hacks, such that if an author makes it look good on one browser, they won't make it unreadable on another.

Anything more is overly restrictive, anything less means the feature is useless.

For example, is it ok for some implementations to use the accent-color to paint the background of a glyph, and other implementations to use it instead for the foreground glyph image? Or should we attempt to use accent-color in the same general way, across implementations, where possible?

I think it's fine to use the color in slightly different ways, so long as care is taken by the UA to ensure that the control remains usable. For example, if they use the accent color for a background color, upon which they paint some sort of control-specific glyph (a clock, a calendar, etc), then they should not paint that glyph in the element's 'color', because there's no general requirement on the author that they ensure that color pair is contrasting (unlike 'color' and 'background-color', for instance). (Or the UA could be smart and pair the colors if there's sufficient contrast, and otherwise use black/white as appropriate, etc).

For checkboxes the situation's more complex, since their entire body is just the one small bit of background with a glyph. Chrome recently switching to making it white-on-color instead of black-on-white like it's traditionally been has certainly made this more... interesting. I'm not sure what to do there.

I was intrigued by one thing fantasai proposed during the meeting, which might help strike the right balance here.

Based on the same syntax as today, you could say:

accent-color: dark-blue, light-blue;

But unlike what the current version suggests, this would not (necessarily) mean a request to set the accent/backgroundy color to dark blue AND the contrasting/foregroundy color to light-blue, but rather to set the accent/backgroundy color to dark blue OR the contrasting/foregroundy color light-blue. Which one gets used depends on which part of the native control is normally accented.

If the native control actually uses two distinct colors, the UA would probably use both, but in typical case where only one part is accented, the author wouldn't be telling the UA which part to use the accent color on, merely providing appropriate colors to use.

And if you only provide one, the other is synthesized, but the pair is still used to pick the right color from.

That way, we neither insist on accenting the "wrong" part of the control (according to platform conventions), nor end up with the color used in the wrong place and failing at contrast.

@frivoal thanks for the interesting suggestion. It might provide a more palatable implementation path for some rendering engines. I want to point out, though, that I think this is a fully compatible interpretation of the existing proposal, as written. As mentioned multiple places in the spec, UAs are given freedom to decide when to use the provided accent-colors. The spec primarily tries to say that if the UA uses an accent-color on a particular control, it should attempt to be consistent with the other UAs. I.e. in your example above, it seems perfectly ok to not use one or the other color. The spec is mostly trying to avoid "mixing" the colors in an unpredictable way. I.e. the first color (dark-blue) should be used for the "backgroundy" color, or not used at all, but it should not be used as the "foregroundy" color.

If something in the proposed spec seems to contradict the above, please do point it out.

I don't think it really contradicts the model as described, or would be forbidden by the normative text, but in terms of emphasis and intent, it is a little different, and so the wording should probably be adjusted. Possibly in the 4th paragraph, and then in the informative examples, showing a foregroundy check-box and a backgroundy one, and how they'd stay as they are, just using a different part of the supplied color list (and possibly showing how auto would work out in that context).

I like form elements to feel "native" to the browser and OS I'm using. If I'm on Chrome, I want the checkboxes and drop-downs to feel like Chrome checkboxes and drop-downs. If I'm on Safari, I want the checkboxes and drop-downs to feel like Safari checkboxes and drop-downs. So, I like the idea of specifying an accent color and allowing browsers to decide where to use it.

This lines up with how most operating systems use accent colors: In macOS, Windows, iOS, and Android, when a user or developer sets an accent color, they don't decide which parts of the OS or sections of a control inherit that color. To me, that's what differentiates an "accent color" from a color or background-color. If an author wants to override colors on a specific piece of a control, I think they should be able to target that piece of the control and apply a color or background-color to it.

I think an author should ultimately be able to customize everything about a form element with CSS, but appearance: none; and hopefully Open UI will allow for that level of customization, using standard CSS color and background-color properties. An "accent color" as defined in modern operating systems is something different.

The CSS Working Group just discussed [accent-color] Should interoperability be a goal for the `accent-color` spec?.

The full IRC log of that discussion

<dael> Topic: [accent-color] Should interoperability be a goal for the `accent-color` spec?
<dael> github: https://github.com/w3c/csswg-drafts/issues/5480
<masonfreed> https://github.com/mfreed7/accent-color/blob/master/proposal.md#motivation-and-intent
<dael> masonfreed: Heard 2 things from last time. One is ^ to add motivation and intent to help interpret written spec. I wrote that.
<dael> masonfreed: tl;dr is it's to provide a compromise between interop and not constraining browser impl.
<dael> masonfreed: Today is interop question. Are we going for interop? It's fundamental. Depending on your answer the spec changes. Should it be same across or hint to browsers?
<dael> masonfreed: My opinion is useful either way but lose a lot if don't strive for interop.
<dael> masonfreed: 2 reasons. 1 is not easily usable by devs without browser sniffing. Could also cause a11y and contrast issues if different expectation as to where the color goes. blue background, white accent for checkbox and you assume that's the background. If browser colors the check white you have contrast problems.
<dael> masonfreed: I started this with the idea of a single color and went through how it works for each control. Realized it's hard to use without language on how it's used for all controls. Helpful to look at examples section
<dael> masonfreed: Question today is should accent color be interoperable.
<dael> myles: Background concern is being able to match platform form controls is valuable. Some browsers system framework needs to fit in. Don't want to have 2 sets of form controls for web content vs rest of OS
<emilio> q+
<dael> masonfreed: I think if you as a dev want to make form controls match platform it's easy, don't spec anything for fonm controls and it matches. If you spec colors you're trying to change away.
<astearns> ack emilio
<jensimmons> q+
<TabAtkins> q+
<dael> emilio: I feel a bit the same as myles. If we try and spec form controls...dev may spec accent color b/c chrome handles it and they don't look native but look better if you change accent color. I'm not sure your argument applies that some browsers will honor colors and others won't.
<myles> q+
<myles> q-
<dael> emilio: For some platforms like Windows and MacOS (I think) we don't have much control over which colors are native and which are for form controls. Alternatives are remove native but you don't want to do same as appearance:none, right?
<dael> masonfreed: Right. Idea here is make basic style of color easier for developers.
<myles> q+
<dael> masonfreed: The intention of proposal is that it's open to not do anything. It's explicit you can disregard a color. It says if you are going to respect it you should try and use it same way as everybody else. If you don't want to control colors of native form controls you can do that. But if you use accent color you should do it same as everyone else
<dael> emilio: But if Gecko and Wk want to keep native appearance we have to impl form controls twice if we want to honor it sometimes.
<dael> myles: Another way to say this, this is a world where some browsers impl intentionally and some done. Some browsers use own native design and others use non-native custom design. That doesn't sound like consistency. That world answers the question, it isn't consistent.
<dael> masonfreed: Agree form controls are all different. Is that what we want is the question. If we're adding something new should we point it toward interop?
<una> q+
<astearns> ack jensimmons
<dael> jensimmons: I think there's 2 ways to look at this. One is what we're discussing from impl. From author PoV is the other.
<myles> q-
<dael> jensimmons: I think some of what you're asking masonfreed gets at the root of the idea where coming up with accent color as the property...another way to do is pseudo class for checkmark and another for checkbox....having something more vague implies the idea we're not giving you a bunch of hooks
<dael> jensimmons: If I expect to say my checkbox bg is blue I expect that everywhere. But when it comes to saying accentColor: blue it's impled by the property and the name that hey author welcome to the wide world of chaos and there is not consistency even in the same browser what's happening
<dael> jensimmons: I thought the idea is hey we know it's chaotic so we're going to give authors something that's more generic and we'll give authors a way to say my accent color is blue and it's not interop in a way that pixel perfect designs would imagine
<dael> masonfreed: I appriciate and understand that. That is still my intent. Range looks different across everything. I think the realization I made going through each control is there are in a lot of cases 2 places where accent color comes in. There's background-y and foreground-y thing. I think we're still trying to spec something vague but add a bit more information and provide more of a hint what the dev is trying to do.
<gregwhitworth> q+
<dael> masonfreed: Providing 2 colors and some guidance feels to me helpful even to devs. Definitely helpful to devs. If building a checkbox and looks like other checkboxes it's helpful to me.
<jfkthame> q+
<dael> masonfreed: I hear we're not going pseudo classes for everything. Maybe that's down the road. This is low hanging fruit that solves a bunch of dev problems that want to make the controls the right color for their site.
<dael> masonfreed: I feel you need some level of intent about doing the same thing if you're going to do it.
<dael> jensimmons: Makes sense to put something in spec so impl aren't just making it up and everyone gets to a different idea. Say in general we think accent is here and other color is here so impl can have some guidance and not make it up from scratch or look at other browsers. But maybe just a gentle suggestion
<dael> jensimmons: You're asking should we try and get everyone to be definitely the same way and I don't know that we can say yes
<dael> masonfreed: Adding one more thing. Way we got here is there was concern about first mover problems. If one browser impl accent color then other browsers would be stuck matching. Work I did to go through each control was in response to this call saying let's discuss first up front.
<astearns> ack TabAtkins
<emilio> q+
<dael> TabAtkins: Two things. 1 to talk to myles and emilio about browsers wanting native on particulr platforms. I think that should be fine. Goal of form elements being stylable will continue to be impossible. Native form controls are weird. Spec allowing browsers to stick with native and ignore accent color is necessary and doesn't make us any worse.
<dael> TabAtkins: When talking interop, saying we need interop is nonsense. We need interop to make this a property. We need at min if it's a fg or bg color. Required to ensure element looks good against parent. This will be complex b/c things liek Chrome redesign from where checkign a checkbox swaps the bg and fg colors
<dael> TabAtkins: This means chrome cannot be using blue as fg accent and use that to draw bg. Needs to set in UA that when checkbox is checked it uses flipped. It's a work around. If we're clear that if you give 2 colors one wis fg and one is bg I think we're okay. Given there's no control what so ever right now that bit of requirements should insure enough interop even if there's a first move
<dael> TabAtkins: Means we'd have to be careful about how we spec
<astearns> ack una
<jfkthame> q-
<TabAtkins> like, `input { accent-color: blue white; } input:checked { accent-color: white blue; }` needs to be in the Chrome UA stylesheet
<dael> una: I want to speak to intent of prop. Give authors more control over form styling. Problem for 20 years. If we're giving authors more control the authros that would case want consistency across brands and OSs. My worry is it seems to be about consistency. If there's not consistency about how colors applied it doesn't solvet he issues the property tries to solve.
<dael> una: Even with having BG color it's different in Safari where there's a gradient. Solving those issues is key to making this something authors adopt. If we say here's the color and good luck and it's different across browser and OS it takes away the power of the property
<astearns> ack gregwhitworth
<dael> una: Want to argue to authori ntention in wanting consistency. If we're introducing new properties and options it should be top of mind
<dael> gregwhitworth: I would like to 100% agree with TabAtkins and una. This was something we were hoping to tackle at joint meeting and it's b/c masonfreed hit nail on head. Need to resolve if we agree this is a problem we're solving
<jensimmons> q+
<dael> gregwhitworth: There's a reason author is putting this in there. They're saying I need to change this for a meaningful reason. Way we start to address is recognizing there's potential buckets, potential capabilities we can unlock these things. We're going after the extreme far end to unlock everything. This property is more like intent
<dael> gregwhitworth: There is a spirit and an intent to say I'm coke and I want checkboxes to be coke-red. I love your checkbox but it's blue and it feels Chrome not Coke. I'm proving you a brand hint, please apply to your control in a meaningful way. That's the way it's spec.
<dael> gregwhitworth: Trying to thread the needle of allowing author to have limited control, but some control, while not biting entire problem. Feel it's a good first step.
<bradk> +1 to CocaCola example
<dael> gregwhitworth: I agree with TabAtkins that if they're using the property you should leverage it. I guar everyone has primary, secondary, etc. colors. We should be able to commit to if they're native render or not it's not un-implable.
<astearns> ack emilio
<dael> gregwhitworth: jensimmons and una hit on it. Author problem and if we feel our controls are superior to the problem author is trying to solve. Agree with TabAtkins about we should lock down. Appriciate masonfreed trying to have the spirit
<fantasai> +1 to gregwhitworth "please use this color in a meaningful way"; -1 to defining what "use in a meaningful way" means in terms of which parts get which color
<dael> emilio: Agree with sentiment
<TabAtkins> Important bit here is that the role of the colors *cannot* be semantic like "primary, secondary, tertiary". They *must* be functional like "foreground, background, shadow". Otherwise a page using "black white" for a checkbox, expecting a white box with a black check, and putting it against a black background, would look bad on Chrome where the bg is the "primary" color when checked.
<gregwhitworth> q?
<gregwhitworth> q+
<fantasai> +1 TabAtkins
<fantasai> need to ensure contrast
<dael> emilio: Concern is implementablity. We can do the work to make it work. If WK commit they can add coco APIs for Mac but no control over windows. Only alternative is re-write form controls. We may end up doing that. I don't know. If you force engines to apply it then you prevent using native form controls
<gregwhitworth> q?
<dael> emilio: If you don't it's not all that useful to authors b/c they can't customize
<gregwhitworth> TabAtkins: yeah, my point was that everyone does have colors in their control that will be able to map to the property value set
<dael> astearns: Compromise is for a browser using native controls without any capability of changing the browser could say they do not support on that platform. lets author know styles won't work as intended.
<dael> emilio: It's an option but pages could rely on colors to work
<bradk> I disagree that it should say backwards vs. foreground. If one native control has a border and another doesn’t, saying the background should be white would be much worse on the one with no border.
<fantasai> wrt accent-color, I don't think making a list of "primary/tertiary/etc" makes sense. But listing colors, against which the browser will use a "pick color with most contrast against [color/bgcolor as needed for this particular use of accent coloring]", could be a good way to do this
<astearns> ack jensimmons
<TabAtkins> gregwhitworth: Yeah, I was just countering your use of "primary" in your description. ^_^
<dael> astearns: There will always be browsers that won't support.
<TabAtkins> agree with jensimmons; this has been circling for twenty minutes when it's actually just a debate over the existence of the feature itself
<emilio> q+
<dael> jensimmons: I'm just confused as to where disagreement is. Feels like a high level debate about if we should use must/may/should in every part of the spec. Maybe some of spec should say must, some should be may, some should.
<dael> masonfreed: For me the debate is the way prop is written is the interop version. Alternative is strip away most of that to just say accent color looks like this and browsers us as they say fit. Debate is spec as written vs another spec that reads that accent color is a hint, use as you'd like
<gregwhitworth> q-
<dael> astearns: Put another way we dsicussed and asked masonfreed to make non-normative suggestions. masonfreed is coming back for validation. I think we should say yes this is what we want or no, dial back on interop
<astearns> ack emilio
<gregwhitworth> my main point here was that we can pick up this discussion at the Open UI + CSSWG meeting
<gregwhitworth> I have this as an agenda item
<gregwhitworth> as it's paramount to land on aspects of interop
<gregwhitworth> whether we do or do not
<astearns> ack fantasai
<dael> emilio: Assuming we spec this feature I think it should be sufficiently well spec so browsers and impl can do something consistent.
<TabAtkins> masonfreed: I'll make it easy: if the spec says "here's some colors, do what you want with them", I'll formally object to it. ^_^
<bradk> Seems like dark-color, secondary-dark-color, light-color, secondary-light-color would work better
<dael> fantasai: I think I would go with saying spec shouldn't mandate use of color and instead say it's a hint. If we're switching to a mode of form control with a lot of author controls we can mandate. There is a desire for authors to influence without changing render at a fundemental level.
<TabAtkins> bradk: That doesn't work for Chrome's checkboxes vs everyone else's checkboxes.
<TabAtkins> bradk: That's what I meant by "cannot use semantic roles, must use functional roles"
<gregwhitworth> q+
<dael> fantasai: Main concern should be how do we get enough contrast. Some checkmarks use fg and some bg. Need to make sure we can get enough contrast. Having examples which are here's how it's used in some browsers is good, but you're using native controls and accent color should be a hint that says I'd like to use this accent color and please use it meaningfully. But shouldn't define meaningful
<dael> astearns: So you think dial back on non-normative text of what you should do with accent color
<gregwhitworth> q-
<dael> fantasai: I don't think we should have should or must requirement
<dael> astearns: It's all non-normative. So you're okay with spec as-is?
<dael> fantasai: I'm fine with it being examples
<dael> masonfreed: All non-normative examples
<dael> myles: WE said difference is today with non-normative vs deleting the examples. What's the functional difference between the two
<astearns> https://github.com/mfreed7/accent-color/blob/master/proposal.md#per-control-guidance
<dael> masonfreed: Functionally means every impl can do own thing and may be completely different. Chrome will impl the way they want. If we delete all the text. It will just be a rough desc and no guidance as to how to use it.
<TabAtkins> And I"ll strongly object to a version fo the spec without guidance on using the colors
<iank_> Unrelated to current topic - I've added a comment to the overflow model issue: https://github.com/w3c/csswg-drafts/issues/129#issuecomment-697691447
<dael> astearns: Back to original issue, should interop be a goal? non-normative examples will likely get better interop. Removing is more likely for non-interop
<TabAtkins> No guidance = browser-specific, so this is a prefixed property, not a real property.
<emilio> TabAtkins++
<gregwhitworth> emilio: you're confusing me bud
<gregwhitworth> TabAtkins: agreed
<dael> fantasai: I think the section labeled non-normative is written with normative language. It needs to say this is how it could be done but it could be done in a different way.
<emilio> gregwhitworth: if we specify the property, we should specify what it does
<emilio> gregwhitworth: (that's what I said when I last spoke)
<TabAtkins> If someone doesn't want the property *at all*, say that; trying to water down the requirements by removing guidance doesn't do the job.
<dael> astearns: My way of thought is here's an example where if form control looks like this here's what it should do. If it looks different do what you want. But if you have something liket his should is appropriate
<emilio> gregwhitworth: That is regardless of my concerns about implementability in Gecko / WebKit
<dael> fantasai: In this case might want 2 examples. If it looks like this here's what changes and if it looks like that here's what else would change. So you can say your form control doesn't have to look exactly like that
<emilio> gregwhitworth: But I think we decided a bit ago that debating implementability was specifically a non-goal of this issues
<dael> astearns: Can we resolve to say this non-normative section is way we want to proceed?
<emilio> this issue*
<dael> astearns: Would anyone object to keep with advice on impl?
<dael> fantasai: Don't want as is, but fine with a bunch of examples
<dael> myles: Need resolutions for non-normative text?
<emilio> gregwhitworth: So I think I'm not contradicting myself, but maybe I'm wrong :))
<dael> masonfreed: Looking for next steps
<dael> fantasai: Happy to give more specific feedback. We can resolve on the normative
<dael> astearns: This issue is about non-normative
<dael> astearns: myles do you object to keeping non-normative? Want more time?
<TabAtkins> I would like this to wait for the OpenUI talk; this 40min discussion did very little. :(
<dael> myles: We're kind of out of time
<dael> masonfreed: Can I get more specific feedback on the issue?
<TabAtkins> Let's not talk about this again until there's a focused topic on it
<masonfreed> Thanks!
<dael> astearns: Anyone with specific concerns please put them in the issue and we'll do this first thing next week

The main question for this issue is:

A: Do we want this non-normative section with examples and suggestions for how to apply accent-color to improve interoperability at the expense of implementer discretion?

B: Do we want to avoid providing suggestions for how to apply accent-color in order to allow more implementer discretion at the expense of interoperability?

Once we have the answer to this question we can work on more tightly scoped issues on particular examples or how the non-normative suggestions are worded.

Thanks @astearns. To make the discussion very concrete:

The proposal for Option A is the full proposal. This includes the normative section, the Motivation and Intent section, and the non-normative examples section.

The proposal for Option B is just the normative section, with the 4th paragraph referring to "interop" removed. To make that concrete, see below.

Both of these are, of course, open for discussion, modification, etc. But the first question to answer is the basic direction - A or B.

Option "A":

The full proposal.

Option "B":

Name: ‘accent-color’
Value: <color>+
Initial: 'auto'
Applies to: form control elements
Inherited: yes
Percentages: N/A
Computed value: computed color, see resolving color values
Canonical order: per grammar
Animation type: by computed value type

The ‘accent-color' CSS property sets the color of the “accent” parts or pieces
of form control elements. The first provided <color> value is to be used for
"primary" accent elements. If a second <color> value is provided, that color
should be used for "contrasting" accent elements.  The third and subsequent
colors are only used on some form control elements in some cases, for additional
"accent" parts other than "primary" or "contrasting".

If any color is not provided, or if 'auto' is provided for any color value, then
the UA should attempt to select an appropriate color which offers good contrast
and visibility when paired with remaining provided colors, if any. In selecting
'auto' colors, if the operating system provides an “Accent Color” or similar
user setting, the UA is encouraged to respect that setting as much as possible.
The UA may use a similar, though not identical, color in some cases, for example
to enhance contrast or accessibility.

In limited circumstances, it is permissible for user agents to render the accent
parts of some controls using different colors than those specified by
'accent-color', for example to maintain design guidelines or accessibility
constraints. In those cases, the rendered color should be influenced as much as
possible by the specified 'accent-color'. For example, the UA may wish to only
render the checkbox glyph in either white or black; in this case, the selection
of white or black should depend on the 'accent-color' value, e.g. using the
luminosity of the provided color.

{...paragraph 4 removed here...}

The text content of form control elements is explicitly not included in the set
of “accent” parts, as text content is already controlled by the 'color'
property. In addition, the 'background-color' property is often used to control
the rendering for some background parts of form controls - those parts are
similarly not included in the set of "accent" parts that are subject to control
via the `accent-color` property.

Quick reminder that this is on the agenda for discussion tomorrow, Sept 30. The action item for the other participants on the call was to comment, here on the issue thread, with specific recommendations or comments. Please see the "A vs. B" comparison above for some context.

The CSS Working Group just discussed [css-ui] Should interoperability be a goal for the `accent-color` spec?.

The full IRC log of that discussion

<dael> Topic: [css-ui] Should interoperability be a goal for the `accent-color` spec?
<dael> github: https://github.com/w3c/csswg-drafts/issues/5480
<dael> Rossen_: Based on last week's discussion we want to discuss the accent-color topic one more time and see if this is something we should pursue and how
<dael> Rossen_: We're going to cap this to 10 minutes. If we cannot come to consensus we'll push back to GH until consensus there.
<masonfreed> https://github.com/w3c/csswg-drafts/issues/5480#issuecomment-697747055
<dael> Rossen_: I want to have chrishtr or masonfreed summerize outcome they're looking for and ask group if consensus. If none I want clear constructive feedback.
<dael> masonfreed: Make it crisp. Looking for resolution for A or B in link above
<Rossen_> q?
<dael> masonfreed: Looking for a direction, interop vs hint. Interop is full proposal as presented. B is a striped down version with no normative text or guidance on how to do accent-color. A or B with a link in the thread.
<florian> q+
<dael> Rossen_: Questions or feedback?
<dael> florian: Seems to be a linked issue from fantasai is a variant C. It's closer to B but not identical.
<bkardell_> are others experiencing problems with w3c infra today? I can't get to the meeting link
<fantasai> https://github.com/w3c/csswg-drafts/issues/5544
<dael> florian: That one ^
<dael> florian: If fantasai is on maybe she can explain. Part of conversation
<Rossen_> ack florian
<dael> fantasai: We have accent-color list of color but use of colors is not clear. Expalins primary, terciary accent colors. If you pick a bunch of colors of the rainbow you have no idea how they're used. In general noticed platforms have 1 color so multiple maybe not needed. Do have problem about whereever color is we don't know how used with respect to bg color.
<dael> fantasai: We allow UA to adjust lumenence.
<dael> fantasai: My prop is define accent color to be a list of alternative. You expect to pick a bunch of colors and UA picks the one with correct amount of contrast. Rather then make it be about different usage but about which has right contrast
<fantasai> https://github.com/w3c/csswg-drafts/issues/5480#issuecomment-682242811
<dael> fantasai: I think overall my take that TabAtkins comment ^ is the key piece of the design
<dael> fantasai: [reads it]
<dael> fantasai: The idea is the UA should be able to do what it feels is appropriate and we shouldn't pin down on how to use the color but should make sure there's enough contrast.
<dael> fantasai: I think going in direction of allowing UA to use color in what pieces it wants and make multi color be about right contrast helps us get there
<dael> masonfreed: I didn't see that other issue, I appologize. Sounds like option B-lite. Less interop than option B. For purpose of today is that a vote for option B and we go on and define option B more concretely if that's as the way group wants to go?
<dael> fantasai: Maybe? I think so?
<jensimmons> q+
<dael> Rossen_: Are we ready to vote out option A? Does anyone want to keep A?
<dael> Rossen_: Sounds to me like varients of B but if that's what group favors lets move on with additional details to break down B into more details.
<dael> masonfreed: I should say Chromium favors A. However we really want this so we would accept B.
<dael> fantasai: Looking more I htink my proposal is areally a different thing. Both A and B define accent-color. As to how much detail that's a different thing
<dael> masonfreed: Level of detail is the question for today.
<Rossen_> q?
<dael> fantasai: I would go with B more details. A lot of specific cases in A should be examples. Here's an example of how you could. That makes spec clear on intent without providing restricting guidance
<fantasai> s/more details/for details/
<dael> Rossen_: We have 2 more minutes on this. If we can't resolve we'll go back to GH
<dael> jensimmons: I can't shake feeling that it seems like 2 things being debated. One is should we include a lot of non-normative text and an attempt to have a lot of info in spec. That's A vs B.
<dael> jensimmons: Title of the issue and some comments feel more like if you agree we're putting in non-normative tex tyou also agree current text is what we end up with. Then we get stuck.
<fantasai> I don't have any objection to adding informative sections *with examples*. But Proposal A is written as specific guidance, which I don't agree with.
<Rossen_> q?
<fantasai> s/with examples/as examples/
<dael> jensimmons: What TabAtkins desc is threading the needle so it's not overly descriptive but not useless and underspec. If we're trying to call now to include text or not if we can unwind from demand about incredibly descriptive...we're getting stuck because being conflaited.
<dael> masonfreed: Let's go back tot he issue. Post says they're open for discussion and further details but first question is large direction of A or B.
<astearns> this could be part of the OpenUI joint meeting in a few weeks
<dael> Rossen_: sgtm. Don't want to resolve on A or B, just on thread.
<dael> Rossen_: Thank you masonfreed

FWIW, I think fantasai's suggestion is a step in the right direction. Instead of ordering the colors and mandating a "first" and "second" color, just allowing multiple colors and then have the user agent use these colors as "snap points" for the colors they would use otherwise seems pretty nice as a starting point.

This is less powerful than A because you cannot force a user agent to use a reverse contrast than usual, but also authors probably shouldn't try that because it's likely to cause issues.

If we go that road, then I'm in favor or reworking the specific per-control recommendation a bit to match this, and use the resulting examples to encourage the implementations to match if possible.

A vs B is not the important part of this; it's a vague question about the style of specification, and has little to no actual importance to the feature. The important question that keeps getting brought up and (unknowingly) skipped around is what the colors mean.

As I said earlier, if the property does not define what the colors mean, it's worthless. It's not a feature that people can actually use; it's entirely browser-specific. In particular, if accent-color: blue white leads to Chrome's implementation (white bg when unchecked, blue bg when checked) in Chrome and a more "traditional" coloring (white bg all the time) in other browsers, the property is worthless and cannot be used by authors.

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.

The colors must be specified with (necessarily vague) functional roles - at bare minimum, "foreground" vs "background". This means that Chrome's implementation of checkboxes is, effectively:

input[type=checkbox] { accent-color: blue white; }
input[type=checkbox]:checked { accent-color: white blue; }
/* assuming a "fg bg" ordering */

(fantasai's proposal in #5544 is thus a no-go as well; i don't think it's possible for such a semantic/contrasting definition to result in Chrome's "white, then blue" behavior.)

CSS already has the color property for indicating a foreground color and the background-color property for indicating a background color. accent-color is different from foreground/background. I think it's important to look at how operating systems are already using the term "accent color" (links in my comment above) rather than redefining it as foreground or background.

On the call, @fantasai 's proposal from #5544 (which I'll call option C) has been described as even less prescriptive and less interoperable than B, but I would disagree with that characterization.

B tells you that the first color in the list is the primary accent, the second one is the contrasting accent, and so on, but it doesn't tell you what that means, nor how to deal with controls being differently structured from one browsers to another (giving you these details would be A). Still, it tells you that the first color goes to the primary accent, and is inflexible about that. What part of the control gets a primary accent may change per platform / control / etc, but it does not depend on the specific colors provided.

C isn't less prescriptive, it's differently prescriptive. Which ever part(s) of the control is colored on that platformwill be accented, picking from the list of colors provided, but the UA is not bound to use the first in the list for the primary accent. Instead, it is required to use the color from the list which has the best contrast with whatever it is it will be contrasting against. This should make it more interoperable: to the extent controls are structured the same, the same color will end up being picked, and when they're not, you're at least guaranteed good contrast.

Noticing @tabatkins 's https://github.com/w3c/csswg-drafts/issues/5480#issuecomment-701498538 comment just before I post: that's a bummer. I wonder if there's a middle way. Could it indeed be expressed as a combination of accent and background, as https://github.com/w3c/csswg-drafts/issues/5480#issuecomment-701500321 suggests? That feels doable for the UA stylesheet, which can assume what the structure of the control would be, but I'm less sure authors could reliably do that without that knowledge.

Yes, I agree with you Tab, fantasai's proposal cannot guarantee interop with visual. I think this is fundamentally an A vs B question here. And, yes, fantasai's proposal does not enforce A, it just provides an set of colors UAs can use but they can still chose to render the controls differently under that proposal.

If the proposal is to standardize the appearance precisely too, then we need A and I'm not sure there is a lot of enthusiasm for that.

To (re-)clarify the issue up for discussion here:

A. Should the spec for `accent-color` be specific about how it should be used, per control, to ensure better interoperability?

B. Or should the `accent-color` spec be left mostly up to UAs to decide how/where/whether the specified accent-color value(s) should be used on each control.

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.

Side note about issue 5544. As I read it, that proposal is very definitely a variant of B above, because it explicitly states this:

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

I'd love to discuss that proposal further, but let's first decide that B is the right way to go here.

To be very clear, I favor option A. We think developers generally benefit from having unified expectations about behavior across browsers and platforms. Specifying accent-color in a way that results in different behavior across browsers will result in more developer frustration, more broken sites, and fewer developers able to reasonably use this feature. Indeed, interoperability was a top pain point in the 2019 MDN Developer Needs Assessment. Having said that, I also think accent-color, in either of the A or B forms, is a useful feature. So if the group can't come to consensus around A, I'm ok going with B.

I continue to disagree that #5544 is a variant of B. It does define which color gets used, it just does not do it based on the position in the list, but based on picking the highest contrast. But that's different from not specifying.

Arguably, this means that #5544 is a variant of A: two browsers with similarly structured controls, when provided with the same list of colors, would pick the same color for the same part. That's based on resolving contrasts, not on defining what's primary and what's contrasting, but it results in interop, unlike B.

I continue to disagree that #5544 is a variant of B. It does define which color gets used, it just does not do it based on the position in the list, but based on picking the highest contrast. ~ @frivoal

B is deterministic if browsers implement the controls the same way. But currently browsers do not. So it's possible to get "inverted" color controls in two browsers if they currently already have opposing rendering styles for their controls.

This is what the "A" bit is about in my understanding, specifying exactly the shape of the controls have, and where the colors go, so that browsers have matching implementations of the controls.

Agreeing on the rule without the templates is considered to be a "B" proposal by @mfreed7 (even though I agree the B proposal in this spec is too undefined to possibly lead to interop, while fantasai's proposal would eventually allow it, which is why I like it better).

Looking at just the titles of "A" and "B", and not worrying about implementation yet, I vote "B".

Interoperability will require either rebuilding a component from scratch, or standardizing the varying layouts, shapes, corner radii, shadows, glyphs, and gradients that different browsers' form elements use – which isn't a job for CSS alone.

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.

So your (A) is bad, but (B) is also bad. Neither result gives us a spec that can actually be implemented and produce a feature that's useful cross-browser. Let's discuss how to achieve that goal, rather than trying to wordsmith or reach a false consensus.

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.

I think we have a slight disagreement here. I don't think authors should expect something more of this property than "take the platform ui and change its blue color tint to another tint" and not "make it look a specific way" because if this is the latter they want they can already do that by changing the background/other properties of the various pseudo elements.

I strongly believe that unformizing when the accent color is used as background or not is not a reasonable goal. Chrome for instance switches this when a checkbox is checked. That's not the natural situation in most platforms. While I respect that choice, I don't see how it would be reasonable to enforce that choice to all platforms.

Based on this, it would seem we don't have an agreement on what this property would do at all at the moment, since we are chasing different goals it would seem.

Please look back at my previous comments, particularly https://github.com/w3c/csswg-drafts/issues/5480#issuecomment-701498538, where I talk about Chrome's checkbox implementation and how it would interact with this. I definitely do not intend for everyone to be forced to regularize toward or away from Chrome's UI.

Ah, and Elika explained her #5544 suggestion better to me. Her idea is that the UA already knows what colors its going to be working with (generally, starting with the 'color' and 'background-color' values) and then adds in some "accent colors" of its own, which become controllable via this property. (For Chrome's UA stylesheet, accent-color: blue, basically.)

In any given instance of the UI, the UA knows how it's going to be displaying the colors against each other, and thus knows what colors need to contrast against each other. It can thus determine whether the provided accent color is adequate in the given situation or not, and if not, can switch to a "fallback" accent-color (from fantasai's suggestion), or if nothing works, can tweak or ignore the given accent color to work, as a last resort.

So in Chrome's case, an unchecked checkbox would just use the 'background-color' (and perhaps 'color' for the border?), while a checked checkbox would use the 'accent-color' for the bg and the 'background-color' for the check. If it determines that those two colors, as provided by the author, don't contrast sufficiently, it can fallback to a second 'accent-color' specified, or adjust the specified accent-color lighter/darker, or ignore it and use the default, as desired by the UA.

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

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

And then the section for <input type=checkbox> says:

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.

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 date1 or this date2 . That seems very explicitly in the B camp.

As far as defining a specification, option "A" takes into account what browsers are doing today and have done in the past, but we can't really account for what they will do in the future. After all, who expected Chrome to one day reverse its colors?

Another issue with this specification is that it very specifically uses the text "browsers" at the moment, and this seems to me to remove some of the power of CSS across platforms. Consider, if you will, that this specification could be used on a device with a limited color output. During device setup, the device asks a user to pick an accent color. That color is used where the device deems appropriate to maintain usability. Consider perhaps a device that meets a functional need with a 4 or 16 color display and a long shelf life. The device has the ability to interpret form elements, but no ability to set a background color -- perhaps a clear display. In the case of a checkbox, the one accent color chosen could end up being either the color of the checkbox or the color of the checkmark, but not both, so we wouldn't be able to force a foreground and background for it, or even a "primary" and "secondary" for it -- just a primary.

If we want to restrict this specification to browsers, we can, but I think that would be missing out on an opportunity. If we were to think of the specification more generically while still allowing it to give the guidance needed to provide power to authors, then we almost certainly can't use "A".

Using "B" may take away the focus on interoperability, but UAs aren't made to be completely interoperable for display anyway when using default controls. The goal of this specification seems to be to add flavor to default controls, not ensure consistency in display. And it says nothing of what to do with those form controls when I go to print the webpage. Maybe the accent color isn't something that should ever appear on paper for legibility (like a bright yellow), but makes complete sense on a monitor.

This is where "C", @fantasai 's proposal could also come in handy -- rather than specify a color and say "Do this" (A) or a color and say "Do what you will" (B), it says "This is what we'd like." (C) and allows the hinting to take place so that the UA can render for media as appropriate.

The idea at heart here I think is that we can already beat UAs into submission by specifying foreground and background colors, but then we lose styling such as gradients and shadows and shapes. An "accent color" lets the UA do what it needs to do to preserve the user experience, but gives authors control over "theme hinting" or "style hinting" rather than styling.

And that's the problem, isn't it? This is potentially an extremely powerful property:value pair that can change the entire feel of a page that has several form elements on it, and at some point it will probably get extended to more than form elements. If we allow the browser to take "C" as a hint, and then want other elements on our pages to use the color decisions that the browser has made so that the page will not clash with the form, then we'll have to add a "color: accent-color;" at some point so that the browser knows to use whatever it applied to the forms to other things on the page.

Another issue is that we are only able to limit our thinking to form elements as they exist today, but who knows which additional form elements may get added in the future?

"A" is too limiting in how explicit it is. "B" isn't harnessing the power that this specification can truly give. "C" is very powerful, but the amount of additional scope that it could introduce is possibly staggering. I think it would need a bit of refinement to be truly useful, including a "should" here and there.

I think we should take "C" and run with it, change the wording to be more all-encompassing to explore UAs besides browsers, and express this spec as the intention of an author to add a hint to the existing UI rather than to take complete control of it.

"Interoperability" in this case could mean that: 1) At least an accent color SHOULD be applied if at all possible. 2) The vendors make a pledge that the form elements will continue to be visually usable despite specification of an accent color. 3) Elements will continue to act as they already do, so if you check a box and it reverses the colors, authors continue to see this behavior. 4) Accent colors will not affect existing "flavor styling" of a form control -- if a control has rounded corners, a slight shadow in one corner, and a gradient background, that form control will retain all of those things, with the accent color applied in such a way that the vendor sees fit to preserve their existing user experience.

"Interoperability" in this case should NOT mean that: 1) The form control looks the same on every device. 2) The accent color from the author is applied in such a way that it breaks the display of the form (no white-on-white or black-on-black). 3) Vendors disregard the user experience and author's intention in using accent-color in favor of their own styling. You know who you are. Your users know who you are and are already using your product.

I'm not sure if I understand the difference between B and C. Aren't they both allowing the user agent to decide where to apply the color(s) – in contrast to A, where the author mandates which part of the element should have the color(s)?

I'm not sure if I understand the difference between B and C. Aren't they both allowing the user agent to decide where to apply the color(s) – in contrast to A, where the author mandates which part of the element should have the color(s)?

Yeah, I don't know why C keeps coming back up here. This issue is binary - A or B. Should the spec guide where to put each color (A), or not (B)? I must be missing something, but I don't know what it is. I think I need to take a break from this issue.

I believe the spec should not guide where to put each color.

(B) specifies the color and says "use this". (C) specifies the color and says "use this, or something close to this, but make sure you don't encroach on usability". That is why I like (C) better.

Neither (B) or (C) says where or how to use the color. If that needs to be defined down the road somewhere, it can be done with something like an accent-color-color (accent-color: blue;) and accent-color-intent (accent-color-intent: primary foreground;). For now just getting the proposal moving forward seems to be more important to vendors, and I believe moving forward with the less-prescribed route is the way to do that.

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:

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.

@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. 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"!).

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.

Okay, that's not what the current proposal says. ^_^ Fixing that would help, since you've continually been referring to the current proposal.

I suspect others on this thread will vote for option B.

I would not take that as an assumption. There's been a lot of confusion around this issue, and nobody wants a specification that will end up being worthless to authors due to giving totally different results across browsers.

What you're instead seeing is (a) some degree of reluctance to commit to the current spec as the proposal (which is what you've explicitly said "Option A" is during the call!), and (b) some degree of reluctance to define form styling at all, and flailing for "Option B" as a "well, I guess Chrome can do whatever, we'll continue to do nothing so it doesn't matter" fatalist choice.

Going back thru the minutes, see for example:

masonfreed: Looking for a direction, interop vs hint. Interop is full proposal as presented. B is a striped down version with no normative text or guidance on how to do accent-color. A or B with a link in the thread.

This is where you've been saying "Option A" is "what's currently in the proposal", not the more generic thrust you're talking about now. If you don't remember tying "Option A" so explicitly to the exact current text, that's part of the confusion. ^_^

Okay, that's not what the current proposal says. ^_^ Fixing that would help, since you've continually been referring to the current proposal.

Thanks. Help would be appreciated in "fixing" this issue, as I've tried numerous times and apparently failed 100% of the time. I wish I could just delete all of the comments here, and refer back to the original issue comment. Do you think, if I added "A" and "B" labels there, that comment still explains the question we're trying to resolve?

I suspect others on this thread will vote for option B.

I would not take that as an assumption. There's been a lot of confusion around this issue, and nobody wants a specification that will end up being worthless to authors due to giving totally different results across browsers.

Reading back through comments on this thread, I think these are the only clearly stated positions, to date:

@mfreed7 supports option A
@tabatkins supports option A
@samuelbradshaw supports option B.
@x-Jake-x supports option B.

masonfreed: Looking for a direction, interop vs hint. Interop is full proposal as presented. B is a striped down version with no normative text or guidance on how to do accent-color. A or B with a link in the thread.

This is where you've been saying "Option A" is "what's currently in the proposal", not the more generic thrust you're talking about now. If you don't remember tying "Option A" so explicitly to the exact current text, that's part of the confusion. ^_^

I agree to saying exactly that. But I intended that as a shorthand for: "when trying to understand what Option A is, see the current proposal, which is one example of Option A. It tries to explain how to use each color on each control. There are, of course, many other ways to implement Option A. But let's debate that later, after we decide that Option A is the right way to go." I can see how people might have mis-interpreted that shorthand, and I should have been more clear.

"But let's debate that later, after we decide that Option A is the right way to go."

The problem you're running into on the call is that people are reluctant to say "Yes, let's go with something like this", because they're afraid that doing so will be seen as "yes, Chrome is okay to ship what the spec currently says". The details of the proposal matter; this is why we haven't succeeded at doing this precise thing for 20+ years.

But again, "here's some colors, do something with them" is not actually an option on the table. That's not a spec, and I will formally object to attempting that; it's giving up on there being a spec, and I'd rather be more honest and continue not having a spec instead.

The only actual options are:

Come up with a reasonably detailed, but not too detailed, specification for how UAs must use the colors, if they're using them at all. This must be defined such that an author can use the property to style elements on the page, and have a reasonable guarantee of them looking okay in all browsers regardless of any browser's particular styling conventions.
Continue to leave form styling an unsolved problem.

Continue iterating on the spec and reaching consensus on the details; trying to push for an even more explicit "yes" on (1) feels like attempting to lock down a solution before there's consensus.

Thanks. Help would be appreciated in "fixing" this issue, as I've tried numerous times and apparently failed 100% of the time.

Yeah, let's do that in another issue.

What I'm hoping for is something like "Take what you currently accent as blue, and accent it as a variation of this color or color(s) instead." I think that would be "B," in the more specific form of "C."

As a developer, I would apply that CSS rule to the body, and hope for it to cascade to form elements, text selection, focus outlines, etc. that would normally be blue in the given browser, except in the case where something it might cascade to is overridden by a more specific rule.

So in Chrome's case, an unchecked checkbox would just use the 'background-color' (and perhaps 'color' for the border?), while a checked checkbox would use the 'accent-color' for the bg and the 'background-color' for the check. If it determines that those two colors, as provided by the author, don't contrast sufficiently, it can fallback to a second 'accent-color' specified, or adjust the specified accent-color lighter/darker, or ignore it and use the default, as desired by the UA.

I would not expect color to affect anything but text, and not necessarily text that was several layers deep, like the text in a button in a file upload control. And it would affect borders that were set to currentColor, which wouldn't necessarily be the same across UAs (they wouldn't have been in Aqua). And I wouldn't expect all UAs to use a text glyph for the checkmark or other icons. An image (SVG? Or even a PNG) would be reasonable and also not necessarily currentColor.

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 do not agree with this.

Suppose I am an implementor 10 years in the future, when skeuomorphism is popular again, and computer screens are typically the size of the top half of a large office wall (they stick to the wall like contact paper, and only cost 25¢ per square foot). So I design a "switch" control to be an actual photo of a late 20th Century light switch and switch plate, with a bit of a perspective angle. The overall shape is a vignette, so some yellow wallpaper with brown stripes shows around the outside of the switch plate.

When the switch is in the up "on" position there is a blue non-rectangular shape over the actual switch part, with a screen ink effect, like there is a blue light emanating from it. A similar screened color effect picks up a bit of blue along two edges of the switch plate. When it's in the "off" position, the color is grayish red, while the wallpaper and switch plate are darker, like it's nighttime.

I cannot change that blue to the accent color when one is provided, because it's not actually a background? I can only use it to, what? Put the accent color behind the photo? Even when the switch is off?

But again, "here's some colors, do something with them" is not actually an option on the table. That's not a spec, and I will formally object to attempting that; it's giving up on there being a spec, and I'd rather be more honest and continue not having a spec instead.

I understand you'll formally object, but I do actually think this is an option on the table. It's "option B". And there are several people (many developers, surprisingly to me) that appear to be advocating for option B. I'm less pessimistic that we could define an "option B" in a way that is close enough to a "spec" that there is some level of usefulness to the feature.

Continue iterating on the spec and reaching consensus on the details; trying to push for an even more explicit "yes" on (1) feels like attempting to lock down a solution before there's consensus.

The reason I created this issue, and continue to want to reach an A or B conclusion first, is that the shape of the solution to A is vastly different from B. Without this decision first, we'll never reach consensus on a specific spec text, because we'll still be implicitly debating the basic A vs. B question.

@bradkemper I'm going to mark your response as a definite vote for Option B. One point though:

Suppose I am an implementor 10 years in the future, when skeuomorphism is popular again, and computer screens are typically the size of the top half of a large office wall (they stick to the wall like contact paper, and only cost 25¢ per square foot). So I design a "switch" control to be an actual photo of a late 20th Century light switch and switch plate, with a bit of a perspective angle. The overall shape is a vignette, so some yellow wallpaper with brown stripes shows around the outside of the switch plate.

In an "option A" world, the intent would be to get current controls to all behave the same. If you read my proposal (again, to over-extra-super-emphasize, this is merely one potential example of an option A solution), it is pretty clear to spell out that if a control you're working on looks like one of the ones listed in the non-normative section, then you should follow the behavior listed. In your example, clearly your new control looks nothing like the ones in the list, and you should do what makes sense. There's a whole section emphasizing that innovation should not be limited by the spec. Perhaps when you finish your new control in the future, you should also file an accent-color spec PR to define your new way of thinking about switches, and include it in the non-normative section. And then other implementations that copy yours will want to follow your lead so there's still interop.

Current (still changeable, of course) state of positions:

@mfreed7 supports option A
@tabatkins supports option A
@samuelbradshaw supports option B.
@x-Jake-x supports option B.
@bradkemper supports option B.

Others who have participated in these calls, what do you think? A or B? @frivoal @uma @fantasai @AmeliaBR @jensimmons @emilio @litherum @gregwhitworth

Again, A means any proposal that tries to be as specific as possible about how the colors get used (e.g. try to put the same color in roughly the same place across browsers), and B means any more general proposal that doesn't try to lock down how/where the colors are used. The canonical example is the checkbox: proposal A says that if the background of the checkbox is controllable by accent-color, it should be controllable in the same way (e.g. with the same value for accent-color) across browsers. Proposal B says that an accent-color value might be used for the background of the checkbox in one browser, and instead for the check-mark in another browser. The details of how the actual A or B spec is written do not matter for this question. Those will be still be very much open for debate, later.

Thanks for the ping @mfreed7

As it relates to this issue I'm in favor of Option A

I discussed this issue at length with @brandonferrua on our SLDS team and ultimately we will not utilize this property until a time that we can have a guaranteed utilization across UAs. So ultimately I'm in favor of what @tabatkins is trying to get across and what I was trying to allude to in this comment on the original issue.

Since A is primarily trying to gently prod to keep with the spirit of the property I prefer it and I think that it will serve the needs of some developers but technically both A & B are a type of hint since they are non-normative definitions.

Is there any chance that we can do both A and B without breaking the implementation bank?

Value: <color>+ could be Value: [hint] <color>+

where we expect the UA to render the colors specified consistently as expected (how to define the various parts of a control and colors for those {foreground/background/primary/whatever} can be discussed later),

UNLESS

the hint keyword is specified first, in which case we give the UA a wider range of decision about how to apply the accent-color(s) within its own styling.

This way, we can have both consistency where we need it for mission-critical applications (think the professional version of your web application distributed to clients), or simply a hint of an accent where we don't feel like using default accents (to avoid explicitly testing and styling colors to achieve a proper contrast).

As @gregwhitworth mentioned, and in light of the discussions going on, we (salesforce) see option B as useless. If I cannot use accent-color and get predictable results across UAs than I'd have a difficult time advocating for use of this property.

It seems to me that accent-color is trying to solve too many problems in one go. I don't know if there would be a need for accent-color if I had access to more of the form controls internals, similar to what :part or ::pseudo-elements would offer me. I understand that isn't the immediate issue being addressed but I can't help to not think of that as another part of the problem.

Thanks for bringing that up, @brandonferrua. I agree that CSS access to form control internals is needed, which would allow us to style specific parts of the form controls with the existing background-color or color properties. I see accent-color as an opportunity to fill a different need – which is to lightly dust the existing controls with color in a way that feels "native" to the browser being used.

@bradkemper You're already describing something extremely far away from current implementations; I think it's quite unlikely such a switch would look remotely good on a broad swathe of webpages. I don't think that's a reasonable hypothetical to work within. Note that similarly skeumorphic elements on existing iOS devices, like the date picker, are not inline in the page, but rather modal popups, in part because they would not look good on a broad swathe of pages.

If such a future would ever come about, it would be accompanied by some automatic ML-driven re-styling to blend into the color and design of the page, at which point how it treats accent-color is completely out of our hands.

I agree that CSS access to form control internals is needed, which would allow us to style specific parts of the form controls with the existing background-color or color properties.

I think this is a good point. We are trying to define a property called accent-color that specifically is being related to colors of form controls and nothing else at the moment. These aren't really "accent colors" if we are explicitly defining them, these are form control colors. I don't look at the paint on the side of a house and think "that's a nice accent color" -- I think "that's a nice color".

This property is semantically being used incorrectly. It's one thing to use accent-color to define an accent color which can also apply to form controls as an accent color, but it's quite another to simply decide that this is what CSS is going to call its form control color styling property.

I think the specification of accent-color as a multi-colored property, in which how the various colors get used is either A) dictated precisely by spec, such that authors can expect to theme specific parts of a control to specific different colors or B) utterly undefined, such that a style sheet written for browser is potentially unusable on another is harmful to the cross-platform and future-compatible nature of the Web Platform.

I also think your fixation with resolving this issue as either A or B and preventing any discussion of alternatives or nuances is the reason this conversation is deadlocked.

I don't think it's appropriate for accent-color to be a "switch into Chrome's styling model" switch. It should be a color hint to the browser, that influences the way it draws its own controls.

If we want a "switch into Chrome's styling model and give me explicit control over the colors of every part" switch, we can also do that, but I don't think accent-color should by itself be that switch.

If we want a "switch into Chrome's styling model and give me explicit control over the colors of every part" switch, we can also do that, but I don't think accent-color should by itself be that switch.

I don't think this is the exact way I'd frame it but I agree with your point. Ultimately, if we don't get into normative definitions of parts and relations to these then accent-color can only be hint even if there are recommendations to its spirit.

In the meeting on Monday we hope to go over the spectrum and I have a very rough strawman proposal that may be this switch but I don't want to hijack this thread.

we will not utilize this property until a time that we can have a guaranteed utilization across UAs.

If we are trying to normalize how and where UAs apply color, then I would say that goes way beyond what I would expect from a property called accent-color. Sounds more like it should be called normalize-form-colors.

In my view, we should recognize that most/all UAs use a very limited color palette of colors that are not black or white (or shades/tints of the main colors), and that those are the colors we want to change for theming. To go beyond that to insist of where colors go in the native control seems like something else altogether. For that level of control, there should be part selectors. But for changing the main blue of a UA's control to a corporate red, that should be a simple thing that you should be able to do with accent-color (or accent-colors) without worrying that it will otherwise change the overall design of the native control.

w3c / csswg-drafts

[css-ui] Should interoperability be a goal for the `accent-color` spec? #5480

Option "A":

Option "B":

A. Should the spec for `accent-color` be specific about how it should be used, per control, to ensure better interoperability?

B. Or should the `accent-color` spec be left mostly up to UAs to decide how/where/whether the specified accent-color value(s) should be used on each control.

w3c / csswg-drafts

[css-ui] Should interoperability be a goal for the `accent-color` spec? #5480

Option "A":

Option "B":

A. Should the spec for accent-color be specific about how it should be used, per control, to ensure better interoperability?

B. Or should the accent-color spec be left mostly up to UAs to decide how/where/whether the specified accent-color value(s) should be used on each control.

A. Should the spec for `accent-color` be specific about how it should be used, per control, to ensure better interoperability?

B. Or should the `accent-color` spec be left mostly up to UAs to decide how/where/whether the specified accent-color value(s) should be used on each control.