[css-color-adjust-1][mediaqueries-5] Clearly define what 'light' and 'dark' mean

[AmeliaBR]

A common theme came up in discussions of #3853 (about sepia), #3849 (about normal not always being the same as light) and #3859 (about an any option for the color-scheme property): light and dark themes don't always have to be the same from browser to browser. But a web page author needs confidence that if they say they support the theme, it won't result in a broken site.

To me, the most important way something can be “broken” by colors is if it fails contrast minimums.

I therefore propose that we include explicit requirements for browser's built-in light & dark schemes, based on the WCAG contrast formula. For example, for light mode we could say:

• The default canvas color (and new canvas system color) must meet AAA contrast for all text sizes when compared against #333 text.

• The default text color (text color keyword) must meet AAA contrast for all text sizes when compared against #ccc background color.

A dark scheme would have the requirements reversed.

That way, an author could use the built-in light theme canvas color and set their own text colors, knowing the contrast will be good enough so long as their chosen text colors are at least as dark as #333 (or whatever cut-offs we choose).

Now, only talking about contrast leaves a lot of room to move. Maybe too much. A yellow on darkblue scheme would meet the definition of a dark scheme above, but it might clash on many websites designed for current dark mode schemes. So maybe we also want maximum saturation level or other restrictions.

But my point is, if we want to allow authors to use a color-scheme but selectively override parts of it, they need to know what they can expect. So, while we may also want to keep a broad definition of what light & dark mean (possibly broad enough that light could include sepia schemes), we need to limit how broad it can get.

Spec links:
https://drafts.csswg.org/css-color-adjust-1/#preferred
https://drafts.csswg.org/mediaqueries-5/#prefers-color-scheme

[tabatkins]

Note that sepia does indeed pass WCAG AAA, with a contrast ratio against white of 8.47.

Overall this seems like a good idea.

[css-meeting-bot]

The CSS Working Group just discussed definition of light and dark, and agreed to the following:

• RESOLVED: Add a note to color-scheme to warn authors that dark and light modes are not necessarily black and white colors, and that if they are specifying any of their own colors they should specify enough colors to satisfy WCAG requirements (with a link)

The full IRC log of that discussion

