Re: [csswg-drafts] [mediaqueries-5] UA guidance on light vs no-preference (#3857)

The CSS Working Group just discussed `UA guidance on light vs no-preference`.

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: UA guidance on light vs no-preference<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/3857<br>
&lt;hober> q+<br>
&lt;myles_> ScribeNick: myles<br>
&lt;myles_> ScribeNick: myles_<br>
&lt;myles_> fantasai: The bakcground is we have a wide variety of content types on teh web. some are application-like, and some are art-like. For the use case of night reading, authors need to perceive dark not as a UI choice, but as a global choice for all content.<br>
&lt;myles_> fantasai: anyone disagree?<br>
&lt;myles_> jensimmons: are we saying that every part of a page should be on a dark background with white text?<br>
&lt;myles_> fantasai: no. It means the user wants a dark mode (such as being in a dark environment) so please adapt to that expectation. It's not just "i think black looks cool"<br>
&lt;myles_> jensimmons: There are cases where 1 blog designer might say the article textshould be light on dark in dark mode. But a different one might only want to do that to the sidebar, not to the body text<br>
&lt;myles_> jensimmons: I think what you're saying is the first is good, but not the second<br>
&lt;dbaron> I think the text fantasai read was "The Web consists of a wide variety of content types, some of which are application-like, and others which are art-like: for dark mode to be useful for e.g. night reading, as has been suggested, authors need to perceive (prefers-color-scheme: dark) not as a preference for UI in app-like interfaces, but as a global<br>
&lt;dbaron> preference for content."<br>
&lt;myles> fantasai: it means "it is difficult for me to work with a light-mode scheme", or "<br>
&lt;fantasai> We need to distinguish between "I want my apps to be dark mode, but content whatever, because I want the app interfaces to fade into the background wrt the content I'm focusing on"<br>
&lt;fantasai> vs. "I'm in a dark room or otherwise have difficulty with light-mode theming, please make things dark for me"<br>
&lt;hober> q?<br>
&lt;florian> q+<br>
&lt;myles> fantasai: the other thing: light has the same weight as preference/desire as dark. If an implementation wants to have a no-preference mode, it maps to a no-preference mode. I don't carewhat the UI is, but the default mode of the web is no preference. The default mode that is communicated is no-preference.<br>
&lt;myles> TabAtkins: Current dark websites should not be told "everyone on the web prefers light, please use a light mode" when in reality most users don't have a preference, use any mode<br>
&lt;myles> TabAtkins: Even though you only have two states, you should map it to "no preference" and dark.<br>
&lt;astearns> ack hober<br>
&lt;myles> hober: We have no notion of no-preference on our platforms. At OS install time, we prompt the user to pick light or dark. You have to to move on to the next screen. There is no system concept of no preference. We're not interested in pretending otherwise.<br>
&lt;jensimmons> a website I designed over a decade ago: http://runesofgallidon.com<br>
&lt;myles> florian: You're describing what you call the buttons in the UI. On macOS, there is a light and dark button. If you pick dark, all apps are dark. If you pick light, only some are light. So yes, you call it light, but in reality it doesn't mean that. Apps don't get forced into light mode. The mode you ahve been calling light is a no preference mode. It's not a preference for light.<br>
&lt;myles> florian: all the pro apps are still dark in teh light mode<br>
&lt;myles> hober: Not all websites are going to listen for this thing. That's okay.<br>
&lt;myles> jensimmons: I disagree with the first statement: Dark mode means everything has to be dark. We don't need that. That belongs in teh hands of the designer. Some sites can interpret "dark" differently than other sites. Authors can interpret it differently.<br>
&lt;myles> TabAtkins: If i want dark mode because i'm in bed, I would be unhappy with any light<br>
&lt;myles> jensimmons: Your'e speaking as a user. Websites can do tha tto their users.<br>
&lt;myles> florian: We are describing what this preference means.<br>
&lt;myles> jensimmons: That is not how this is going to work out.<br>
&lt;myles> TabAtkins: You are arguing that the notion of dark mode is not useful<br>
&lt;myles> dbaron: I think you started from the assumption that this should be symmetric. In reality, it is not symmetric. So saying "therefore it should be symmetric" is not helpful. The reality we're starting from is that existing content wouldn't work if users had dark defaults. If you want a mdoe where all we bcontent is dark, then you need a browser that is going to make destructive modifications to websites<br>
&lt;una> q+<br>
&lt;AmeliaBR> ack dbaron<br>
&lt;tantek> I'd like "I (webpage) can handle dark mode, except can you take care of dark form controls and scrollbars for me" ?<br>
&lt;TabAtkins> TabAtkins: That's not what I'm saying. I know I"ll get blasted by light sites sometimes. But *if* I say Dark Mode, and I visit a reasonable site that pays attention to it, I expect the site to be dark. That's just the general expectation of what that value means.<br>
&lt;myles> dbaron: I think we're starting from a world where most web pages are light. And some pages are going to be willing to design two options, some aren't. That's the reality. We're also ina. world where a bunch of OSes have introduced these dark mode preferences. It's a request that a lot of stuff be dark. So, we have preferences htat users have chosen where one option in that preference is "the legacy behavior where most stuff but not all was light" and the<br>
&lt;myles>  other is "i request more stuff be dark". Those are the preferences that people are asking to be reflected to the web. Those aren't symmetric. Trying to map into a thing that's symmetric or pretend that one is an expression of no preference at all, where the light one is a weak preference for maybe no preferences, and maybe "i have not chosen the dark mode". The dark mode preference is a stronger preference. It's not "no preference at all' but it's pretty<br>
&lt;myles>  weak. The other is strong. That' sthe thing we have. Trying ot map that onto a tri-state, wehre two optinos are symmetric, and one must express no preference at all is not going to work<br>
&lt;jensimmons> q+<br>
&lt;myles> florian: I don't think no-preference means no preference. No-preference mode means "the state of today". Most websites tend to be white. Some websites are dark, and some are fuscia, and I'm okay with that, which results in most content being light. This is No-preference. If we had two states, it would be "what you've been doing" and "dark". If we had 3 states, it would be "light", "dark", and "no-preference"<br>
&lt;jensimmons> But what in the world are the browsers / OSes going to do with three states? What are Authors going to do with three states?<br>
&lt;myles> florian: THe default shouldnt' mean "i really need you to be light". If an UI has 3 states, it should map to 3. If it has 2 states, the one that isn't dark, the one remaining should be a no-preference value. Or, we shouldn't have al ight mode at all, but the default one should nto be a request to be light<br>
&lt;fremy> q+<br>
&lt;AmeliaBR> +1 for florian's summary<br>
&lt;hober> +1 to dbaron<br>
&lt;AmeliaBR> ack florian<br>
&lt;astearns> ack una<br>
&lt;myles> una: Yes, a lot of websites tend to be light with dark text on light background. That's true for media websites with text, but landing pages are often dark. We have light and dark modes; I see them, and people interpret modes where their current astehtic is not sufficient, then use light to create a light version of the website. Mercedes is a dark theme, with many dark pages. There are use cases for both. There's no benefit in separating out no-preference<br>
&lt;myles>  from light and dark.<br>
&lt;myles> florian: i am confused.<br>
&lt;myles> una: no-prefernce is equal to brand identity<br>
&lt;myles> florian: Yes, and it should be the default<br>
&lt;myles> florian: In macOS, one is dark and one is the default. Even though you labelled it as light, it means no-preference<br>
&lt;myles> florian: so the request is to for macos to map what is called "light" to no-preference<br>
&lt;myles> hober: no<br>
&lt;bkardell_> &lt;room chuckles><br>
&lt;myles> florian: so mercedes can continue to be dark<br>
&lt;myles> astearns: we are asking for changes in UA behavior<br>
&lt;jensimmons> q?<br>
&lt;myles> TabAtkins: in dark mode, you expect all apps to be dark, right?<br>
&lt;myles> hober: no. i agree with dbaron<br>
&lt;myles> TabAtkins: A well-behaved app should be dark, right?<br>
&lt;myles> hober: I don't know what "well-behaved" means<br>
&lt;myles> hober: If I'm in photoshop, the canvas's background is white, I don't expect it to be black in dark mode<br>
&lt;myles> hober: If I change the preference, I expect many things to change, and some things not to.<br>
&lt;astearns> ack jensimmons<br>
&lt;TabAtkins> q+<br>
&lt;AmeliaBR> Do we agree that browsers should give users a no-preference option? Or is that also controversial?<br>
&lt;myles> jensimmons: Priority of constituency. This is a theoretical purity vs practicality argument. Theoretically, users should pick light and everything should be entirely light. but that won't happen because of the history. So we should explain how dark means everything should be dark, and vice versa? I'm not on board with that. The control that's presented to users is light and dark. Sometimes it's in the OS, and some are in the browser, and this doesn't make<br>
&lt;myles>  sense to me. I don't know how to tell authors how to make 3 designs? Should some AI do it for the artist? So why do we want 3 options? What should the browser hook up to each option in the media query?<br>
&lt;myles> jensimmons: The reality is that we don't know yet what designers are going to want to do with a vague idea of dark "mode" and the vague idea of light "mode". Users might hate it, but it's their right to make something users hate. Maybe both modes will be lightish, but that's just the design of the page<br>
&lt;astearns> ack fremy<br>
&lt;myles> fremy: We have been saying that all OSes have 2 themes: light and dark, where light doesn't mean anything strong. In the latest windows, there is 3 options: no preference, dark, and light.<br>
&lt;florian> q+<br>
&lt;myles> Light on windows means, all dark things that are dark by default get light.<br>
&lt;myles> There is this new mode that is "light" in which case the start menu and settings become light<br>
&lt;myles> fremy: This is how the media query should be modelled<br>
&lt;myles> q+<br>
&lt;fantasai> q+<br>
&lt;myles> fremy: Maybe we should revisit this issue in a little while. It doesn't sound crazy to me to map 2 preferences to no-preference and dark<br>
&lt;astearns> ack TabAtkins<br>
&lt;myles> TabAtkins: dark mode means something. Applications/pages can respond to it and do something. There is an expectation about what a page responding to dark mode is. Something will happen to a page. And it will be dark.<br>
&lt;myles> TabAtkins: What is the expectation for a page in light mode?<br>
&lt;myles> hober: As mild as the preference for dark<br>
&lt;myles> florian: For the pages that do respond, what do they do?<br>
&lt;myles> TabAtkins: If you respond to the query, and you do something with your colors, is the expectation that they will be light?<br>
&lt;astearns> q?<br>
&lt;myles> heycam: The expectation is that for pages and apps that have both, they will chose the light, but that's not the expectation that all pages will do that. Some ::more:: will be light or dark.<br>
&lt;myles> fantasai: Specific example of the mercedes page. Let's say they make a light and dark background pages. My branding strategy is that I want most people to see the dark one, but if they want light, they will turn that one on. On macOS, are they going to switch into the light mode, or would the expectation be that they get the branding colors they ideally want the users to have in light mode?<br>
&lt;fremy> if someone want to learn about the new windows light mode aka "the perfect antithesis of the dark mode", here is a blog post: https://www.windowschimp.com/windows-10-light-theme/<br>
&lt;myles> TabAtkins: In dark mode, we expect mercedes to use dark colors. In the other mode, we expect them to use their normal brand colors, which are light<br>
&lt;myles> astearns: we can't be that black or white about our expectations. Given the desires of advertisers, I can certainly see one saying "theyr'e in dark mode, I'll use light colors to stand out"<br>
&lt;myles> TabAtkins: People can be assholes no matter what<br>
&lt;myles> TabAtkins: What do teh values mean? What should authors do with the media query? If we can't answer those questions, we remove the media query<br>
&lt;bradk> I think most of the time ‘light’ and ‘no-preference’ would be designed the same way. But Mercedes might have a ‘light’ version that is not shown for no-preference.<br>
&lt;myles> q?<br>
&lt;jensimmons> q?<br>
&lt;bkardell_> q+<br>
&lt;myles> jensimmons: Your example: team at mercedes, they have had a design for years, so they design two more versions of the site: light and dark. So what do they do with the no preference mode? I don't want to give them three options<br>
&lt;bkardell_> q-<br>
&lt;fantasai> jensimmons, we're not expecting to design three options. Either the website doesn't care (ignore all options, one design only)<br>
&lt;AmeliaBR> No preference doesn't mean, design a third color scheme. It means the website author gets to pick whether to use the dark scheme or the light scheme.<br>
&lt;jensimmons> I simply don’t understand how three options will work.<br>
&lt;dauwhe> +1 to astearns plan<br>
&lt;myles_> astearns: We are done for the day.<br>
&lt;fantasai> jensimmons, or it designs two: light mode and dark mode. In no-preference mode, they pick whichever one they like the most<br>
&lt;bradk> And liaBR: +1<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3857#issuecomment-499261339 using your GitHub account

Received on Wednesday, 5 June 2019 21:24:56 UTC