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

[CSSWG] Minutes Sydney F2F 2018-07-04 Part IV: Media Queries [mediaqueries]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 24 Jul 2018 19:09:14 -0400
Message-ID: <CADhPm3ssm=yw7DQMTcv+iSnMmFfB11N0dD9SztcFAQ2MEDeEeg@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.

Media Queries

  - The various approaches to handling and then exposing a user's
      preference around high contrast and brightness was covered to
      determine if a media query should be created
      - Everyone was in favor of exposing a media query, but there
          were a lot of potential approaches and variation in what
          vendors do
      - Microsoft forces the change and combines contrast and
          brightness whereas Apple just exposes the users preference
      - Two media queries, one for high contrast and one for
          brightness were generally preferred over just one media
          query combining the two.

  - prefers-reduced-data media query (Issue #2370) seemed possible,
      but the group needs to know that there's actual demand before
      beginning work.

  - RESOLVED: Remove Media line from all propdef tables (Issue #2413)
  - RESOLVED: Add a normative statement for properties that say
              "Media: all" explaining what "Media: all" meant. (Issue
  - RESOLVED: Close this issue (Issue #2791: Is the `<mf-range>`
              "swapping value and name" syntax really useful?) with no


Agenda: https://wiki.csswg.org/planning/sydney-2018#schedule

Scribe: fantasai

Media Queries

Prefers high contrast

  dino: Talked about prefers-dark mode media queries already.
  dino: Other one is prefers-high-contrast
  dino: Apple has a simple toggle for this. Prefer high contrast?
  dino: It's much more complicated in Windows
  dino: Would want auto | yes | no
  dino: Blocked on not knowing what Windows or Android do, what
        granularity do they have, how much do they want to expose.

  frremy: We have states [light | dark ] high-contrast?
  florian: In Apple contrast vs light/dark are separate
  Rossen: That's different
  Rossen: There's “high contrast” which could be user-defined, e.g.
          yellow and black
  Rossen: There are themes, dark theme and light theme, and blue
          theme, etc.
  Rossen: Nothing to do with contrast
  Rossen: Can have bad contrast with dark theme
  Rossen: they're just dark
  Rossen: What frremy is talking about is high contrast
  Rossen: not about themes.
  florian: MS contrast MQ has two options, white-on-black and
  florian: Apple has independent control of high-contrast vs not and
           dark background vs light background

  Rossen: What we wanted to do in high contrast was to guarantee
          readability. That's what high-contrast is all about
  Rossen: Had to figure out how to isolate text and make it readable
  Rossen: Make sure it has high contrast, regardless of colors
  Rossen: Two options are white-on-black and black-on-white, nothing
          to do with dark theme
  florian: I disagree with frremy's statement that this is the same
           thing as what Apple is doing

  myles: You said high-contrast is a collection of themes and you also
         talked about how Windows has theming
  myles: You can choose one of the many high contrasts or your own
         theme but not both?

  [iank explores the Android Settings menu]
  <shane> invert colors inverts bitmap images but not vector images on
          Android. In practice this means everything in Chrome though.

  [Rossen projects Windows]
  Rossen: Here is Edge browser in dark theme
  Rossen: UI of browser is dark
  Rossen: Current theme of windows is dark
  Rossen: In terms of readability, having images with text on top of
          them is not the best for readability
  [Rossen projects browser with dark chrome, but web pages are
      rendering as normal]
  Rossen: If I turn on high contrast:
  Rossen: Now what you see is that inside of the browser, we have
          applied a number of techniques
  Rossen: Firstly, all of the UI is in high contrast
  Rossen: This current page, as you can see on the images where
          previously this text was not high-contrast because on top of
          the image
  Rossen: Here we compute the bounding areas of text, and make sure
          that we have a backing plate that preserves the contrast
          between the background and the text
  Rossen: This is not observable by the web author
  Rossen: In the past we would strip background images entirely, b/c
          we didn't know how to deal with it
  Rossen: but this is high contrast
  Rossen: So that was high contrast
  Rossen: So themes, are something separate

  florian: Within contrast, you can pick different styles of high
  Rossen: Right, so I can change the colors instead of having yellow
          on black, I can flip the colors
  dino: Apple does that, but only for subtitles in videos
  dino: We allow complete customization of captions
  Rossen: We do this for everything
  Rossen: We have predefined high contrast themes, e.g. white on black
          and black on white

  Rossen: Also can have themes
  Rossen: I can change the UI colors like this
  Rossen: I can change just the browser theme, even though the OS is
          dark theme

Scribe: heycam
  dino: Do you have any mode to say turn off the transparency [in the
  frremy: Yes
  dino: In accessibility?
  frremy: No, general option
  dino: We have that option too, might be worth considering that for a
        MQ in the future, since some people find that distracting

  fantasai: I think there's several things here we're talking about
  fantasai: not the same thing
  fantasai: One is general theming of the OS, where you want to change
            the chrome toolbars etc. but you don't want to change any
  fantasai: That is outside the scope of what we're doing here
  Rossen: That's what I wanted to point out
  fantasai: We could make it in scope, if you wanted to try to match
            the theme, but we're not concerned with that today
  fantasai: rather cases where the user wants changes in the content
            of pages

  fantasai: Then there's the request for: I want high contrast, and I
            want dark or not
  fantasai: Four states possible here
  fantasai: actually more than that
  fantasai: two axes here
  fantasai: (whatever, high contrast, low contrast) x (whatever,
            light, dark)
  fantasai: Default state is whatever, page shows whatever. "light"
            would mean force dark backgrounds to be light etc.
  fantasai: for (whatever, light), you don't care what the contrast is
  fantasai: Windows doesn't have a (whatever, high contrast)
  Rossen: That's not true
  Rossen: You can choose some colors
  fantasai: But you're not responding to what the author said
  fantasai: There's no setting that says I see there are white colors
            on dark backgrounds
  fantasai: which tries to detect "is this a dark themed page or light
            themed page"
  Rossen: I agree
  Rossen: This is how it will be for the forseeable future

  <fantasai> Chart on the board: x-axis has whatever | forced
             high-contrast | forced low-contrast | prefers
             high-contrast | prefers low-contrast
  <fantasai> y-axis has whatever | forced light | forced dark |
             prefers light | prefers dark

                | whatever |   high-contrast  |    low-contrast  |
                |          | forced | prefers | forced | prefers |
       whatever |          |        |         |        |         |
   forced light |          |        |         |        |         |
    forced dark |          |        |         |        |         |
  prefers light |          |        |         |        |         |
   prefers dark |          |        |         |        |         |
  <skk> Currently on the board: http://www.tsukune.org/skk/tmp/mq.jpg
  [ archived at

  astearns: You're talking about forcing things
  astearns: I thought we're talking about MQs
  astearns: where authors can key off of, and provide a high contrast
            experience, not forcing something
  astearns: if they're cared to provide one
  fantasai: That's separate
  Rossen: What frremy was trying to describe is available
  Rossen: Currently we provide MQ to say y/n for high-contrast. And
          for the two default themes, light or dark, what it is
  florian: When you say "y", in your MQ, you have something to let the
           author know high contrast has been forced with some colors
  florian: fantasai is asking about a way with MQ to know if the page
           is forced contrast with its existing page colors
  Rossen: Of course not.

  chris: [demos what Android does]
  chris: Has a Negative Colors option
  dino: We have a MQ for that
  dino: Similar to the color-invert stuff
  chris: And there's a color lens thing
  chris: Lastly, color adjustment for different color blindness

  myles: I have a question about Edge's MQs
  myles: I turn on high contrast on Windows
  myles: Web page has a MQ that matches that
  myles: in the MQ that says make text blue, whatever
  myles: Does Edge then take that as a signal the web page is handling
         high contrast itself? And the UA doesn't need to do anything?
  Rossen: Basically what was mentioned this morning, we have a
          property that lets you opt out an element and its subtree,
          from high contrast imposed by the OS
  Rossen: for that particular element and its subtree, you can define
          whatever colors you want
  Rossen: if you want to guarantee high contrast go ahead and do it
  myles: Got it
  Rossen: If it's one of the two default high constraints options,
          black on white, white on black, if you can use a MQ to
          handle it yourself
  myles: Is it possible to use that property to turn off high contrast
         handling outside the MQ?
  Rossen: Yes

  florian: We have the thing Apple brought, is different from this
  florian: because the Windows mode is about forcing the page into one
           of several high contrast modes
  florian: and letting the author detect this has happened, and
           through the property let the author opt out
  florian: The thing Apple brought is not detecting it has forced high
           contrast, but the user requested the page does it to itself
  frremy: Sure
  Rossen: So your assertion is that the high contrast mode will by
          default never apply to content, unless the content decides
          yeah I'll do it
  dino: For Apple, yes, we don't force high contrast on any content
  florian: There are multiple types of high contrast. Some are
           preferences, some are enforced
  florian: which you may be able to opt out or not

  astearns: One of the distinctions in my mind about these things is
            that I don't think it's our place to specify browser
            forcing behavior as a CSSWG
  astearns: We're not going to specify anything that says "here's what
            happens when a browser forces changes on content"
  astearns: The only thing we can do is provide a MQ that says the
            user prefers a certain high contrast scenario, or that
            your content decisions have been hijacked by the UA
  dino: I agree
  dino: and our request is only for the former
  dino: We just want the user to indicate to the dev of the page
        they've made a preference decision
  dino: The color-filter property discussed this morning is a hammer
        the dev can use to make it easier to satisfy one of those
        preferences, but it's not required

  florian: I was also thinking that combinations of preferences is
           easier to handle
  florian: The MS things are reasonable but more complex
  florian: I tried to devise a single MQ query that dealt with all of
           that, preferences and enforcements
  florian: so I suggest we don't try to solve all these with the one MQ
  florian: The preference thing is simple
  florian: The MS is not as simple, we should solve them separately
  florian: Exactly what the page should do if force high contrast and
           prefer low contrast... shouldn't be exposed to the page

  myles: I understand there are these two ideas for how to implement
         these features.
  myles: Is MS making a proposal to standardized their way?
  Rossen: We made this a long time ago
  astearns: But it's not the current issue
  frremy: We'd be fine having a pref for high contrast
  frremy: if the user forces high contrast they prefer high contrast

  TabAtkins: What do you think people will do when the MQ is true?
             prefer high contrast true?
  frremy: Make it high contrast
  TabAtkins: But it's already happened by the UA
  myles: He is imagining the content would turn on the property to say
         "don't do high contrast" and do it themselves
  frremy: And it's more complex, if you don't set the property, and
          you have the prop in the MQ, it's applied anyway
  frremy: It will work
  frremy: If the define everything for prefer, it'll work
  florian: In that direction it works
  florian: If the page has been devised with Apple semantics in mind,
           and the browser does what you says, it'll work.
  florian: If it has been designed for Edge design, assumes that
           prefers high contrast means I've been forced, so I should
           do nothing, if you run it in Safari the page won't do it
  myles: If the page will do nothing why would it have this MQ
  florian: It would turn off some subtle things?
  frremy: This is not worse

  fantasai: [whiteboard, chart of different combinations of
            preferences and forcing]
  <skk> fantasai's description: http://www.tsukune.org/skk/tmp/mq2.jpg
  [ whiteboard shows
      prefers-contrast: none | high | high-forced | low | low-forced
      prefers-brightness: none | light | dark | forced-light |
  fantasai: You can get all the info you want on what kind of contrast
            you like or are forced into

  fantasai: There really seems to be two sets of prefs
  fantasai: One is about contrast, one is about light on dark and vice
  fantasai: The MS MQ mixes them into the same thing
  fantasai: You can have no pref, but also pref for high contrast
  fantasai: or prefer high contrast, or I've been forced into high
  fantasai: You can treat them the same or distinct, as an author
  fantasai: In terms of whether you're forced into dark on light or
            vice versa, then having a brightness preference will tell
            you which one you're in already
  fantasai: These are MQ values I've written

  frremy: I would be fine without these force values
  fantasai: You can use the property discussed earlier to opt out of
  frremy: If people want to know about them they can use the MQs
  florian: MSDN says the high contrast MQ has been removed
  Rossen: That's wrong

  fantasai: frremy your suggestion someone doing the same as MS must
            create their own vendor specific features to interop with
  frremy: There is no browser who wants to match with us right now
  astearns: If they want to we can bring something to the group
  fantasai: We have to standardize their extensions with their syntax
  dbaron: Interoperate with what aspect of what MS does?
  dbaron: Gecko has certainly to reacted to windows high contrast
          theme settings in various ways, probably differently from
  dbaron: it doesn't override a lot of colors
  emilio: We disable author colors
  <birtles> Gecko makes quite a few changes when Windows high-contrast
            mode is set (e.g. dropping the fill of SVG shapes and
            showing their outline)

  astearns: My suggestion is, we've had a discussion, put it into the
  astearns: Sounds like we do want these MQs in some form
  astearns: and then come back to it at a later meeting

  dino: One point, I don't know if we need a prefers-contrast: low
  Rossen: Actually there is a dyslexia adaptation ...
  florian: We described the way you react to high contrast active,
           which doesn't say if it's black on white or vv, I'm the
           page that knows how to do it, and I'll go into high
           contrast, [...]
  Rossen: If you're responsible you will query the colors
  fantasai: You can't do that
  Rossen: You can
  fantasai: Not in a cross platform way

  dino: What do people think of the brightness name? I didn't like the
        term "dark mode" or "dark content". but "brightness" is a bit
  fantasai: I just put that up because I needed a word
  florian: I would go with something like "color theme", but that
           might be confused with UI theme...
  florian: Preferred color scheme?
  fantasai: It's about the content
  fantasai: There's the theming scheme, which we might expose at some
            point in the future, and the prefers light vs dark for

  <br type="afternoon-tea">

  <myles> The proposal is two media queries:
          prefers-contrast: none | high | high-forced | low | low-forced
          prefers-brightness: none | light | dark | forced-dark |
            forced-light | forced-something
  <fantasai> alternately prefers-contrast: none | [ high | low ] ||
  <astearns> not sure preferring no contrast is a thing
  [ none should be no-preference]

prefers-reduced-data MQ
  github: https://github.com/w3c/csswg-drafts/issues/2370

  florian: I don't know for sure in which browser but I suspect in
           chrome, which has a new HTTP header which they can send if
           the user requested so
  florian: which informs the web server that you would prefer
           lightweight content
  florian: There has been a suggestion to have a MQ to match that
  florian: In the same circumstances, the page author would also know
           that the user may be directly / through some heuristic,
           prefers some lightweight content
  florian: Images as a background instead of a video, e.g.
  florian: Seems reasonable to me

  myles: How does chrome know when to send the header?
  philipwalton: I think it's from the OS on Android
  iank: There's a setting Chrome, prefer lightweight data, then we
        send everything through potentially an HTTP proxy
  iank: Few other things as well
  florian: Is it user triggered
  iank: Yes
  iank: but I'm not sure, might be varied on country basis
  iank: We run HTTP proxies where we'll send traffic through that,
        then do a bunch of compression for the user
  myles: So the proxy might turn on the header?
  iank: No
  iank: the proxy is one of the side effects from turning on this
  iank: and I think the bit of information that we give devs is on
  philipwalton: It's a client hints header, in the clients hint spec

  florian: Somebody proposed to detect this via MQ
  fantasai: Seems reasonable to me

  astearns: Is that header, are there plans for other browsers to
            implement this?
  fantasai: What values does the header have?
  philipwalton: I think it's just a boolean at this point
  philipwalton: but the spec is written in a way that it could apply
                additional values
  fantasai: I can imagine wanting three levels, I don't care, I would
            prefer if you didn't give me heavy things, I'm on a
            metered / dialup connection so keep it absolutely minimal

  <astearns> http://httpwg.org/http-extensions/client-hints.html#save-data
  iank: Quickly looking through the additional things we expose, we
        also give as headers (what we think is the effective)
        roundtrip time
  iank: an estimate of the downlink speed
  philipwalton: And effective connection type
  heycam: mobile vs fixed?
  iank: 3g, 4g, slow 2g, ....
  florian: Don't think we'd expose all that
  florian: via the MQ
  florian: Having something that can be used in a boolean context,
           where one case is no preference, and may have other "yes
           please" levels

  iank: One thing I'd like to see here is use cases for where it's
        used in CSS
  florian: Use image background instead of video background
  iank: Do that with script
  philipwalton: 1x vs 2x?
  florian: Browser should do that already
  [side discussion about font-display:optional]
  philipwalton: With save data, 1x vs 2x, could be your device
                supports 2x but you only want a smaller version of the
  florian: Mostly you should not be using resolution MQ feature, but
           instead image-set
  florian: then the load data preference could influence that

  myles: Maybe terribly idea, can we extend that mechanism to allow
         switching between videos and images as backgrounds, instead
         of a MQ?
  fantasai: MQs are not only used in CSS, also media attr in HTML...
  emilio: Responsive images
  iank: I'm not saying no, but I want to see web developer demand for
  astearns: That's the general tone I'm hearing
  astearns: sounds like it could be useful, but we'd need to have it
            motivated by use cases and I'd prefer to see this client
            hint get a bit farther on the track
  florian: Sounds ok

  koji: This is an Android OS setting
  ericwilligers: It's both Android and a Chrome setting

porting media groups
  github: https://github.com/w3c/csswg-drafts/issues/2413

  florian: CSS 2.1 has a section, media groups, which describes what
           media groups are
  florian: visual, interactive, static, things like this
  florian: It doesn't define what they are, just lists what exists
  florian: then says visual is print or screen or tv or handheld
  florian: Interactive is print or screen or some tvs
  florian: This is used in the propdef for every property definition
  florian: Media: Visual
  florian: fantasai suggested porting this to something else
  florian: but I don't think it does anything useful
  florian: Unlike the Applies line, which says browsers will do
           nothing on some elements
  florian: this basically says "on some browsers this property won't
           be supported"
  florian: They're insufficiently described
  florian: The way we've used the Media line, 95% say Visual, the few
           that say something else are using it wrong
  florian: I suggest we stop having a Media line

  dbaron: I think the reality is there's been not a lot of
          implementation of CSS for anything other than visual media
  dbaron: and what implementation there has been hasn't provided
          feedback to the WG, so the specs don't account for it well
  florian: The animations and transitions properties claim to work on
           interactive media, not visual
  florian: If you look at how interactive is defined, it would seem to
           mean the transitions and animations work on a kindle with
           buttons, but not on a digital signage screen with no buttons
  florian: which is wrong
  florian: So we could define it in a way that's correct
  florian: but it's still not useful
  frremy: Makes sense to me
  myles: Is it valuable to say you can't animate on a piece of paper?

  RESOLVED: Remove Media line from all propdef tables

  github: https://github.com/w3c/csswg-drafts/issues/2791

  florian: (width < 100px) is allowed in MQ L4
  florian: It also lets you do (100px > width) which people don't care
           about strongly
  florian: but they also let you do (50px < width < 100px)
  florian: Firefox has implemented the first one
  florian: and claimed that the second two are more difficult to
  emilio: It's not that I'd like not to, it's that it's somewhat
  emilio: The way we do parts of MQs now, you look at the media
          feature name, you know what kind of value you parse, so you
          have the value before it, it is more annoying to figure out
          which is the media feature name
  emilio: and identifiers can also be media feature values
  emilio: If you have an ident operator ident, you can't reject it,
          because you can't know that a range feature with ident
          values wouldn't make sense, but...
  florian: I think the third option is nice
  florian: TabAtkins's suggestion was if dropping the middle one, you
           can still easily identify the media feature for the third
           one, just a couple more tokens later
  emilio: I think if we're going to keep the last one, we may as well
          keep the previous one
  astearns: Doesn't make it much easier
  astearns: Are you the only ones implementing this?
  emilio: I think so, so far
  frremy: That was two weeks ago

  ericwilligers: I think this is clear:
                 width < 100
                 100 <= width < 200
                 200 < width
  ericwilligers: with the last one the width on the RHS
  florian: If removing the middle one was a significant
           simplification, we can do it, but sounds like not

  RESOLVED: Close this issue with no change

porting media groups (cont.)
  github: https://github.com/w3c/csswg-drafts/issues/2413

  fantasai: I ran a grep through the tree
  fantasai: Almost everything is Visual, some exceptions
  fantasai: Interactive vs not is not interesting
  fantasai: but we distinguish between CSS props that should affect
            the accessibility tree, and the ones that shouldn't
  fantasai: or don't
  fantasai: Content prop affects what shows up to a screen reader
  fantasai: Display does
  astearns: How is that expressed?
  florian: By Media: all
  astearns: Are we consistent about that?
  fantasai: Yes
  fantasai: Props that should add or remove content from the a11y tool
  fantasai: It's an indicator to the screen reader as to what content
            should be added or skipped
  florian: I think it's not about screen readers
  florian: It's about audio rendering
  fantasai: Yes, but if we remove this, we need to make sure we're
            very clear in the spec, explicit wording to say this prop
            needs to affect non-visual things

  dbaron: I think if that was the intent of the spec, I suspect most
          implementors missed it
  dbaron: I think it would be good to have the wording in some other
  astearns: I think it would be an improvement to be explicit, rather
            than hide it here
  frremy: Most of these things, if they're defined, are in ARIA, they
          explicitly call out the properties and what you should do
          with them
  florian: For a11y, probably, for visual and non-visual media ....
           for the ones that say "all", a normative statement that
           says "this works on all media" is fine
  astearns: It should be more explicit
  astearns: "such as, screen readers"
  florian: No
  florian: They don't work like that
  florian: they're a visual media
  fantasai: But they're also not handling gencon properly
  Rossen: They do
  frremy: In Edge it works perfectly
  fantasai: But it is a common bug in implementations, to miss that

  frremy: The content thing is defined precisely in the ARIA specs
  frremy: I don't believe we need to say anything in the CSS specs
  frremy: It says gencon should be exposed
  frremy: but it shouldn't require any specific wording

  florian: I would suggest adding a sentence not a11y specific,
           calling out that this property is supposed to apply to all
           kinds of rendering, even not visual
  florian: not specifically to a11y, e.g. audio rendering without a
           screen reader, don't forget this property
  astearns: Would that be enough?
  dbaron: Sure

  fantasai: We should have these kinds of sentences anyway. In the
            propdef table it's easy to look up which ones you need to
            care about
  fantasai: but it takes up a lot of space
  fantasai: Removing from the propdef table is a benefit overall

  fantasai: We should add a statement explaining normatively that CSS
            requires these to work
  fantasai: It's our job, not ARIA's, to define what the properties
            mean and how they're interpreted. ARIA can then reference
            that to define more specifically how they affect a11y.

  RESOLVED: Add a normative statement for properties that say "Media:
            all" explaining what "Media: all" meant.
Received on Tuesday, 24 July 2018 23:10:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:11 UTC