Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-ui-4] Use of accent color outside of form control elements #5657

Open
samuelbradshaw opened this issue Oct 23, 2020 · 7 comments
Open

Comments

@samuelbradshaw
Copy link

samuelbradshaw commented Oct 23, 2020

Issue #5187 discusses an accent-color attribute that may be applied to form controls (checkboxes, select menus, etc.).

Should accent-color be limited to form control elements, as in the linked issue, or should it be applicable to anything that is "traditionally blue," like focus outline rings or text selection backgrounds?

If I applied an accent color at the top level (for example, the html or body element), what would it be allowed to cascade to?

@fantasai fantasai added the css-ui-4 Current Work label Oct 23, 2020
@fantasai
Copy link
Collaborator

I was thinking about scrollbars when I was drafting the proposed spec text in that issue, but you're right that there's other places where it could be relevant!

I'd be in favor of allowing any UA-provided colors to be influenceable by accent-color (the UA "may").

@fantasai
Copy link
Collaborator

Note: If we do this, we should recommend authors set accent-color on the root. Having per-element accent colors might be a bit tough for some of these effects, so some UAs might end up needing a single color to use, and picking off the root would be the most straightforward way to do that.

@frivoal
Copy link
Collaborator

frivoal commented Jan 21, 2021

I suggest we add something like this to the definition of accent-color:

This property may affect any user-interface controls drawn by the element, including scrollbars, resize handles, selection colors, outlines whose 'outline-line-style' is ''auto'', and any other effects on the element that key off of the [=accent color=].

Note: Selection colors being automagically controlled by the UA is already allowed in css-pseudo-4, this would just give influence over that magic.

@samuelbradshaw
Copy link
Author

samuelbradshaw commented Jan 21, 2021

I think it might also be good to mention in a potential spec that user agents are not expected (or alternatively "may, but are not required"?) to apply color to elements that are not normally colored in the user agent's default styling. For example, in Safari, scrollbars are usually gray. I wouldn't expect them to automatically adopt the page's accent color.

@fantasai
Copy link
Collaborator

@samuelbradshaw I think that's covered by the definition of "accent color". Gray isn't really an accent color in the UA palette, it's base color.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-ui-4] Use of accent color outside of form control elements, and agreed to the following:

  • RESOLVED: UAs may use an accent-color outside of form controls at their discretion
