- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 6 Jul 2019 18:52:17 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Color Adjust
-------------
- 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) (Issue #3983: Clearly define
what 'light' and 'dark' mean)
- There was heavy disagreement as to if the spec should also include
a note that both foreground and background should be specified
in pairs. Due to the lack of consensus the pairs section of text
was not added to the spec.
- There was support for allowing prefers-color-scheme to expose
subsets of color-scheme in the future. Without user agents
expressing a desire to implement any additional color schemes it
was decided that it was too early to add this to spec and
instead it was important to avoid writing spec text that would
prevent this in the future.
- RESOLVED: No change (Issue #3853: Future <custom-ident> value
sepia)
Media Queries
-------------
- There was disagreement on the purpose of the no-preference value
for prefers-color-scheme (Issue #3857: UA guidance on light vs
no-preference).
- Part of the group argued that the default state of the web is
no-preference where designers create their own look, but the
other side said that a majority of the web is already light so
the reality is the default would equal light already.
- Windows has three options for color schemes (light, dark,
system default), but macOS only has two (light and dark)
- There was concern that three values would lead to designers
feeling the need to create color schemes instead of two
(rather than letting no-preference share with either light or
dark).
===== FULL MINUTES BELOW =======
Agenda: https://wiki.csswg.org/planning/toronto-2019
Scribe: emilio
Color Adjust
============
Clearly define what 'light' and 'dark' mean
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3983
AmeliaBR: So I wrote this up after the last telecon
AmeliaBR: We were talking about sepia mode, and whether we needed a
new keyword
AmeliaBR: It came up that sepia is usually a dark text on light
background, which matches "light"
AmeliaBR: People assume that the default colors for light / dark
mode are white / black
AmeliaBR: 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
AmeliaBR: i.e., how far can you adjust those while being light or
dark
AmeliaBR: 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
AmeliaBR: If authors use system colors or such and only use the
preferred media query then having the variety could be
problematic
AmeliaBR: so I think we should define what's the scope of variation
for these definition
AmeliaBR: I posted some suggestions using the contrast definition,
because that's a very important factor
AmeliaBR: but we may want to limit saturation as well for example
hober: Disclaimer: I'm channeling feedback
hober: It's probably fine to have light / dark being somewhat generic
hober: I'm a little wary of including specific colors in that
definition
hober: For example macOS Mail has a complex algorithm
hober: but yeah something that says "this needs to have enough
contrast" sounds good
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
heycam: seems pretty niche, and if browsers wanted to decide whether
they're light or dark that seems fine
heycam: but probably this doesn't warrant spending a lot of time
figuring out a precise authors
AmeliaBR: This is also about potential future changes of OS-provided
colors
florian: Seems like the OS vendor should be the one figuring that out
<fantasai> +1 to Florian
AmeliaBR: It's kind of awkward that this is the first issue we talk
about this
AmeliaBR: Even something like sepia mode people seem to be clear
that it's light, but for authors it doesn't seem so
fantasai: May be worth adding a note to that effect to the spec
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?
jensimmons: But this is also about the WG teaching designers to do
the right thing
jensimmons: and I don't think that that may be the right thing to
reach them
jensimmons: I also don't particularly agree that they would assume
black / white
jensimmons: I'd like to talk about it but it's probably not WG's
business
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
AmeliaBR: I think we cannot resolve this issue without deciding how
to group color schemes
AmeliaBR: and are authors aware about it
AmeliaBR: because people are implementing different thing
fantasai: Spec says dark / light, not black / white, so we could add
a note
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
AmeliaBR: so my proposal is to define the minimum luminance ratio so
that we can guarantee that authors meet requirements which
may be a legal obligation
jensimmons: ...
jensimmons: Authors are probably going to be picking both background
and foreground colors
jensimmons: we can add text to the spec to remind everyone that
color contrast is important. In notes.
Rossen: When I was going about how high-contrast is implemented on
windows
Rossen: There are three different ways of color-scheme propagation
Rossen: The os one (which doesn't propagate to the browser at least
on windows)
Rossen: so for example the shell started to ship dark mode but none
of the apps were opted in
Rossen: Then there's the author of the application opting in to the
UI of the application
Rossen: Then there's the propagation into the content.
Rossen: high-contrast propagates all the way forcibly
Rossen: For color schemes, first there are not many colors to begin
with, authors should be able to make pretty well educated
guesses
Rossen: If the colors are what we need to expose, we already have
this and decided to un-deprecate the system colors
Rossen: and they would have an effect however the browser manages to
get them there
Rossen: You can also opt individual apps into forced-colors mode
(e.g., only the browser)
Rossen: None of this involves sepia btw
Rossen: though it's a reasonable expectation on content
Rossen: 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
programmatically address them
Rossen: So my question is, what's missing in the platform so that
authors can make these decisions
AmeliaBR: For this specific issue we're just looking at the colors
that came down to the content
AmeliaBR: So your question is "we got the system colors, why would
we need to define them more or less"
AmeliaBR: One answer could be telling authors "just stick with
system colors"
AmeliaBR: but if we acknowledge that system colors won't be enough,
then you need a way to figure out the variance
Rossen: What do you mean with system colors not being enough?
AmeliaBR: If you also have your own brand color or such
AmeliaBR: color mod functions may be enough?
AmeliaBR: But right now we've got a system where people designing
for dark mode make assumptions of what system colors look
like
AmeliaBR: so we need to either educate or limit dark mode to define
what the range
Rossen: The UA UI-color choice is not something we should be
demanding
Rossen: currently all of the color schemes that are propagated down
are based on this matching the ui
jensimmons: I think it's fine if we want to add notes and such in
the spec
jensimmons: but this proposal is to pin down what light and dark
mean and I don't think we want to do that
jensimmons: We don't do that in a bunch of places and try to teach
people how to use media queries
jensimmons: I don't share the premise of authors making assumptions
about system colors
jensimmons: 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
jensimmons: I don't think we should define this without knowing
where this is going
jensimmons: and I think people are caring more and more about
contrast and such
<bkardell> we do sometimes * [in reference to teaching people]
<tantek> bkardell: indeed, it would be interesting to list all the
places we reference WCAG* from CSS* specs
<tantek> in terms of author guidance
<bkardell> https://www.w3.org/TR/css-flexbox-1/#order-accessibility
hober: I agree with what jensimmons just said
bkardell: I thought hober had said that the spec could mention
should have specific contrast
jensimmons: Well we could do add a somewhat vague note, but not
finding a precise definition
AmeliaBR: One way to solve this would be adding a warning to the
spec to tell authors not to make assumptions about them
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
dbaron: I spent a lot of time in the past dealing with GTK themes in
the Firefox UI
dbaron: 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
dbaron: but they're extremely hard to test
dbaron: I think light / dark would be ok, but if you expose too many
degrees of freedom
dbaron: then you break the users that have the weird settings
astearns: So you would oppose to add a note to the spec and would
want something more normative?
dbaron: I'm fine with a note as long as it's something for which
authors can reasonably test, which I think this is
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)
AmeliaBR: in that case we should encourage authors to use them in a
very dedicated set
AmeliaBR: That way if those pairs don't have enough contrast then
it's the user choice
AmeliaBR: but if you mix the colors with your on colors then you're
also responsible
AmeliaBR: (puts some example about some win10 dialog not working in
high contrast)
<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?
<tantek> Many years ago I tried to do so and was one of the reasons
why I gave up on System Colors
dbaron: I think that goes well beyond what we can reasonably ask
authors to do
dbaron: if you want that kind of stuff we need to write tools for
that because they're not going to get it right
dbaron: and I think we should ensure that light / dark mode should
be coherent enough
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
astearns: I suggest adding a note to the spec mentioning that
light/dark themes won't always be white / black
fantasai: We can add a note that "light" doesn't mean "black on
white"
fantasai: We can add a note in the color spec to tell it that system
colors should be used in pairs
tantek: I'd object to that
astearns: Is the light / dark theme note ok?
tantek: That seems fine
tantek: we should not give authors advice without evidence
<tantek> I specifically object to all the assumption about "pairs of
system colors"
jensimmons: I'd propose to have the note say "don't assume light /
dark means white / black", and "think of color contrast"
<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
fremy: I think that's the point, we can't compute contrast
correctly, we went all around
fremy: (repeats the initial proposal about the minimum contrast/
darkness/lightness)
Rossen: You can choose your own colors, if you want to follow WCAG
Rossen: that's all we're saying
<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
astearns: I'm happy with jensimmons' suggestions
fremy: It's about UA advice
Rossen: No it's not
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
<fantasai> https://github.com/w3c/csswg-drafts/commit/df94ea26ff9f99c3d3fedbfc4c7c59f15232ee6b
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
AmeliaBR: I agree with fremy that we can't say "you can't know what
the color is, but care about contrast"
AmeliaBR: 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
AmeliaBR: We should also tell the system colors that are supposed to
go together
AmeliaBR: so those are my two recommendations
AmeliaBR: One saying that you don't know what you're going to get
AmeliaBR: and another for the pairs system colors are supposed to be
used together
<fantasai> +1 to AmeliaBR's proposal
<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
<dbaron> opposed to Amelia's proposal
<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"
<dbaron> if it had worked, we'd have been able to do dark system
colors by default without pages having to opt in
<emilio> dbaron++
<tantek> dbaron's analysis is correct
astearns: so we have agreement on the first note but not on the
system color stuff
astearns: so I propose resolving for the first
astearns: and leave the pairing of system colors for another time
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
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)
Future <custom-ident> value sepia
---------------------------------
Scribe: fantasai
github: https://github.com/w3c/csswg-drafts/issues/3853
AmeliaBR: Discussing idea of having sepia color scheme
AmeliaBR: to reflect reader mode options
AmeliaBR: Discussed whether it's just a different type of light
scheme
AmeliaBR: We have two different use cases
AmeliaBR: We have prefers-color-scheme MQ
AmeliaBR: which author use to set their own colors
AmeliaBR: And we have color-scheme which is about requesting or
indicating which sets of UA color schemes you can work
with without breaking
AmeliaBR: These use cases are different
AmeliaBR: Suggestion from Tab was for color-scheme property we could
keep generic light/dark and maybe other
AmeliaBR: for prefers-color-scheme could have more nuanced options,
so within 'light' might distinguish bright white vs sepia
AmeliaBR: Author could figure out which scheme user prefers the most
AmeliaBR: If we have nested hierarchical preferences, how does that
look like?
florian: From MQ mechanics, no problem with multiple values matching
at the same time. Just need to say so
florian: Whether we want to do that is a separate question
AmeliaBR: So if we define nested categories, then MQ can handle it
AmeliaBR: Question is do we want a comprehensive set of queries light
/dark/other?
TabAtkins: What would other be?
AmeliaBR: Brightly colored
AmeliaBR: Like blue-on-yellow
TabAtkins: I don't think that's realistic anyway
TabAtkins: Every scheme we've seen in practice can be described as
light or dark
TabAtkins: I've seen maybe a few middling schemes, like light red on
dark red
TabAtkins: but otherwise seen stark colors, low-contrast grays,
and sepia
AmeliaBR: Also talked about color-scheme: any;
AmeliaBR: decided any was problematic
AmeliaBR: what about adding other
TabAtkins: Not quite as opposed, but don't think we need it yet
TabAtkins: If we have a definitive third category, then happy to
reconsider, and leaning toward that strategy for it
AmeliaBR: User would pick specific scheme, e.g. dark red on light red
AmeliaBR: But author has to say "this website can work with light
scheme, dark scheme, or other scheme"
una: I think something as general as other is too generic
una: maybe call it contrast
una: Like idea of sepia, but depends on so many things like ambient
light
una: I like thought of considering that and giving authors more power
jensimmons: I feel pretty strongly that the controls that we want to
provide for authors need to match what browser makers are
going to do in revealing user-facing controls
jensimmons: Right now we're responding to light mode/dark mode toggles
jensimmons: It's in the news and popular media right now, switching
entire OS to dark
jensimmons: or browser to dark
jensimmons: What I don't see is any browser maker stepping forward
jensimmons: to provide more complex controls for users
jensimmons: to opt into sepia or chocolate-fudge-brownie-cake or
whatever
jensimmons: If we provide these controls to authors, they don't go
anywhere
jensimmons: there's no demand for them, not hooked up to anything
AmeliaBR: non-browser UAs offer controls for more variants
jensimmons: Or FF reader mode
jensimmons: But as author I can't style within reader mode anyway
jensimmons: there's nothing for me as an author to do
jensimmons: I have no access to that as an author
jensimmons: Having a sepia mode in reader mode is not relevant to me
as an author
jensimmons: if Firefox wanted to hook that up to something else then
we could consider
<hober> i (again) completely agree with jensimmons
TabAtkins: If sepia mode shows images, might want to alter images
fantasai: Reader mode can apply sepia filter if it wants to
jensimmons: Also want us to separate ideas that we personally have
about how we want to surf the Web
jensimmons: from the reality of what browsers will actually
implement wrt controls for users
jensimmons: Right now I don't think sepia reader mode will be hooked
up to images like you describe
jensimmons: This is one case where I really want browsers to say "we
want this in CSS"
<AmeliaBR> As a user, I want sepia mode everywhere. Please. Please
let me at least ask websites for it.
<emilio> use MSFT forced-colors mode
hober: We have a sepia mode in our ereader, and I don't want a sepia
mode here.
TabAtkins: Do these books have CSS in them?
hober: Of course they do
hober: Even if ? solves the problem for itself, I don't want to do
it here
florian: EPUB is HTML + CSS
jensimmons: As person making a website, you can't control how reader
mode presents content on any level
<una> I agree with jensimmons that we should only be aligning color
scheme media queries with what capabilities the browser gives
users
florian: Broadly yes, but for ebook readers, the style applies, the
CSS that you apply in your book applies, and there is a
sepia mode
jensimmons: Are there any ebook readers that want us to expose this
to authors
dauwhe: I can also ask Readium about it
hober: Absent a *positive request* from an implementer.
hober: I'm not saying never ship it
hober: if someone ships an OS-level control for it, we can do that
hober: but I'm not seeing that
TabAtkins: I'm fine with that
TabAtkins: largely because behavior of "not sepia" and "not
supported value" are identical
TabAtkins: More general idea, what if any is the necessary
correlation between color-scheme property and
prefers-color-scheme
TabAtkins: I think we can have them diverge in value space and
meaning a bit
TabAtkins: Light vs dark we should keep
TabAtkins: prefers-color-scheme can deliver more detail as we wish
it, sepia being a likely candidate
TabAtkins: When we have an existence proof of an implementation then
we can add it later
TabAtkins: maybe put a note in the spec that this could happen
* emilio notes that there exists a note
florian: I think I agree with Tab that MQ and property are separate
florian: If we were to add sepia mode this is how we would do it,
but absent demand from implementers let's not do it yet
tantek: I think similar to some of the previous questions, we should
gauge it also by what are web authors publishing today
tantek: I've seen some sepia style pages, would be easy to opt in
tantek: but haven't seen a lot of them, so dunno how much demand
there is
tantek: demand would have to be demonstrated to consider adding such
a mode
<tantek> e.g.
https://github.com/w3c/csswg-drafts/issues/3853#issuecomment-499244493
<aja> issue was mostly to stop thinking of (supports-)color-scheme
as binary dark/light, since it's spec'ed to support other
values
TabAtkins: Note that none of this is "please add a sepia mode", it's
just "if you have a sepia mode, this is how to handle it"
<aja> what Tab said
tantek: To assess that plausibility in the future, we can look at
what web authors are publishing to see if that would
motivate browsers
TabAtkins: I don't care, it's not relevant to me
TabAtkins: I didn't say "please implement a new color scheme,
browsers" Just establish how we will handle this in the
future.
<emilio> https://github.com/w3c/csswg-drafts/issues/3853#issuecomment-494472950
[Options list:
- Add it to the spec as a legal value with a description
- Don't add it to the spec, but use it in an example of handling
unknown names from the future
- Don't mention it
]
tantek: Which of the three options are we going with?
TabAtkins: I want a note in the spec so I remember in the future
fantasai: Add a comment in the source code
myles: Audience of the spec isn't just people in this room
AmeliaBR: There's a note already mentioning possibility of future
values
AmeliaBR: Wanted to respond to no demand from UAs
AmeliaBR: Nobody exposing these other modes
AmeliaBR: Want to go back to Rossen's comment about nested
hierarchies
AmeliaBR: There's the OS color scheme, app UI scheme, and content
color scheme
AmeliaBR: There is no demand for sepia in the outer levels
AmeliaBR: There is demand for color scheme selectors that focus only
on content
AmeliaBR: It still comes down to we need UAs who are offering those
color schemes to make that connection with these brand new
CSS mechanisms
AmeliaBR: But just because it hasn't happened yet in the 6 months
that we've discussed this, doesn't mean it won't happen
next year
AmeliaBR: We do have in the spec trying to be forward-focused with
idea that there might be additional color schemes
AmeliaBR: so proposal is to clearly state that the color scheme
keywords and prefers-color-scheme are not going to be 1:1
AmeliaBR: color-scheme property will focus on general classes of
color scheme
AmeliaBR: and prefers-color-scheme exposes those classes but may in
the future expose more specific subsets
AmeliaBR: to distinguish e.g. sepia mode vs bright white mode
florian: I don't disagree with what you're saying
florian: but it's overly prescriptive for what the WG might do in
the future
TabAtkins: I'm done with this topic, we got the feedback we needed
jensimmons: It's a good idea to think about future-forward and make
sure we don't engineer ourselves into a corner
jensimmons: I also feel strongly that I don't want to put into any
spec any values that don't exist yet
jensimmons: because it will really clutter up the discussion we have
to have with designers
jensimmons: to explain all this dark mode light mode stuff
jensimmons: We already have to do a lot of education
jensimmons: we don't need it to be excessively complicated or
overwhelming
jensimmons: I don't want to overengineer anything
jensimmons: Keep ourselves from blocking into a corner, but don't
try to anticipate a future that doesn't exist yet
<AmeliaBR> If the decision of the group is that we won't do this
without user agent requests, we should have an note in
the editor's draft spec requesting user agent feedback.
RESOLVED: No change
What has Apple done?
====================
TabAtkins: Talked to Tess already, so don't need to discuss here
TabAtkins: Can we get smfr on the call in two weeks?
hober: yes
TabAtkins: I want that information please
hober: I can't guarantee that smfr will know the things
Media Queries
=============
Scribe: myles
UA guidance on light vs no-preference
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3857
fantasai: The background is we have a wide variety of content types
on the 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.
<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 preference for content."
fantasai: Anyone disagree?
jensimmons: Are we saying that every part of a page should be on a
dark background with white text?
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"
jensimmons: There are cases where 1 blog designer might say the
article text should 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
jensimmons: I think what you're saying is the first is good, but not
the second
<AmeliaBR> `prefers-color-scheme-ui: dark`
`prefers-color-scheme-content: dark`
`prefers-content-meaning: dark`
fantasai: It means "it is difficult for me to work with a light-mode
scheme", or...
<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"
<fantasai> vs. "I'm in a dark room or otherwise have difficulty with
light-mode theming, please make things dark for me"
fantasai: The other thing: light should have 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 care what the UI is, but the default mode of
the web is no preference. The default mode that is
communicated should be no-preference.
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
TabAtkins: Even though you only have two states, you should map it
to "no preference" and dark.
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.
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
have been calling light is a no preference mode. It's not a
preference for light.
florian: All the pro apps are still dark in the light mode
hober: Not all websites are going to listen for this thing. That's
okay.
jensimmons: I disagree with the first statement: Dark mode means
everything has to be dark. We don't need that. That
belongs in the hands of the designer. Some sites can
interpret "dark" differently than other sites. Authors
can interpret it differently.
TabAtkins: If I want dark mode because I'm in bed, I would be
unhappy with any light
jensimmons: You're speaking as a user. Websites can do that to their
users.
florian: We are describing what this preference means.
jensimmons: That is not how this is going to work out.
TabAtkins: You are arguing that the notion of dark mode is not useful
<tantek> I'd like "I (webpage) can handle dark mode, except can you
take care of dark form controls and scrollbars for me" ?
<AmeliaBR> tantek, that's the color-scheme property, we're talking
about the prefers-color-scheme MQ again
<AmeliaBR> I mean, it's not like this are confusing concepts or
anything...
<tantek> AmeliaBR wait prefers-color-scheme is shipping already?!?
https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme#Browser_compatibility
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 mode
where all web content is dark, then you need a browser that
is going to make destructive modifications to websites
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.
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 in a
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 that users have chosen where one option
in that preference is "the legacy behavior where most stuff
but not all was light" and the 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 weak. The other is strong. That's
the thing we have. Trying to map that onto a tri-state,
where two options are symmetric, and one must express no
preference at all is not going to work
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 fuchsia, 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"
florian: The default shouldn't 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 a light
mode at all, but the default one should not be a request to
be light
<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?
<AmeliaBR> +1 for florian's summary
<fantasai> agrees with florian
<hober> +1 to dbaron
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
aesthetic 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 from light and dark.
florian: I am confused.
una: no-preference is equal to brand identity
florian: Yes, and it should be the default
florian: In macOS, one is dark and one is the default. Even though
you labeled it as light, it means no-preference
florian: So the request is to for MacOS to map what is called
"light" to no-preference
hober: No
florian: So Mercedes can continue to be dark
astearns: We are asking for changes in UA behavior
TabAtkins: in dark mode, you expect all apps to be dark, right?
hober: No. I agree with dbaron
TabAtkins: A well-behaved app should be dark, right?
hober: I don't know what "well-behaved" means
hober: If I'm in photoshop, the canvas's background is white, I
don't expect it to be black in dark mode
hober: If I change the preference, I expect many things to change,
and some things not to.
<AmeliaBR> Do we agree that browsers should give users a
no-preference option? Or is that also controversial?
<TabAtkins> amelia, we're saying that browsers *already* give a
no-pref option, and "dark mode" adds dark; no OS
currently actually gives a "light" mode
<TabAtkins> correction, apparently newest Windows has three options
^_^
<AmeliaBR> TabAtkins, but that proposal has been shot down. If Day
Mode doesn't mean no-preference, then is there going to
be any way for users to express no preference?
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 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?
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
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.
Light on windows means, all dark things that are dark by
default get light. There is this new mode that is "light" in
which case the start menu and settings become light
fremy: This is how the media query should be modeled
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
<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/
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.
TabAtkins: What is the expectation for a page in light mode?
hober: As mild as the preference for dark
florian: For the pages that do respond, what do they do?
TabAtkins: If you respond to the query, and you do something with
your colors, is the expectation that they will be light?
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.
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?
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
astearns: We can't be that black or white about our expectations.
Given the desires of advertisers, I can certainly see one
saying "they're in dark mode, I'll use light colors to
stand out"
TabAtkins: People can be assholes no matter what
TabAtkins: What do the values mean? What should authors do with the
media query? If we can't answer those questions, we
remove the media query
<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.
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
<fantasai> jensimmons, we're not expecting to design three options.
Either the website doesn't care (ignore all options, one
design only)
<fantasai> jensimmons, or it designs two: light mode and dark mode.
In no-preference mode, they pick whichever one they like
the most
<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.
<bradk> AmeliaBR +1
<jensimmons> I simply don’t understand how three options will work.
astearns: We are done for the day.
Post meeting chat
- - - - - - - - -
<jensimmons> no preference, light-mode-preference,
dark-mode-preference is three sets of code to think
about and plan for… to design & engineer.
<fantasai> no, just two
<bradk> fantasai: +1
<fantasai> unless your website prefers lime green on fuchsia, in
which case it might be difficult to call that "light" or
"dark" ;)
<TabAtkins> Today, FooCorp Inc has dark branding guidelines; all
their printed material is dark background with a
light-color icon.
<TabAtkins> The website team wants to be responsible, so they use
(prefers-color-scheme).
<bkardell> I don't understand really why that is 'be responsible' ?
<AmeliaBR> jensimmons: In reality, it's about the choice between
whether the website code uses dark and not-dark media
queries (no-preference uses light), versus light and
not-light (no-preference uses dark). You don't need three
media queries, you usually only need one versus your
default styles.
<bradk> That’s a good point AmeliaBR
<AmeliaBR> Thanks Bradk. Wish you were here!
<bradk> Me too
<AmeliaBR> and not just because you're agreeing with me...
<bradk> 😀
<TabAtkins> If MacOS is set to dark, (prefers-color-scheme:dark)
matches, cool, the default corp branding works. The
website as already designed works.
<TabAtkins> If MacOS is set to the non-dark option, does that mean
the site should do an opposite style, with dark logo on
light background?
<TabAtkins> (I submit that that is *not* the expectation currently.)
<bradk> It’s not a CSS thing, but I hope browsers let user opt out
of web page dark mode even when the OS setting is dark mode.
Apple does that for mail.app
<bradk> So window chrome and menus etc are dark, but documents in
the browser are not.
<bradk> Like hober’s photoshop example.
Received on Saturday, 6 July 2019 22:53:10 UTC