- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 24 Jul 2018 19:09:14 -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.
=========================================
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
#2413)
- RESOLVED: Close this issue (Issue #2791: Is the `<mf-range>`
"swapping value and name" syntax really useful?) with no
change
===== FULL MINUTES BELOW ======
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?
Yes/No
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
black-on-white
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
contrast
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
panel]?
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
content
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
https://lists.w3.org/Archives/Public/www-archive/2018Jul/att-0007/mq.jpg
]
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 |
forced-dark
]
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
versa
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
contrast
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
them
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
you?
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
Edge
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
issue
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
weird...
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
content
<br type="afternoon-tea">
<myles> The proposal is two media queries:
prefers-contrast: none | high | high-forced | low | low-forced
and
prefers-brightness: none | light | dark | forced-dark |
forced-light | forced-something
<fantasai> alternately prefers-contrast: none | [ high | low ] ||
forced
<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
option
iank: and I think the bit of information that we give devs is on
navigator.connection.saveData
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
image
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
this
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
<mf-range>
----------
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
implement
emilio: It's not that I'd like not to, it's that it's somewhat
annoying
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
way
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