Csswg-drafts: [css-color-4] Support high-contrast/dark mode colors

[fantasai]

With Dark Mode and MSFT's “high contrast” mode (which is more accurately a “specific contrast” mode since it also represents low-contrast settings), we anticipate that authors will want the ability to re-use relevant system colors. Revisiting the CSS System Colors, @tabatkins and I have come up with the following list of colors (based on the available MSFT high-contrast settings) which we propose to add*/undeprecate for these purposes:

• Canvas* (we'd have liked to call this “Background” but that's already used for something else)
• Text*
• LinkText*
• VisitedText*
• Highlight
• HighlightText
• GrayText (could be aliased to InactiveText or DisabledText for clarity)
• ButtonFace (could be aliased to Button for consistency)
• ButtonText

Note: MSFT doesn't distinguish visited vs. unvisited links, but as some systems may we included keywords for both variants: they can be mapped to the same color as needed.

[smfr]

WebKit's user agent CSS file contains the following system color values:

background-color: -apple-system-control-background;
background-color: ButtonFace;
color: -webkit-activelink;
color: -webkit-link;
color: ActiveButtonText;
color: ButtonText;
color: GrayText;
color: text;

So of those, the ones not covered by your list above are:

background-color: -apple-system-control-background;
color: -webkit-activelink;
color: ActiveButtonText;

[fantasai]

