W3C home > Mailing lists > Public > www-style@w3.org > July 2019

[CSSWG] Minutes Toronto F2F 2019-06-05 Part IV: Color Adjust, Media Queries [css-color-adjust] [media-queries]

From: Dael Jackson <daelcss@gmail.com>
Date: Sat, 6 Jul 2019 18:52:17 -0400
Message-ID: <CADhPm3tbX1-Dv099oay+Uoic580PnoPoEc6aePmNVGn9FsEvvA@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Saturday, 6 July 2019 22:53:11 UTC