<fremy> Topic: definition of light and dark
<astearns> github: https://github.com//issues/3983
<emilio> ScribeNick: emilio
<emilio> AmeliaBR: So I wrote this up after the last telcon
<emilio> ... we were talking about sepia mode, and whether we needed a new keyword
<emilio> ... it came up that sepia is usually a dark text on light background which match light
<emilio> ... people assume that the default colors for light / dark mode are white / black
<emilio> ... and if we want more flexibility of color schemes but still group them into light / dark / etc. then we need to have some sort of normative definition of what do they mean
<emilio> ... i.e., how far can you adjust those while being light or dark
<hober> q+
<emilio> ... I put an example with yellow / bright blue on the issue, I'd be surprised if authors would expect a light theme to have those colors
<emilio> ... if authors use system colors or such and only use the preferred media query then having the variety could be problematic
<emilio> ... so I think we should define what's the scope of variation for these definition
<emilio> ... I posted some suggestions using the contrast definition, because that's a very important factor
<emilio> ... but we may want to limit saturation as well for example
<astearns> q+ heycam
<emilio> hober: disclaimer: I don't know about colors but I'm channeling feedback
<emilio> ... it's probably fine to have light / dark being somewhat generic
<emilio> ... I'm a little wary of including specific colors in that definition
<emilio> ... for example in Mac there's a fairly specific algorithm
<jensimmons> q+
<emilio> ... but yeah something that says "this needs to have enough contrast" sounds good
<astearns> ack heycam
<hober> s/I don't know about colors//
<emilio> heycam: I'm a bit skeptical about how much we need to worry about custom background and foreground colors set by the user and have sites be able to respond to all of those
<emilio> ... seems pretty niche, and if browsers wanted to decide whether they're light or dark that seems fine
<emilio> ... but probably this doesn't warrant spending a lot of time figuring out a precise authors
<emilio> AmeliaBR: this is also about potential future changes of OS-provided colors
<emilio> florian: seems like the OS vendor should be the one figuring that out
<fantasai> +1 to Florian
<hober> s/in Mac there's a fairly specific/macOS Mail has a complex/
<emilio> AmeliaBR: it's kind of awkward that this is the first issue we talk about this
<jensimmons> q-
<jensimmons> q+
<emilio> ... even something like sepia mode people seem to be clear that it's light, but for authors it doesn't seem so
<emilio> fantasai: may be worth adding a note to that effect to the spec
<Rossen_> q?
<Rossen_> ack jensimmons
<emilio> jensimmons: I'm unclear about what do you want us to write up, it's some kind of fence about where default background / colors can be? And if so why a fence and not a specific value?
<emilio> ... But this is also about the WG teaching designers to do the right thing
<emilio> ... and I don't think that that may be the right thing to reach them
<emilio> ... I also don't particularly agree that they would assume black / white
<emilio> ... I'd like to talk about it but it's probably not WG's business
<emilio> AmeliaBR: my main focus is about UAs but also about whether we should have different color schemes for the media queries but not for the properties
<emilio> ... I think we cannot resolve this issue without deciding how to group color schemes
<Rossen_> q?
<emilio> ... and are authors aware about it/
<emilio> ... because people are implementing different thing
<emilio> fantasai: spec says dark / light, no black / white, so we could add a note
<emilio> AmeliaBR: the issue is contrast, if the author assumes it's a black background for contrast requirements and the background ends up grey then there may not be enough contrast
<Rossen_> q+
<emilio> ... so my proposal is to define the min luminance ratio so that we can guarantee that authors meet requirements which may be a legal obligation
<emilio> jensimmons: ...
<emilio> jensimmons: Authors are probably going to be picking both background and foreground colors
<astearns> ack Rossen_
<emilio> Rossen_: When I was going about how high-contrast is implemented on windows
<jensimmons> jensimmons: we can add text to the spec to remind everyone that color contrast is important. In notes.
<emilio> ... There are three different ways of color-scheme propagation
<emilio> ... the os one (which doesn't propagate to the browser at least on windows)
<emilio> ... so for example the shell started to ship dark mode but none of the apps were opted in
<emilio> ... then there's the author of the application opting in to the UI of the application
<emilio> ... then there's the propagation into the content. high-contrast propagates all the way forcibly
<emilio> ... for color schemes, first there are not many colors to begin with, authors should be able to make pretty well educated guesses
<jensimmons> q?
<emilio> ... if the colors are what we need to expose, we already have this and decided to undeprecate the system colors
<emilio> ... and they would have an effect however the browser manages to get them there
<emilio> ... you can also opt individual apps into force colors mode (e.g., only the browser)
<emilio> ... none of this involves sepia btw
<emilio> ... though it's a reasonable expectation on content
<emilio> ... as we're going down this path it's best to have an easily detectable mechanism to figure out whether (1) I'm forced (2) what's the general preference (light / dark) (3) and a way to identify the individual colors so that you can programatically address them
<emilio> ... so my question is, what's missing in the platform so that authors can make these decisions
<emilio> AmeliaBR: for this specific issue we're just looking at the colors that came down to the content
<emilio> ... so your question is "we got the system colors, why would we need to define them more or less"
<jensimmons> q+
<emilio> ... one answer could be telling authors "just stick with system colors"
<emilio> ... but if we acknowledge that system colors won't be enough, then you need a way to figure out the variance
<emilio> Rossen_: wdym with system colors not being enough?
<emilio> AmeliaBR: if you also have your own brand color or such
<emilio> ... color mod functions may be enough?
<emilio> ... but right now we've got a system where people designing for dark mode make assumptions of what system colors look like
<emilio> ... so we need to either educate or limit dark mode to define what the range
<emilio> Rossen_: the UA UI-color choice is not something we should be demanding
<emilio> ... currently all of the color schemes that are propagated down are based on this matching the ui
<emilio> jensimmons: I think it's fine if we want to add notes and such in the spec
<emilio> ... but this proposal is to pin point what light and dark mean and I don't think we want to do that
<Rossen_> q?
<Rossen_> ack jensimmons
<emilio> ... we don't do that in a bunch of places and try to teach people how to use media queries
<bkardell_> we do sometimes *
<emilio> ... I don't share the premise of authors making assumptions about system colors
<tantek> bkardell_: indeed, it would be interesting to list all the places we reference WCAG* from CSS* specs
<tantek> in terms of author guidance
<emilio> ... it's not clear if we are entering an era where we have OSes have dark and light mode with a bunch of colors, or all the way to a heavily customized sites like in the old days
<bkardell_> https://www.w3.org/TR/css-flexbox-1/#order-accessibility
<emilio> ... I don't think we should define this without knowing where this is going
<Rossen_> q?
<AmeliaBR> q?
<emilio> ... and I think people are caring more and more about contrast and such
<emilio> hober: I agree with what jensimmons just said
<emilio> bkardell_: I thought hober said said that the spec could mention should have specific contrast
<emilio> jensimmons: well we could do add a somewhat vague note, but not finding a precise definition
<astearns> ack dbaron
<emilio> AmeliaBR: one way to solve this would be adding a warning to the spec to tell authors not to make assumptions about them
<emilio> dbaron: I think one of the problems we've had in the past is that when the platform has too many degrees of freedom in it, developers aren't able to test what they're doing well enough
<emilio> ... I spent a lot of time in the past dealing with GTK themes in the Firefox UI
<emilio> ... so I had to write a debugging mode where I would customize the light / background color, and ensuring that setting front / back colors were matched
<emilio> ... but they're extremely hard to test
<emilio> ... I think light / dark would be ok, but if you expose too many degrees of freedom
<emilio> ... then you break the users that have the weird settings
<florian> q+
<emilio> astearns: so you would oppose to add a note to the spec and would want something more normative?
<emilio> dbaron: I'm fine with a note as long as it's something for which authors can reasonably test, which I think this is
<emilio> AmeliaBR: so thinking about what that specific note should look like I think it should be focusing on the system colors (which includes using a color scheme and not specifying background / text colors)
<emilio> ... in that case we should encourage authors to use them in a very dedicated set
<emilio> ... that way if those pairs don't have enough contrast then it's the user choice
<emilio> ... but if you mix the colors with your on colors then you're also responsible
<tantek> Is there any existential evidence of *any* web designer or web site of authors using system colors in such pairs or very dedicated sets?
<emilio> ... (puts some example about some win10 dialog not working in high contrast)
<tantek> Many years ago I tried to do so and was one of the reasons why I gave up on System Colors
<emilio> dbaron: I think that goes well beyond what we can reasonably ask authors to do
<tantek> q?
<tantek> q+
<emilio> ... if you want that kind of stuff we need to write tools for that because they're not going to get it right
<florian> q-
<emilio> ... and I think we should ensure that light / dark mode should be coherent enough
<astearns> ack tantek
<emilio> tantek: specific response to AmeliaBR: without any successful evidence of authors doing so, it's irresponsible and a bit arrogant from us to tell authors what to do
<emilio> astearns: I suggest adding a note to the spec mentioning that light / dark themes won't always be white / black
<emilio> fantasai: there is such a note IIRC
<emilio> ... we can add a note in the color spec to tell it that system colors should be used in pairs
<emilio> tantek: i'd object to that
<emilio> astearns: is the light / dark theme note ok?
<emilio> tantek: that seems fine
<emilio> ... we should not give authors advice without evidence
<tantek> I specifically object to all the assumption about "pairs of system colors"
<emilio> jensimmons: I'd propose to have the note say "don't assume light / dark means white / black", and "think of color contrast"
<tantek> q?
<emilio> fremy: I think that's the point, we can't compute contrast correctly, we went all around
<emilio> ... (repeats the initial proposal about the minimmum contrast / darkness / lightness)
<tantek> I also said that any such advice should be checked with WCAG and if we can't find a WCAG citation for the advice, we should assume that there's a good chance we may be mistaken
<emilio> Rossen_: you can choose your own colors, if you want to follow WCAG
<AmeliaBR> q+ to wrap up with some proposals
<emilio> ... that's all we're saying
<emilio> astearns: I'm happy with jensimmons' suggestions
<emilio> fremy: it's about UA advice
<emilio> Rossen_: no it's not
<tantek> in some cases WCAG suggestions may be necessary but not sufficient, that is, it is possible there are WCAG recommendations that are not backed by evidence or possibly even existence
<emilio> fremy: it is, we have color provided by UA and you cannot apply WCAG if you don't know the color
<bkardell_> +1 to what jen said, that is what I was suggesting we were all saying in several ways
<emilio> emilio: I think Rossen_'s point makes sense, we expose these colors in getComputedStyle, and you can adhere to the guidelines with either color-modifying functions, JS, or using system colors
<emilio> AmeliaBR: I agree with fremy that we can't say "you can't know what the color is, but care about contrast"
<fantasai> s/there is such a note IIRC/we can add a note that "light" doesn't mean "black on white"/
<emilio> ... we can say "you don't know the colors, so if you use non-system colors you should set your background / foreground"
<fremy> +1 to what AmeliaBR just said, that would be acceptable to me
<emilio> ... we should also tell the system colors that are supposed to go together
<emilio> ... so those are my two recommendations
<tantek> going to state that system color "pairings" are fundamentally broken and we shouldn't even pretend that it's anything remotely workable for authors
<emilio> ... one saying that you don't know what you're going to get
<fantasai> +1 to AmeliaBR's proposal
<dbaron> opposed to Amelia's proposal
<emilio> ... and another for the pairs system colors are supposed to be used together
<tantek> -1 to any even description of such "pairings" because no one has actually made them work
<dbaron> we've been telling people to specify foreground and background colors together for 20 years, and it hasn't worked
<tantek> even without any "shoulds"
<emilio> astearns: so we have agreement on the first note but not on the system color stuff
<dbaron> if it had worked, we'd have been able to do dark system colors by default without pages having to opt in
<emilio> ... so I propose resolving for the first
<emilio> dbaron++
<tantek> dbaron's analysis is correct
<emilio> astearns: and leave the pairing of system colors for another time
<emilio> astearns: objections
<tantek> I'd like to close on "pairs" of system colors until someone comes back with actual new information / evidence that such "pairings" are workable
<fantasai> tantek, it's required for authors to work with such pairs for MSFT forced-colors mode
<AmeliaBR> and the system colors as a concept are unworkable without pairs
<tantek> fantasai I don't believe you - show me such an example
<AmeliaBR> RESOLVED: Add a note to color-scheme to warn authors that the exact colors for dark and light mode are not specified, and that if they need to guarantee contrast against their own colors, they need to specify both foreground and background pairs.
<astearns> s/RESOLVED: Add a note to color-scheme to warn authors that the exact colors for dark and light mode are not specified, and that if they need to guarantee contrast against their own colors, they need to specify both foreground and background pairs.//
<astearns> RESOLVED: Add a note to color-scheme to warn authors that dark and light modes are not necessarily black and white colors, and that if they are specifying any of their own colors they should specify enough colors to satisfy WCAG requirements (with a link)
<fantasai> ScribeNick: fantasai

[svgeesus]

I see this text in the spec, which is simultaneously precise and imprecise (my bold):

Additionally, if the UA determines (based on Lab lightness), that the canvas color is clearly either dark or light (for some reasonable UA delineation of “dark” or “light”), then it must match the appropriate value of the prefers-color-scheme media query and express a corresponding user preference for color-scheme.

Now, since L=50 is defined to be exactly mid-way, visually, between light and black then basing this on CIE Lightness is a good start. But then the spec text veers off into untestable handwaving while still using an RFC2119 must. I don't see why. Here is some suggested wording that splits lightness into thirds: light, mid/no-preference, and dark:

Additionally, if the UA determines,based on Lab lightness, that the canvas color is clearly either dark (L < 33%) or light (L >67%) , then it must match the appropriate value of the prefers-color-scheme media query and express a corresponding user preference for color-scheme.

[fantasai]

Added a note as resolved in #3983 (comment) and adjusted the color-scheme assumption rules as suggested by @svgeesus in #3983 (comment) (which is really a separate issue, but anyway). Specified the range in between as explicitly UA-defined.