The full IRC log of that discussion <dael> Topic: [css-ui-4] Use of accent color outside of form control elements
<fantasai> s/minimum/minimum -- and anything else that might affect it in the future/
<dael> github: https://github.com//issues/5657
<dael> florian: Introduced accent-color to let you change it when there is one. Mostly talked about it as form controls. But there are other things that might be colored link scrollbars or the selection color or an outline color.
<dael> florian: Are these supposed to be influenced? I'd say yes but didn't discuss it explicitly
<dael> leaverou: I think they should and authors should be able to access this property if there isn't already
<dael> florian: You mean default?
<dael> leaverou: If you override can authors use in other properties?
<dael> florian: Author sets it
<dael> leaverou: If I set accent-color is there a keyword like currentColor?
<dael> florian: No
<dael> leaverou: Should be
<dael> florian: Can't you set a variable?
<dael> leaverou: Can but variable is a contract between values but accent-color is a global
<dael> chris: Seems you should do it like this, but it's not a single author that writes stylesheet
<dael> florian: Sounds like a separate issue. Can you file a new issue? It's interesting
<dael> leaverou: Yes
<dael> florian: So are we going to apply this to scrollbars, outlines, all things that could be colored.
<dael> fantasai: I think UA should be allowed to do so. We need to be clear about definition as to what an accent-color is. Scrollbars mostly don't have accent-colors. accent color is the color that stands out. Inthat light I think it makes sense to allow UA to use it any place where it derives a color, but I think it should be a may so UA can decide if it's able
<dael> chris: This is behind the scenes magic?
<jensimmons> q+
<dael> florian: Yeah b/c we don't know how UA builds these in the first place. To extent they use one.
<astearns> ack jensimmons
<dael> jensimmons: Thinking about setting universal accent for my whole site as an author it feels like not knowing all details of where it shows in form control makes sense to me. Having whole scrollbar that color is too much
<dael> florian: Wouldn't be, though
<dael> jensimmons: If scrollbar still have arrow it could color that
<dael> florian: Not adding colors where they aren't. But if UA is using a blue accent you ask to switch to purple
<dael> fantasai: I think we should give an example in spec as to what effect it would have
<fantasai> s/would have/would have to set it on the root and letting it inherit through/
<dael> florian: Example is in macOS you can change accent color of whole system. You highlight color for selection changes. And other places
<dael> leaverou: Is UA allowed to use varations of it? Can UA make it lighter or darker?
<dael> florian: It's speced that yes.
<dael> leaverou: Okay
<fantasai> https://drafts.csswg.org/css-ui-4/#widget-accent
<dael> florian: Main cases is to maintain contrast or b/c if you think of aqua mac OS with gradients you don't want to substitute a gradient with a flat color.
<fantasai> "The UA should use the specified accent-color to draw whichever parts of the element’s control(s) would have otherwise been styled with an accent color. The UA must maintain contrast for legibility of the control, and in order to do so may adjust the luminance or brightness of the color or make color substitutions in other parts of the control (e.g. switching an overlaid glyph from using color to using
<fantasai> background-color). It may also generate variations of the color for gradients etc. to match the control to platform conventions for the use of the accent color."
<dael> astearns: Hearing yest we should allow UAs to use accent color outside of form controls. Leave to UA if it's appropriate
<dael> smfr: Confused about how relates to system colors. Do we want to prevent this from leaking?
<dael> TabAtkins: accent-color isn't user privacy
<dael> smfr: Author spec, right.
<dael> jensimmons: Makes a lot of sense to work outside of form controls. Want it to be up to browser or vendor of how it works. Should have clear language around that this is for accents, not just coloring all the bits. These are things that are true accent colors. Would allow authors to set univerally and not have unintended consiquences.
<dael> fantasai: Spec does have wording. If you want to suggest improvements give it a look
<dael> astearns: Risk of unintended consiquences if user has accent-color and likes what Safari does but doesn't check Chrome. But b/c nature of feature this is just a hint which the browser can do what they want. That possible mis-match comes with territory
<dael> florian: Examples from leaverou and jensimmons are reasonable. They're intended to be covered in spec text. Pelease give a look and feedback
<jensimmons> cool, yes, fantasai & florian on taking a look at what you've already done on this. Thank you.
<dael> astearns: Prop: UAs may use an accent-color outside of form controls at their discression
<dael> RESOLVED: UAs may use an accent-color outside of form controls at their discretion

@fantasai
Copy link
Collaborator

Note: We also wanted to add an example setting :root { accent-color: purple; } or whatever.

pull bot pushed a commit to FreddyZeng/chromium that referenced this issue Mar 13, 2021
The accent-color CSS property lets the page specify a color to be used
in form controls instead of the builtin colors.

This patch does not change focus ring colors or text selection colors as
mentioned in this issue:
w3c/csswg-drafts#5657

Spec: https://drafts.csswg.org/css-ui-4/#widget-accent
I2P: https://groups.google.com/a/chromium.org/g/blink-dev/c/q9zf-frdewo

I plan to have the particular usage of colors and contrasting reviewed
by UX and accessibility before launching this feature.

Bug: 1092093
Change-Id: Ida4586a73219b5c3347cc1385b01d02714b02abe
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2681146
Commit-Queue: Joey Arhar <jarhar@chromium.org>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Reviewed-by: Mason Freed <masonfreed@chromium.org>
Cr-Commit-Position: refs/heads/master@{#862542}
mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this issue Oct 14, 2022
The accent-color CSS property lets the page specify a color to be used
in form controls instead of the builtin colors.

This patch does not change focus ring colors or text selection colors as
mentioned in this issue:
w3c/csswg-drafts#5657

Spec: https://drafts.csswg.org/css-ui-4/#widget-accent
I2P: https://groups.google.com/a/chromium.org/g/blink-dev/c/q9zf-frdewo

I plan to have the particular usage of colors and contrasting reviewed
by UX and accessibility before launching this feature.

Bug: 1092093
Change-Id: Ida4586a73219b5c3347cc1385b01d02714b02abe
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2681146
Commit-Queue: Joey Arhar <jarhar@chromium.org>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Reviewed-by: Mason Freed <masonfreed@chromium.org>
Cr-Commit-Position: refs/heads/master@{#862542}
GitOrigin-RevId: 8c9f1381dfb11c18406d5bea790ec4e8a59ab2e7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants