- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 24 Jul 2018 19:08:27 -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.
=========================================
CSS Values & Units
------------------
- RESOLVED: <color> in <shadow> should default to currentColor
(Issue #2766)
- RESOLVED: drop-shadow and shadow will also default to currentColor
(Issue #2766)
- RESOLVED: 1) All the positions serialize the same way
(background-position, object-position, etc.)
2) All of them resolve as <position>.
Background-position 3-value syntaxes are not allowed.
(Issue #2274)
- RESOLVED: All the <position> values serialize to at least two
values. (Issue #2274)
- There were two issues remaining to resolve for issue #2274
(Inconsistent position serialization):
1) How do we deal with keywords, both if the author supplies
them and do we turn 50% into center, and
2) The two-value vs 4-value question. Interested individuals
will discuss these items during breaks to seek a resolution.
Backgrounds 4
-------------
- RESOLVED: Add stripes() to border-color and outline-color (Issue
#2532)
Filters
-------
- dino gave an introduction to the proposal to create a color-filter
property (Issue #2875) which modifies the color values used when
rendering.
- This proposal was based on the success Apple has had introducing a
dark mode feature and would allow a dark mode to easily be set
up on websites or in emails.
- Generally people agreed the use case was valid and it's an
interesting but complex problem space to try and solve.
- If this is done there likely will need to also add a media query,
something like prefers-colors: light | dark | any
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sydney-2018#schedule
Present:
Rachel Andrew, Invited Expert
Rossen Atanassov, Microsoft
Tab Atkins, Google
L. David Baron, Mozilla
Brian Birtles, Mozilla
Tantek Çelik, Mozilla
Dave Cramer, Hachette Livre
Emil A Eklund, Google
Elika J Etemad, Invited Expert
Jihye Hong, LGE
Koji Ishii, Google
Dean Jackson, Apple
Ian Kilpatrick, Google
Chris Lilley, W3C
Peter Linss, Invited Expert
Myles C. Maxfield, Apple
Cameron McCormack, Mozilla
Xidorn Quan, Mozilla
Francois REMY, Microsoft
Florian Rivoal, Invited Expert
Hiroshi Sakakibara, BPS
Alan Stearns, Adobe
Shane Stephens, Google
Lea Verou, Invited Expert
Philip Walton, Google
Eric Willigers, Google
Scribe: myles
CSS Values & Units
==================
<color> in <shadow> should default to currentColor
--------------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/2766
* fantasai thought we'd fixed this already
fantasai: Any objections?
Rossen: We need to make sure the people who care have a chance to
look
xidorn: The issue is that if it isn’t specified, the used color is
taken from the current property
xidorn: I think the text should just be “it defaults to currentColor”
dbaron: The spec may have evolved from something that was more
flexible
chris: (sarcastically) Let’s say it’s user defined
Rossen: Are we okay with the proposed resolution?
Rossen: Any objections? <silence> resolved
RESOLVED: <color> in <shadow> should default to currentcolor
chris: There’s also the same problem with drop-shadow as well as
shadow
leaverou: It doesn’t work that way already?
Rossen: Any additional comments?
Rossen: <silence> Any objections?
RESOLVED: drop-shadow and shadow will also default to currentColor
<fantasai> fixed this already for text-shadow, not box-shadow,
is what happened
Inconsistent position serialization
-----------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/2274
ericwilligers: For one of the properties, the spec is explicit about
serialization, and that’s different from all the
other ones
ericwilligers: Another inconsistency is that all the browsers behave
differently from one another
ericwilligers: Suggestions?
leaverou: Don’t we have a principle that shorter serializations are
better?
TabAtkins: Yes
leaverou: If we follow that, 50% should not be introduced
leaverou: Does that mean if it was specified explicitly, it should
be introduced?
dbaron: There are cases where you do need it to be disambiguated.
center 10% and 10% center are different
dbaron: Someone should go through, figure out what the compatible
behavior is, figure out what the same behavior is, and
figure out what should actually happen. This table is rather
large for going through in the WG meeting
ericwilligers: The one that’s different from the others, is that a
mistake and they should all the consistent?
emilio: Yes
dbaron: Some of these things are very easy to write as a spec
editor, but we should be careful to stick them in when they
cause inconsistencies like this. Implementors should be
suspicious of them too, if they say to do something
different from everything else
emilio: Can we resolve on the special case being removed?
fantasai: All the cases should be the same
Rossen: Yes
ericwilligers: We should think about transform origin and background
position, because transform origin is 3D, and
background position accepts the 3 value grammar. So
“left 10% top”
fantasai: We’re trying to get rid of 3-value syntaxes for that reason
fantasai: We can resolve on 2 things: 1) all the serializations
should be the same, 2) we never serialize to the three
value serializations, unless one of the three values is
center, and 3)
ericwilligers: What about always serialize to a valid <position>
fantasai: background-position-specific syntaxes should not be allowed
in serialization
Rossen: Objections?
RESOLVED: 1) All the positions serialize the same way
(background-position,m object-position, etc.)
2) All of them resolve as <position>. Background-position
3-value syntax’s are not allowed.
fantasai: We have more questions. 1) Do we ever serialize to a
1-value syntax? Eric made an amazing chart of compat data.
Edge takes the shortest backwards-compatible serialization
principle very seriously, and when it can, drops down to a
single value. The other implementations will always have
at least 2 values
fantasai: Should we ask Edge to change? To match everyone else? Or
are one-value serializations actually good
TabAtkins: This decision applies to typed OM too.
fantasai: I think two-value syntax is more understandable to work
with. Because if you happen to land on 50% arbitrarily, it
would be awkward otherwise. And we have 3 implementations
this way. So, because of minimizing the amount of work, we
should standardize on 2-values
heycam: Is this a general principle? Like pairs of numbers that are
coordinates, they should always be serialized as two-values?
fantasai: I don’t think that’s valuable.
[some 2-axis value syntaxes use duplication for omitted values,
so it would be less useful to duplicate in the serialization ]
dbaron: One reason position is different is that it has a relatively
complicated set of rules, where you’re allowed to do X Y
order, or Y X order much of the time but not all of the
time, which makes it complicated to figure out which values
will round-trip correctly if you reduce it to just one
fantasai: A more important reason is the transform-origin syntax,
which becomes ambiguous if you only have one value
fantasai: You wouldn’t be able to consider position as a single
value without considering whether or not you have a Z
component. That creates a serialization of position cannot
be self-contained
fantasai: The proposal: <position> always serializes at least two
values
TabAtkins: I’m down with that
Rossen: It means some work for us, but ...
TabAtkins: It means some work for all of us because we’re
inconsistent
Rossen: Okay.
RESOLVED: All the <position> values serialize to at least two values.
heycam: Is there a way to tell for a given property whether or not
we have considered its serialization and what’s in the spec
is a considered decision?
fantasai: Not really
fantasai: In most cases, you follow the general principle of
“shortest most backwards-compatible serialization” and the
exceptions are where we will have to explicitly say
something. The spec says “it’s probably this” but you need
to check in case there’s some legacy something
heycam: I don’t like having to check
fantasai: Are you volunteering to do the checking?
heycam: No
heycam: We should reflect our discussions back in the spec so we
don’t have to check
ericwilligers: We may not be testing in all 4 browsers
heycam: So tests may serve this purpose?
fantasai: When we have a 4-value syntax, do you serialize it out to
4 values or do you compress it using calc to two values?
Rossen: I looked at this a year ago in the context of
object-position. Most of the testing I did cross browsers
suggested that almost all implementations attempt to
serialize down to calc for computed values on
getComputedStyle(), and were inconsistent as described in
this one for specified style serialization
emilio: I don’t think we synthesize calc in any case for computed
value serialization. If you specify it as calc(), and we
cannot simplify it, but I don’t think we should use calc to
shorten the result
ericwilligers: We’re just talking about serialization, not computed
value
emilio: It’s essentially the same thing
ericwilligers: Yeah
ericwilligers: We’re talking about specified values, not computed
styles
ericwilligers: Blink would never give you a keyword as a computed
value
Rossen: What are we thinking about in terms of 4 value serialization?
Rossen: Should we attempt to do 2 when possible?
plinss: Turning a non-calc into a calc seems weird
astearns: If we can simplify a 4-value into a 2 value without calc,
that makes sense, but if you have to use calc, then it’s
not a simplification
dbaron: I agree as well, though the principle that would say to use
calc() is the most compatible syntax principle, because
calc() got implemented in background-position background
before the 4-value syntax
dbaron: So for a while you were able to do the effects of the
4-value syntax with calc, without the real 4-value syntax.
But for now we shouldn’t do it because it’s less compatible
astearns: We went through this when we were deciding how to use
these values in basic shapes. What I thought we were doing
was coming up with general principles that would generally
be applied to other things than basic shapes. Basic shapes
prefers two values, if you can express it without calc, so
we may look to that as what we were trying to do years ago
fantasai: Eric, do you have the test you used for the 4-value syntax?
fantasai: Can you modify it from bottom right to top left to see if
the values get dropped, or if we keep the 4 value syntax
even in that case?
ericwilligers: It takes me a while to get results because I use
browser stack.
ericwilligers: If you tell me what you want to know, we can figure
it out
<astearns> <position> in basic shapes is paragraph 2 of
https://drafts.csswg.org/css-shapes/#basic-shape-serialization
<fantasai> top 10% left 20%
ericwilligers: With the suggestion that we go down do two unless it
introduces a calc, what effect would that be for
background-position?
Rossen: The minute you have top 10% and then center ..
ericwilligers: People were saying “we should never ever go to three”
ericwilligers: Right 10% top will go to 4
ericwilligers: 1 more question: right 10% top should serialize
differently from left 10% top???
fantasai: That was the question I wanted to ask. We should see what
the output is. If there is consensus, we tend to go with
that. So I think we should investigate this question a
little more over the break. And then go on to the issue of
whether to serialize out keywords when you put serialize
as a percentage
Rossen: But this is after the discussion in the morning?
fantasai: No, we can do it now
fantasai: Look at the 3rd table: 30px center. Some of the
serializations use 50%, some use the keyword center
fantasai: The table after that: 40px top, some use 0% and some use
the keyword top
fantasai: So the question is, do we resolve on outputting the
keyword when the percentage would work?
dbaron: The bulk of the boxes are the keyword except 3 of them
dbaron: That said, I don’t know if we should try to go through all
of this
fantasai: 2 questions: 1) How do we deal with keywords, both if the
author supplies them and do we turn 50% into center, and
2) the two-value vs 4-value question
fantasai: We can look into that over the break.
Rossen: This is where we are going to get a lot more calcs in
percentages
Rossen: Okay that’s everything for this for now.
Backgrounds 4
=============
Issues for listifying border-color
----------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/2532
leaverou: There’s a very detailed write up in the issue of
everything I’m going to say
leaverou: Do people remember the issues with listifying
border-color? A few meetings ago, we resolved to
listifying border-colors, because 1) Authors wanted
multiple borders, but primarily a11y needed borders that
are both white and black so that they are visible over any
background. So we listifying border-color with the goal of
listifying alt he border properties
leaverou: But when I actually tried to listifying border-color,
there were several issues.
leaverou: 1) Because of the way listified properties work, if the
lists are mismatched, the shorter lists are padded with
the last term, which means if you have a border-width of
10px, and say 3 border colors, then 10px becomes 10px,
10px, 10px, which gives you a width of 30px. So setting
border-color has the effect of tripling your border width.
Weird, and this is the first time
heycam: Wouldn’t this happen with any other listified properties?
leaverou: Others don’t stack. Backgrounds and animations are
independent. But border-width, they stack, they aren’t
independent.
tantek: Or you have to do weird math, which is worse.
leaverou: Other issue: based on how other properties were listified,
the property got almost the same syntax it already had,
but you could add more with commas. So, previously it
accepted 4 colors, you could have 1-4 colors, then commas,
then 1-4 colors, etc. This inverts the relative power of
white space and commas, which is not how authors think
leaverou: You can see an example in the issue
leaverou: It’s quite unexpected.
leaverou: For those reasons, fantasai and I were thinking of an
alternative way to do multiple border colors, because
there aren’t many use cases of multiple colors with
different styles. All use cases for multiple borders are
essentially cases for multiple colors on a solid border.
So we were thinking how can we have multiple colors on
existing borders. The idea is to define a function, we
called it stripes(), which lets people define a
1-dimensional image which is weird but we already have
0-dimensional images, and it can be used in border-color,
and it has to be 1-dimensional image because otherwise it
would be difficult to define how it works around
border-radius. To cover the most prominent use cases it
would include lengths and percentages, and would work with
fr values
<tantek> Lea's proposal looks like an improvement to me
leaverou: I have a list of the use cases we tried to cover in the
issue, and a table of what the different syntaxes would
look like. We also considered letting border-color accept
a sequence of color stops, but that’s not convenient,
because with borders, people usually wants stripes not
gradients, and it’s hard to make stripes with the gradient
syntax
fantasai: You don’t want absolute positions the way gradient stops
do them, but rather widths that stack
leaverou: We also considered using a new border-stripes property.
But it has weird affects. It combines with border-color in
a confusing way, because unless there are transparent
stripes, you don’t see border-color. In general, having
properties that disable other properties is some of the
most confusing parts of css
emilio: Firefox used to have multicolor border support, by using a
new property
leaverou: Yep, and it was confusing
chris: We decided not to do it the Firefox way
dbaron: It was a hack to create a certain button style without
making extra dives
leaverou: I used it 10 years ago to simulate box shadow
TabAtkins: I like it
astearns: What happens when the total sum of the width exceeds the
border width?
TabAtkins: You just only render the border-width of the stripes
leaverou: We can just scale it down. We do it with border-radius, if
the total radii overlap, then it gets scaled equally
across the entire box
astearns: That could work, but what about fractional widths? Those
go to 0? So you have a 2px white fractional black, 2px
white
TabAtkins: *describes another example*
fantasai: It’s better than clamping.
fantasai: It gives you reasonable behavior when you grow and when
you shrink
TabAtkins: We already have mechanisms (percentages) to do this.
TabAtkins: This allows you from putting in more stripes than you need
TabAtkins: So if you alternating 1px stripes, you just make a super
long one, and no matter how wide the border happens to
be, it will just work (in the clamping situation)
frremy: Animations work better too
leaverou: If you want to reveal stripes, you could always animate
them from 0
TabAtkins: Not if we scale the values
leaverou: Non-zero lengths will be scaled down, but if you want to
progressively animate,
TabAtkins: You can already achieve accordion effect
fantasai: What if you want 2px red, 2px white, 2px red. But if the
border grows, you want the white to grow
fantasai: When you scale up, you want red on the outside, you
preserve the red, white, red
TabAtkins: use min() and max() instead.
leaverou: What do we do if we want a thinner width than what we
have? In fantasai's example, what if our border is 10px
TabAtkins: We follow gradients. The last color continues
fantasai: Or the last implied color could be transparent
TabAtkins: But then the border doesn’t look thick
fantasai: If you want it to be thick, put 1fr at the end
TabAtkins: When this is used in a 2 dimensional context, then this
should be a gradient in some arbitrary direction
fantasai: I don’t think the testing and implementation effort of
making stripes in 2d only for an arbitrary direction makes
any sense
TabAtkins: Here we’re just talking about stretching and scaling
Rossen: What if we repeat the pattern?
leaverou: We can introduce that later. Let’s keep it simple.
fantasai: It answers the question of what to do if you don’t have
enough stripes
TabAtkins: Don’t be arbitrarily different. Do what gradients do
fantasai: No
TabAtkins: No
TabAtkins: Be consistent
fantasai: This isn’t gradients
TabAtkins: This is gradients
fantasai: This is stripes
leaverou: Gradient color stops are defined absolutely, and there is
no fr
Rossen: Stop. Are we trying to add this to backgrounds-4?
All: Yes
Rossen: We can work this out later
Rossen: Was there anything else you wanted to go over technically as
part of the proposal?
leaverou: No
Rossen: Should we add this? Are there still too many open issues for
it to be added?
TabAtkins: Using the stripes functions as a border color and not
listifying border color makes more sense than what we
already have
<tantek> agreed
fantasai: This is a better solution.
fantasai: My question: whether to use border-stripes or to add this
to border-color. In general, colors cannot take a 1d
image. Any property that ends in -color takes a color.
This is not a color, it accepts a 1d image
astearns: border-color-stripes?
fantasai: border-stripes is okay
leaverou: What about the confusing interactions?
fantasai: It's okay.
astearns: Some behaviors fall out of the description
astearns: e.g. might answer question of what to do when you run out
of stripes
frremy: That isn’t great because if you pad a border stripes with
the border color, the issue is that the border color by
default is non transparent, but your stripes may be
transparent, then should you display the border-color under
the stripes? If you do, you lose the whole point of having
transparent stripes
fantasai: You should show border underneath this property
leaverou: You often want them to stack, to have a fallback that you
don’t have to repeat it in your gradient
xidorn: I don’t understand the interaction here
[question about border-image]
fantasai: border-stripes and border-color both disappear when you
use border-image
chris: This will need some good examples
TabAtkins: Or we just do stripes() and we don’t have to deal with
this stuff
leaverou: Yep
fantasai: Yep
leaverou: If we do it with a stripes function and not a separate
property, we can extend this to other properties
fantasai: The other properties need a 0-dimensional color, or a
2-dimensional image. If you applied stripes to those other
places, you would need to also specify a direction and
turn it into a 2-d thing
leaverou: I said “if it’s needed” and it may not be needed
fantasai: We could re-use the syntax. It doesn’t have to be a
functional notation
leaverou: We would have to add a new property for each of those cases
fantasai: That’s okay
Rossen: Do we prefer the stripes functions? Or a new property
fantasai: border-stripe
TabAtkins: stripes function
<leaverou> stripes function
<tantek> stripes function
astearns: One reason to have the function is that we noted that
listifying properties is confusing. Stripes() makes
specifying these stripes more comprehensible. If we use a
property, we’re back to a list.
leaverou: Yes
Rossen: Another benefit is you can have the border color and the
stripes in the same definition, so you can have your border
color as defined green, but you can also define the stripes
on top that may or not have green
leaverou: So you can do them both in the same property
Rossen: Yes.
TabAtkins: Why do you need that?
Rossen: So you can have the last value be transparent, and the
default shows through
fantasai: The main benefit of the border-color being separate is so
that they can cascade independently. If they're not
cascading independently, then there’s no point
chris: The original reason for this was because a11y wanted to have
a black and a white outline, and outline is defined in term
of border. With this syntax, you say “black white” and you’re
done.
chris: Let’s not make a new property.
tantek: Is stripes just a subset of gradients?
<tantek> Is stripes a subset of gradients?
<leaverou> tantek: No, gradients are 2D images. Also, gradient color
stops define positions, not widths.
<TabAtkins> tantek, this needs a 1d "image", so that it can
automatically orient "inside"=>"outside" as you draw the
separate border edges.
<tantek> TabAtkins so it would be more work to set separate
gradients for each border side then?
<TabAtkins> tantek: It's *substantially* more work, yes, *and* it
doesn't work well with border-radius either.
Rossen: Proposal: adding stripes() to border-color and outline-color
Rossen: Any additional concerns? Comments that would change this
resolution, or objections?
florian: How does it interact with border-style: double
fantasai: You clip out the border shape.
Rossen: Just like it would work with gradients
leaverou: I think he’s asking about double borders, not dotted and
dashed.
chris: It’s a clip mask effectively.
leaverou: Double has two different colors, and inside and an outside
florian: nope, that’s something else
leaverou: You’re right
dbaron: We could say that inset outset groove and ridge would just
get treated as solid because you’re picking your colors
yourself now and that overrides those styles.
florian: You can use it as fallback.
leaverou: right!
leaverou: I like that
chris: yeah.
Rossen: Any objections?
RESOLVED: Add stripes() to border-color and outline-color
<xidorn> suspect people would want to use it in shadows,
text-decoration-color, caret-color, column-rule-color
<xidorn> eventually
<fantasai> xidorn, which axis are you striping for column-rule-color?
<fantasai> ditto shadows
<xidorn> fantasai, shadow is the same as border, which can go
outwards or inwards I think?
Publication
-----------
Rossen: Do we now publish a new working draft?
fantasai: I don’t know what state the rest of the draft is in,
not great though
leaverou: we’ve published a working draft before, right?
fantasai: nope
Rossen: This is level 4, right?
leaverou: yes, it needs lots of cleanup
Rossen: Let’s not publish
Filters
=======
Scribe: fantasai
color-filter
------------
Github: https://github.com/w3c/csswg-drafts/issues/2875
dino: Some background...
dino: Same way that Windows has done for decades, Apple's latest OS
has a “dark theme”
dino: Where user has a checkbox where they can choose between light
or dark mode
dino: You can see my browser is in dark mode atm
dino: System apps have implemented this
dino: Seems pretty popular
dino: This is about how you can apply something like that to the Web
dino: Particularly relevant to us for mail messages
dino: which are web pages
dino: What we wanted to do was automatically convert a page to dark
mode
dino: To do that, you want white to go to black, but you want hues
to stay the same
dino: e.g. blue shouldn't become orange
dino: We had the idea to use color-filter
dino: This takes filters just like 'filter'
dino: But doesn't have ability to move pixels
dino: It's a paint-time effect
chris: Is this a straight 255 minus effect?
dino: Yes
[dino shows off invert()]
dino: It's not like a regular filter. No stacking context. Just
applies to colors
dino: Colors of gradients, anywhere a <color> appears
dino: Doesn't affect images
dino: Because when you switch to dark theme, you don't want to have
images invert
dino: or emoji colors to invert etc.
dino: We don't actually want to just invert the colors
dino: Here's an example - invert(0.83) hue-rotate(180deg) saturate(3)
dino: White goes to dark gray, bump saturation to compensate for
grayishness, and then hue-rotate gets our colors back to what
they would be without inversion
dino: Works nicely. Better on my laptop than on the projector here.
dino: This other column does some additional tweaks using JS, to
look a little better.
dino: Anyway, this is what we're using to display mail messages now
dino: We have heuristics, if a marketing mail sets bgcolor, we won't
do it
dino: but for plaintext or simple HTML messages, we'll apply the
filter
dino: What we've got here is not Web-exposed, just in Mail
dino: We can talk more later about Media Queries and how to interact
with the Web
dino: But a Web page could e.g. change colors manually in response
to a media query, or they could use color-filter
dino: It's just maths on red/green/blue channels of the colors
dino: images are untouched
dino: No stacking context
dino: It's inherited, so you can undo it in a subtree
chris: Initial value?
dino: none
chris: You say not images, but some parts of CSS are <image>s...
dino: Gradients is a good example. If your background image is a
gradient, you apply it to the color stops
leaverou: What about custom properties that have been defined to
accept <color>?
fantasai: Gets applied when you apply the color to a CSS property?
TabAtkins: But you don't want to double-apply for typed variables
...
xidorn: Is it applied during cascading or what?
emilio: Computed value is not affected
fantasai: used-value time operation
astearns: currentColor
fantasai: probably fine
heycam: <canvas> ?
dino: Wouldn't apply to canvas
dino: Currently implemented not for Web, in apps like Mail etc.
dino: We think it makes sense for the Web
dino: As a way to help authors adjust page
leaverou: What about color modification functions?
TabAtkins: Amelia asked that already in the issue. I think having
both is useful
leaverou: Are there uses other than dark themes?
dino, chris: high-contrast
dino: One of the greatest benefits we've found, before this people
with vision issues that didn't like bright content would be
constantly swapping between inverted/non-inverted mode
dino: And that's a screen-time effect
dino: And then we had to un-invert the images to make that useful
for them
dino: And then also create all these stacking contexts, which
affects the page
dino: So this is pretty nice.
dino: So this might be a nice forced option
dino: That the user could apply, e.g. "I want to see this web site
dark"
leaverou: Does it also apply to colors in inline SVG?
dino: Yes
leaverou: Wouldn't this be ...
leaverou: You can have bitmaps inside an SVG
leaverou: Seems like it would interact badly
dino: Could have a UA rule that sets it back to none
dino: We've mostly experimented with Mail. Haven't tried to apply to
the Web yet
<dbaron> This seems like a reasonable feature, although I'm
skeptical about the readability of the mail in the use case
Dean described given the massive differences in perceived
luminance between the R, G, and B channels. (e.g., blue on
black is hard to read, as is green on white)
heycam: What if page wants to try handling it themselves?
dino: This is a complicated topic, wanted to deal later, but let's
talk about it now
dino: If the browser is being told to apply dark mode automatically,
what should we do?
dino: If there's a media query that allows the page to detect if the
user wants dark mode
dino: Should the browser automatically flip the page or not?
dino: It would be very odd for MQ to trigger behavior change
fantasai: We do have precedence
frremy: On Windows 8, if you resize an application to be in phone
mode, we would scale the website down, except if it used
@viewport
florian: That's not a media query. @viewport is *supposed* to have
an effect on the page
florian: Opera did that for projection media type.
<tantek> similarly with full screen
dbaron: Been done before, but not a good idea. Poor API
dino: API I think that would provide it is also bad
dino: It's <meta viewport>
...
florian: MS has an alternative to that, it's a property
florian: can say "for this subtree, I've done it"
emilio: Could say color-filter: none
florian: *If* the browser is doing this with color-filter and not
some other mechanism
dino: So you'd set that property on the body
fantasai: Can we use html, not body? *hates HTML's <body>
propagation*
heycam: Is this about high-contrast?
Rossen: Yes
dino: The only thing I don't like about that is it forces you to
resolve style before you decide what you've got to do
dino: meta tag doesn't have that problem
dino: but then can't exclude part of the page
Rossen: In practice, ppl tend to opt out on things like menus and ...
dino: So that's actually main reason we don't want to do it
automatically
dino: built-in form-controls look weird
dino: but ppl don't use built-in form controls that much, they use
bootstrap etc.
TabAtkins: Uhhh,, no???
TabAtkins: The whole point of using built-in form controls is that
they work properly on all platforms, e.g. apple watch
florian: We've discussed similar model for auto-adjustment of colors
for printing
florian: Where author might want the browser to not make changes to
the colors, because they already turned on colors and stuff
florian: “Browser has magic adjustments. I want to opt out on this
part of the page.”
dino: It worries me a bit that including any style sheet could
override this
florian: meta tag seems the wrong layer to do it
fantasai: That's true of viewport meta in general. Should be in
style sheet
dino: Suppose you include your favorite UI library. It supports dark
mode.
dino: Should it put "I support dark mode" property on the html?
frremy: No, you set the property on the elements in your framework.
Not on the whole page
dino: So bounding to a tree
florian: It's just a property. You *can* use it on <html>, but could
apply only to components.
<tantek> what about where web devs have matched color related values
with colors in images?
tantek: Did you talk about use case of matching colors in a JPEG?
dino: Could just set the filter to none
florian: Could use property to express two different things
florian: “Dear Browser, don't do it, because I've done it myself.”
vs “Dear Browser, don't do it, because here it's not
appropriate”
dino: So property is nice there, can say "Don't use on this color of
red, because it has to match the red of these shoes" but rest
of page is fine
heycam: Are we considering possibility of mechanisms other than
color-filter() being set to handle these cases?
heycam: Because if not, then maybe we don't need a separate filter
dino: So far color-filter has been enough for us, but we've only
been looking at mail
dino: Haven't tried browsing the web to see what happens on random
content
astearns: It's the exceptions I'm worried about
astearns: In mail, generally the background is set on the body
astearns: but on web pages could be arbitrary div
dino: We found a lot of messages that don't set a bgcolor
dino: but content sets bg white
dino: that's why we couldn't layer mail over a gray application
background
dino: had to put some smarts into analyzing the page
dino: If we can detect that the page wants a white background,
because it's set some things to white...
dino: But so far color-filter has been enough
dino: Good news is implementation is quite easy
dino: Just at the point of where you're asking for the color value
dino: It's great, makes it easy to be a render-time effect
dino: math is pretty easy
dino: can also cache the values
heycam: Some properties to control the color space that we
interpolate in
heycam: for animations and gradients
heycam: That would happen with original color values before
transforming them?
dino: Don't think there's case where you'd want to change colors
*and* change interpolation space
dino: No idea why red-blue gradient, why if you invert it you'd want
it to be in linear-rgb
dino: If you ask for gradient colors, you get filtered colors, and
then interpolate like gradient said to
dino: Of course could put property with a media query if you wanted
chris: So this modification happens last, just before rendering
dino: Right.
dino: Computed style is still the original color
dino: While we're talking about this, maybe talk about MQ
dino: Our current one that we use internally, is
prefers-dark-interface
dino: Think it's more prefers-dark-content
TabAtkins: prefers-dark
dino: Lines up with prefers-*
dino: User is requesting that they prefer this type of content
florian: I'm supportive of prefers-type MQs,
florian: Question is what is the other options?
florian: Can you express no preference in addition to expressing
preference for light?
...
dino: prefers-dark: light seems weird
fantasai: Just rename it to something else, e.g.
prefers-colors: light | dark | any
...
heycam: Say you have a site which is already dark, like
DaringFireball, and you turn on the browser option "Please
automatically make this dark for me"?
heycam: Are there options to keep it dark?
dino: I think we need to be careful to say that "Please make this
dark for me" can't be a universal hammer
dino: It's hard to tell
dino: E.g. we try with scrollbars, to try to guess whether page is
light or dark and make scrollbars match
dino: Because DaringFireball sets bgcolor which is neither white nor
back
dino: we probably wouldn't change anything
heycam: Is that a case where the author should indicate they already
support dark?
dino: Question is, does anyone want to force bright?
dino: If you set bgcolor to hot pink, might say that you support
dark and they'll get hot pink anyway
dino: Also for mail you'd get hot pink
dino: ...
florian: Do ppl anticipate forced-darkening of pages?
dino: There are a lot of users who seem to want that
dino: They've set up shortcuts to invert the page
dino: They toggle this on and off as they browse different pages
florian: If you have prefers-dark and forced-dark on at the same
time, what does that mean?
dino: ...
dino: If the page says 'I did dark mode' then we wouldn't force it
dbaron: Did some experiments with this sort of color inversion maybe
8-10 yrs ago
dbaron: One problem I ran into in the end, and dino's example with
mail was showing it, is that you can't actually do a good
job of preserving both saturation and lightness contrast at
the same time
dbaron: because the contributions of red green and blue channels to
luminance is very very different
dbaron: In the difference of white vs black, the luminance
perception of that is 70% green 23% red and 7% blue or
something like that
dbaron: which means that fully saturated blue is quite readable
against white, but unreadable against black
dbaron: and fully saturated green is quite readable against black
and unreadable against white
dino: Which is why my third column was there, it bumped dark blues
to lighter blues... blends a light-ish blue over every
color ...
astearns: I expect as your designer looks at more and more pages,
they would find additional tweaks they'd want to make to
the filter
astearns: I can see the usefulness for this feature for browser UI
astearns: as something you can toggle, and you can flip it back if
it isn't working
astearns: from a design perspective
astearns: I can't imagine someone wanting to tweak their colors with
such a blunt hammer
astearns: Create a light theme and a dark theme as a designer, never
going to be a filter that'll get you from one to the other
astearns: So from UA perspective I see the usefulness
astearns: but from author perspective I can't see the use case for
the color-filter property
<chris> for sRGB it is 21.26% red 71.52% green 7.22% blue
Rossen: Thank you for demos and explanations, and that's a wrap for
this issue.
Received on Tuesday, 24 July 2018 23:09:29 UTC