W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2018

Re: [csswg-drafts] [mediaqueries-5] Dark Mode in CSS

From: Cameron McCormack via GitHub <sysbot+gh@w3.org>
Date: Tue, 17 Jul 2018 07:40:55 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-405490033-1531813249-sysbot+gh@w3.org>
There was [discussion at the July 2018 F2F](https://logs.csswg.org/irc.w3.org/css/2018-07-03/#e1044896) about dark mode and related media queries.

<details>
<summary>The full IRC log of that discussion</summary>
``
<fantasai> dino: Talked about prefers-dark mode ones.
<fantasai> dino: Other one is prefers-high-contrast
<fantasai> dino: Apple has a simple toggle for this. Prefer high contrast? Yes/NO
<fantasai> dino: It's much more complicated in Windows
<fantasai> dino: Would want auto | yes| no
<fantasai> dino: Blocked on not knowing what Windows or Android do, what granualrity do they have, how much do they want to expose.
<fantasai> frremy: We have states [light | dark ] high-contrast?
<fantasai> florian: In Apple contrast vs light/dark are separate
<fantasai> Rossen: That's different
<fantasai> Rossen: There's “high contrast” which could be user-defined, e.g. yellow and black
<fantasai> Rossen: There are themes, dark theme and light theme, and blue theme, etc.
<fantasai> Rossen: Nothing to do with conrast
<fantasai> Rossen: Can have bad contrast with dark theme
<fantasai> Rossen: they're just dark
<fantasai> Rossen: What frremy is talking about is high contrast
<fantasai> Rossen: not about themes
<fantasai> florian: MS conrast MQ has two options, white-on-black and black-on-white
<fantasai> florian: Apple has independent control of hgih-contrast vs not and dark bg vs light bg
<fantasai> Rossen: What we wanted to do in high conrast was to guarantee readability. That's what high-contrast is all about
<fantasai> Rossen: Had to figure out how to isolate text and make it readable
<fantasai> Rossen: Make sure it has ghigh contrast, regardless of colors
<fantasai> Rossen: Two options are white-on-black and black-on-white, nothing to do with dark theme
<fantasai> florian: I disagree with frremy's statement that this si the smaething as what Apple is doing
<fantasai> myles: You said high-contrast is a collection of themes and you also talked about how Window shas theming
<fantasai> myles: You can choose one of the many high contrasts or your own theme but not both?
<fantasai> iank_ explores the Android Settings men
<fantasai> menu
<fantasai> Rossen projects Windows
<fantasai> Rossen: Here is Edge browser in dark theme
<fantasai> Rossen: UI of browser is dark
<fantasai> Rossen: Current theme f windows is dark
<fantasai> Rossen: In terms of readability, having images with text on top of them is not the best for readability
<fantasai> Rossen projects browser with dark chrome, but web pages are rendering as normal
<fantasai> Rossen: If I turn on high contrast
<fantasai> Rossen: Now what you see is that inside fo the browser, we have applied a numbe rof techniques
<fantasai> Rossen: Firstly, all fo the UI is in high contrast
<fantasai> Rossen: This current page, as you can see on the images wher epreviously this text was not high-contrast because on top of the image
<fantasai> Rossen: Here we compute theb oundign areas of text, and make sure that we have a backing plate that preserves the contrast between the background and the text
<fantasai> Rossen: This is not observable by the web author
<fantasai> Rossen: In the past we would strip bgimgaes entirely, b/c we didn't know how to deal with it
<fantasai> Rossen: but htis is high contrast
<fantasai> Rossen: So that was high contrast
<fantasai> Rossen: So themes, are something esparate
<fantasai> florian: Within constrat, you can pick different styles of high contrast
<shane> invert colors inverts bitmap images but not vector images on Android. In practice this means everything in Chrome though.
<fantasai> Rossen: Right, so I can change the colors instead of having yellow on black, I can flip the colors
<fantasai> dino: Apple does that, but only for subtitles in videos
<fantasai> dino: We allow complete customization of captions
<fantasai> Rossen: We do this for everything
<fantasai> Rossen: We have predefined high contrast themes, e.g. white on black and black on white
<fantasai> Rossen: Also can have themes
<fantasai> Rossen: I can change the UI colors like this
<fantasai> Rossen: I can change just the borwser theme, even though the OS is dark theme
<heycam> ScribeNick: heycam
<TabAtkins> ScribeNice: TabAtkins
<heycam> dino: do you have any mode to say turn off the transparency [in the panel]?
<heycam> frremy: yes
<heycam> dino: in accessibility?
<heycam> frremy: no
<heycam> dino: we have that option too, might be worth considering that for a MQ in the future, since some people find that distracting
<astearns> suggests we all buy some of our competitor's equipment for research purposes
<fantasai> q+
<Zakim> sees fantasai on the speaker queue
<astearns> ack fantasai
<Zakim> sees no one on the speaker queue
<heycam> fantasai: I think there's several things here we're talking about
<heycam> ... not the same thing
<heycam> ... one is general theming of the OS, where you want to change the chrome toolbars etc. but you don't want to change any content
<heycam> ... that is outside the scope of what we're doing here
<heycam> Rossen: that's what I wanted to point out
<heycam> fantasai: we could make it in scope, if you wanted to try to match the theme, but we're not concerned with that today
<heycam> ... rather cases where the user wants changes in the content of pages
<heycam> ... then there's the request for: I want high constrast, and I want dark or not
<heycam> ... four states possible here
<heycam> ... actually more than that
<heycam> ... two axes here
<heycam> ... (whatever, high constrast, low contrast) x (whatever, light, dark)
<heycam> ... default state is whatever, page shows whatever. "light" would mean force dark backgrounds to be light etc.
<heycam> ... for (whatever, light), you don't care what the contrast is
<heycam> ... Windows doesn't have a (whatever, high constrast)
<heycam> Rossen: that's not true
<heycam> ... you can choose some colors
<heycam> fantasai: but you're not responding to what the author said
<heycam> ... there's no setting that says I see there are white colors on dark bgs
<heycam> ... which tries to detect "is this a dark themed page or light themed page"
<heycam> Rossen: I agree
<heycam> ... this is how it will be for the forseeable future
<heycam> astearns: you're talking about forcing things
<heycam> ... I thought we're talking about MQs
<heycam> ... where authors can key off of, and provide a high constrast experience, not forcing something
<heycam> ... if they're cared to provide one
<heycam> fantasai: that's separate
<heycam> Rossen: what francois was trying to describe is available
<heycam> ... currently we provide MQ to say y/n for high-contrast. and for the two default themes, light or dark, what it is
<heycam> florian: when you say "y", in your MQ, you have something to let the author know high contrast has been forced with some colors
<heycam> ... fantasai is asking about a way with MQ to know if the page is forced constrast with its existing page colors
<heycam> Rossen: of course not
<myles> Q+
<Zakim> sees myles on the speaker queue
<heycam> chris_: [demos what Android does]
<heycam> ... has a Negative Colors option
<heycam> dino: we have a MQ for that
<heycam> ... similar to the color-invert stuff
<heycam> chris_: and there's a color lens thing
<heycam> ... lastly, color adjustment for different color blindness
<astearns> ack myles
<Zakim> sees no one on the speaker queue
<heycam> myles: I have a question about Edge's MQs
<heycam> myles: I turn on high constrast on Windows
<heycam> ... web page has a MQ that matches that
<heycam> ... in the MQ that says make text blue, whatever
<heycam> ... does Edge then take that as a signal the web page is handling high constrast itself? and the UA doesn't need to do anything?
<heycam> Rossen: basically what was mentioned this moring, we have a property that lets you opt out an element and its subtree, from high constrast imposed by the OS
<heycam> ... for that particular element and its subtree, you can define whatever colors you want
<heycam> ... if you want to guarantee high constrast go ahead and do it
<heycam> myles: got it
<heycam> Rossen: if it's one the two default high constraints options, black on white, white on black, if you can use a MQ to handle it yourself
<heycam> myles: is it possible to use that property to turn off high constrast handling outside the MQ?
<heycam> Rossen: yes
<heycam> florian: we have the thing Apple brought, is different from this
<heycam> ... because the Windows mode is about forcing the page into one of several high constrast modes
<heycam> ... and letting the author detect this has happend, and through the property let the author opt out
<heycam> ... the thing Apple brought is not detecting it has forced high constrast, but the user requested the page does it to itself
<heycam> frremy: sure
<heycam> Rossen: so your assertion is that the high constrast mode will by default never apply to content, unless the content decides yeah I'll do it
<heycam> dino: for Apple, yes, we don't force high constrast on any content
<heycam> florian: there are multiple types of high constrast. some are preferences, some are enforced
<heycam> ... which you may be able to opt out or not
<heycam> astearns: one of the distinctions in my mind about these things is that I don't think it's our place to specify browser forcing behavior as a CSSWG
<heycam> ... we're not going to specify anything that says "here's what happens when a browser forces changes on content"
<fantasai> Chart on the board: x-axis has whatever | forced high-contrast | forced low-contrast | prefers high-contrast | prefers low-contrast
<fantasai> y-axis has whatever | forced light | forced dark | prefers light | prefers dark
<heycam> ... the only thing we can do is provide a MQ that says the user prefers a certain high constrast scenario, or that your content decisions have been hijacked by the UA
<heycam> dino: I agree
<heycam> ... and our request is only for the former
<heycam> ... we just want the user to indicate to the dev of the page they've made a preference decision
<heycam> ... the color-filter property discussed this morning is a hammer the dev can use to make it easier to satisfy one of those preferences, but it's not required
<heycam> florian: I was also thinking that combinations of preferences is easier to handle
<heycam> florian: the MS things are reasonable but more complex
<heycam> ... I tried to devise a single MQ query that dealt with all of that, preferences and enforcements
<heycam> ... so I suggest we don't try to solve all these with the one MQ
<heycam> ... the preference thing is simple
<myles> Q+
<Zakim> sees myles on the speaker queue
<heycam> ... the MS is not as simple, we should solve them separately
<heycam> ... exactly what the page should do if force high constrast and prefer low constrast... shouldn't be exposed to the page
<astearns> ack myles
<Zakim> sees no one on the speaker queue
<heycam> myles: I understand there are these two ideas how to implement these features
<heycam> ... is MS making a proposal to standarized their way?
<heycam> Rossen: we made this a long time ago
<heycam> astearns: but it's not the currenty issue
<heycam> frremy: we'd be find having a pref to high constrast
<heycam> frremy: if we force high constrats the user prefers constrast
<heycam> ... if the user forces high constrast they prefer high constrast
<tantek> hears high (dynamic volume) contrast
<skk> Current description on the board: http://www.tsukune.org/skk/tmp/mq.jpg
<heycam> TabAtkins: what do you think people will do when the MQ is true? prefer high constrast true?
<heycam> frremy: make it high consrast
<heycam> TabAtkins: but it's already happened by the UA
<heycam> myles: he is imagining the content would turn on the property to say "don't do high constrast" and do it themselves
<heycam> frremy: and it's more complex, if you don't set the property, and you have the prop in the MQ, it's applied anyway
<heycam> ... it will work
<heycam> ... if the define everything for prefer, it'll work
<heycam> florian: in that direction it works
<heycam> ... if the page has been devised with Apple semantics in mind, and the browser does what you says, it'll work.
<heycam> ... if it has been designed for Edge design, assumes that prefers high constrats means I've been forced, so I should do nothing, if you run it in Safari the page won't do it
<heycam> myles: if the page will do nothing why would it have this MQ
<heycam> florian: it would turn off some subtle things?
<heycam> frremy: this is not worse
<heycam> fantasai: [whiteboard, chart of different combinations of preferences and forcing]
<heycam> ... you can get all the info you want on what kind of constrast you like or are forced into
<heycam> ... there really seems to be two sets of prefs
<heycam> ... one is about constrast, one is about light on dark and vv
<heycam> ... the MS MQ mixes them into the same thing
<heycam> ... you can have no pref, but also pref for high constrast
<heycam> ... or prefer high constrast, or I've been forced into high constrast
<heycam> ... you can treat them the same or distinct, as an author
<heycam> ... in terms of whether you're forced into dark on light or vv, then having a brightness preferecne will tell you which one you're in already
<heycam> ... these are MQ values I've written
<heycam> frremy: I would be find without these four values
<heycam> s/four/force/
<heycam> ... you can use the property to opt out of them
<heycam> frremy: if people want to know about them they can use the MQs
<heycam> florian: MSDN says the high constrast MQ has been removed
<heycam> Rossen: that's wrong
<skk> fantasai's description: http://www.tsukune.org/skk/tmp/mq2.jpg
<heycam> fantasai: frremy your suggestion someone doing the same as MS must create their own vendor specific features to interop with you?
<heycam> frremy: there is no browser who wants to match with us right now
<heycam> astearns: if they want to we can bring something to the group
<heycam> fantasai: we have to standardize their extensions with their syntax
<heycam> dbaron: interoperate with what aspect of what MS does?
<heycam> ... Gecko has certainly to reacted to windows high constrast theme settings in various ways, probably differently from Edge
<heycam> ... it doesn't override a lot of colors
<heycam> emilio: we disable alpha colors
<heycam> astearns: my suggestion is, we've had a discussion, put it into the issue
<emilio> s/alpha/cauthor
<heycam> ... sounds like we do want these MQs in some form
<emilio> s/cauthor/author :)
<heycam> ... and then come back to it at a later meeting
<birtles> Gecko makes quite a few changes when Windows high-contrast mode is set (e.g. dropping the fill of SVG shapes and showing their outline)
<heycam> dino: one point, I don't know if we need a prefers-contrast:low
<heycam> Rossen: actually there is a dyslexia adaptation ...
<heycam> florian: we described the way you react to high constrast active, which doesn't say if it's black on white or vv, I'm the page that knows how to do it, and I'll go into high constrast, [...]
<heycam> Rossen: if you're responsibel you will query the colors
<heycam> fantasai: you can't do that
<heycam> Rossen: you can
<heycam> fantasai: not in a x platform way
<heycam> dino: what do people think of the brightness name? I didn't like the term "dark mode" or "dark content". but "brightness" is a bit weird...
<heycam> fantasai: I just put that up because I needed a word
<heycam> florian: I would go with something like "color theme", but that might be confused with UI theme...
<heycam> ... preferred color scheme?
<heycam> fantasai: it's about the content
<heycam> ... there's the theming scheme, which we might expose at some point in the future, and the prefers light vs dark
<heycam> <br type="afternoon-tea">
<myles> The proposal is two media queries: prefers-contrast: none | high | high-forced | low | low-forced, and prefers-brightness: none | light | dark | forced-dark | forced-light | forced-something
<fantasai> alternately prefers-contrast: none | high | low | forced
<fantasai> or prefers-contrast: none | [ high | low ] || forced
<astearns> not sure preferring no contrast is a thing
``


-- 
GitHub Notification of comment by heycam
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2735#issuecomment-405490033 using your GitHub account
Received on Tuesday, 17 July 2018 07:41:13 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:30:53 UTC