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

[mfreed7]

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?

[mfreed7]

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.

[tabatkins]

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.

[frivoal]

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.

[mfreed7]

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

[frivoal]

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

[samuelbradshaw]

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.

[css-meeting-bot]

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

[astearns]

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?

or

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.

[mfreed7]

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.

[mfreed7]

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.