We mainly wanted to hit the colors that are needed to handle forced-colors mode. (MSFT's contrast feature or similar), so our initial list was intentionally limited to the colors MSFT uses in that mode: those are the colors that authors need to be able to access. Extending system colors more generally is possible, but we felt it would be a separate issue so as not to complicate solving this particular problem asap. Not sure how the Apple colors fit into that idea? (What even is -apple-system-control-background)

[smfr]

-apple-system-control-background is what we use to render the background of some elements.

[AmeliaBR]

How are the proposed Canvas and Text colors different from the CSS2 Window and WindowText colors? Are these expected to be the same colors, but just with better names?

In general, I'd prefer not to introduce new keywords/aliases if there isn't a strong reason for them, since user agents are going to need to continue to support the old keywords anyway.

I agree that new named colors are required for the link and visited link colors. I think it makes sense to also include an active link color. It's fairly traditional to have a separate color for that (usually red) in the user agent stylesheet, even if it's not a big accessibility issue. I'd recommend calling them VisitedLinkText and ActiveLinkText to be unambiguous since there are other ActiveSomething keywords.

Similarly, Simon: do you know why -apple-system-control-background required its own keyword & couldn't use one of the predefined ones? Is it a case that Apple UI uses the same color for many different things, which might not be all drawn in the same color in a different UI? Meaning: is this logically more of a color variable rather than a color of a specific thing?

[smfr]

I couldn't see any system colors in https://www.w3.org/TR/css-color-3/#css2-system that are equivalent to an input's background color, hence -apple-system-control-background.

If we do bring back the system colors, can we give them nice hyphenated names ("active-link-text")?

[AmeliaBR]

I couldn't see any system colors … that are equivalent to an input's background color

That's a good point. Another missing value. All the three-d sides of a button, and nothing for a text input. WHCM re-uses the button colors for inputs, but that's not true for system themes in general.

[dbaron]

I couldn't see any system colors in https://www.w3.org/TR/css-color-3/#css2-system that are equivalent to an input's background color, hence -apple-system-control-background.

Early drafts of css3-ui had Field and FieldText for text fields (see my 2001 description of their importance or the original member-only post) and those are implemented in Gecko with prefixes.

[fantasai]

How are the proposed Canvas and Text colors different from the CSS2 Window and WindowText colors? Are these expected to be the same colors, but just with better names?

@AmeliaBR It's not very clear what they mean from the spec, but at least some implementations return Window which are not equivalent to the canvas background. So to prevent anything bad happening, we're introducing new keywords.

If we do bring back the system colors, can we give them nice hyphenated names ("active-link-text")?

Added to the List of Mistakes, because, yeah. That said, since all color names -- system colors, X11 colors, currentcolor -- are following the mashwordstogether pattern, I think we might want to just stick with it here. :/

I couldn't see any system colors in https://www.w3.org/TR/css-color-3/#css2-system that are equivalent to an input's background color, hence -apple-system-control-background.

Tab and I would be OK to add in Field and FieldText if y'all feel it's needed; we left them out of our original list mainly because MSFT's forced-colors implementation didn't seem to distinguish between those and Canvas/Text, and we were aiming at a minimal set to start. (We didn't want to pull in all of https://www.w3.org/TR/2000/WD-css3-userint-20000216#color and tackle the issue of system colors generally here, just get the minimum set needed to support forced-colors mode. If we were pulling anything out of that draft, though, Field/FieldText would've been it, to correspond with ButtonFace/ButtonText.)

[css-meeting-bot]

The CSS Working Group just discussed Support high-contrast/dark mode colors, and agreed to the following:

• RESOLVED: add the original list of colors from TabAtkins and fantasai as well as Field, FieldText and ActiveText

The full IRC log of that discussion

<dael> Topic: Support high-contrast/dark mode colors

<dael> github: https://github.com/w3c/csswg-drafts/issues/3804

<dael> TabAtkins: Working from the presentation of Rossen_ and melanierichards. fantasai and I put together prop for high contrast stuff in CSS. Defining system colors, some exist some new, that map to categories from Rossen_ and melanierichards

<dael> TabAtkins: Only addition is a visited link color in addition to normal and that's because it's already in system colors. MS could set to same color if they want.

<dael> TabAtkins: Idea being is we adapt MS rules for how to apply that says you apply these system colros whereever nec. THere's a MQ that says these are on and you may want to adjust your styles.

<dael> fantasai: Resolved on that earlier, need to add the colors. Resolved on the MQ and properties. This is about making changes to CSS color L4 to un-deprecate a subset of the system colors and add a couple of new ones

<dael> fantasai: New is page background, scrollbar, link text, visited link text

<dael> dbaron: Active link text?

<dael> fantasai: Might need to add that, yes

<TabAtkins> Canvas* (we'd have liked to call this “Background” but that's already used for something else)

<TabAtkins> Text

<TabAtkins> LinkText

<TabAtkins> VisitedText*

<TabAtkins> Highlight

<TabAtkins> HighlightText

<TabAtkins> GrayText (could be aliased to InactiveText or DisabledText for clarity)

<TabAtkins> ButtonFace (could be aliased to Button for consistency)

<TabAtkins> ButtonText

<dael> AmeliaBR: Couple other suggestions in thread of colors used in UA stylesheets. Some of which not named

<dael> fantasai: Discussion about adding field values for text inputs. I don't have a strong opinion on that. Wanted to make sure got minimum set MS was using in high contrast mode. If WG wants to add field and field text can add

<TabAtkins> Looks like additional stuff is just "Field" and "FieldText"

<dael> Rossen_: High contrast PoV your set of colors maps to what's required. I don't have strong pref for additional ones, I don't know use cases. I guess people creating own components and want closer to current system controls sounds reasonable.

<AmeliaBR> and ActiveLinkText

<dael> Rossen_: Want to hear from rest of group

<fantasai> or ActiveText

<dael> Rossen_: Taking silence as supportive

<dael> Rossen_: Prop: un-deprecate or add the list above

<dael> fantasai: * is added

<dael> AmeliaBR: IRC discussion mentions the others

<dael> fantasai: ActiveLinkText and Input field background and foreground color

<dael> fantasai: We pulled old names for those, don't know if they're nec. I think we at least need to minimum set for MS high contrast. If people want to add others I"m fine

<tantek> aside: see more Link related colors here: https://www.w3.org/TR/2002/WD-css3-color-20020418/#css3-user

<dael> Rossen_: Objections to add the original list of colors from TabAtkins and fantasai as well as ones by smfr and ActiveLinkText

<dael> RESOLVED: add the original list of colors from TabAtkins and fantasai as well as ones by smfr and ActiveLinkText

<dael> fantasai: On activeLinkText we have LinkText and VisitedText. We went shorter version of names b/c match selector

<dael> Rossen_: Shorter makes sense

<tantek> aside: (cont'd) which were dropped (not just deprecated) from the REC: https://www.w3.org/TR/css-color-3/#css2-system

<dael> AmeliaBR: There's already ActiveButtonText so that' sonly confusion

<dael> AmeliaBR: If it needs to be clear ActiveText is color for active links

<dael> fantasai: Active button can be own thing

<dael> Rossen_: Okay. Previous resolution stands

<dael> Rossen_: Resolution is ActiveText not ActiveLinkText

[tabatkins]

Closing since the merge in https://github.com/w3c/csswg-drafts/commit/8bb901999787c4e5a6b2af2a0d5049d995b8dc50 addressed this issue.

[snuggs]

@tabatkins @fantasai happen to know why Text was declared in list above but not in https://www.w3.org/TR/css-color-4/#css-system-colors
?

Thanks in advance!