IRC log of css on 2018-07-03

Timestamps are in UTC.

23:10:54 [RRSAgent]
RRSAgent has joined #css
23:10:54 [RRSAgent]
logging to https://www.w3.org/2018/07/03-css-irc
23:10:56 [trackbot]
RRSAgent, make logs public
23:10:56 [Zakim]
Zakim has joined #css
23:10:58 [trackbot]
Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
23:10:58 [trackbot]
Date: 03 July 2018
23:11:19 [astearns]
rrsagent, this meeting spans midnight
23:13:56 [heycam]
heycam has joined #css
23:17:15 [myles]
myles has joined #css
23:17:19 [myles]
Present+
23:18:37 [skk]
present+
23:19:00 [ericwilligers]
ericwilligers has joined #css
23:19:00 [fantasai]
present+
23:19:01 [TabAtkins]
present+
23:19:02 [Rossen]
present+
23:19:03 [heycam]
present+
23:19:03 [xidorn]
present+
23:19:03 [leaverou]
present+
23:19:04 [philipwalton]
present+
23:19:04 [astearns]
present+
23:19:04 [eae]
present+
23:19:05 [ericwilligers]
present+
23:19:09 [dino]
dino has joined #css
23:19:15 [dino]
present+
23:19:20 [dbaron]
present+
23:19:29 [myles]
Topic: <color> in <shadow> should default to currentColor
23:19:39 [plinss]
present+
23:19:52 [myles]
Github: https://github.com/w3c/csswg-drafts/issues/2766
23:19:53 [chris]
chris has joined #css
23:20:02 [chris]
present+
23:20:08 [myles]
Fantasai: any objections?
23:20:25 [chris]
rrsagent, here
23:20:25 [RRSAgent]
See https://www.w3.org/2018/07/03-css-irc#T23-20-25
23:20:31 [myles]
Rossen: We need to make sure the people who care have a chance to look
23:20:51 [myles]
xidorn: the issue is that if it isn’t specify, the used color is taken from the current property
23:21:04 [myles]
xidorn: I think the text should just be “it defaults to currentColor”
23:21:18 [myles]
dbaron: the spec may have evolved from something that was more flexible
23:21:41 [myles]
chris: let’s say it’s user defined
23:21:52 [myles]
Rossen: are we okay with the proposed resolution?
23:22:00 [myles]
Rossen: any objections? <silence> resolved
23:22:03 [chris]
s/let/(sarcastically) let/
23:22:08 [myles]
RESOLVED: Accept the proposal
23:22:24 [frremy]
frremy has joined #css
23:22:36 [Rossen]
s/Accept the proposal/<color> in <shadow> should default to currentcolor
23:22:58 [myles]
chris: There’s also the same problem with drop-shadow as well as shadow
23:23:13 [myles]
leaverou: it doesn’t work that way already?
23:23:23 [myles]
Rossen: any additional comments?
23:23:37 [myles]
Rossen: <silence> Any objections?
23:23:52 [myles]
RESOLVED: drop-shadow and shadow will also default to currentColor
23:24:22 [myles]
Topic: Inconsistent position serialization
23:24:30 [myles]
Github: https://github.com/w3c/csswg-drafts/issues/2274
23:24:54 [myles]
ericwilligers: For one of the properties, the spec is explicit about serialization, and that’s different from all the other ones
23:25:06 [myles]
ericwilligers: another inconsistency is that all the browsers behave differently from one another
23:25:29 [myles]
ericwilligers: suggestions?
23:25:40 [myles]
leaverou: don’t we have a principle that shorter serializations are better?
23:25:42 [myles]
TabAtkins: yes
23:25:49 [myles]
leaverou: if we follow that, 50% should not be introduced
23:26:00 [myles]
leaverou: do that mean if it was specified explicitly, it should be introduced?
23:26:20 [myles]
dbaron: there are cases where you do need it to be disambiguated. center 10% and 10% center are different
23:26:40 [myles]
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
23:26:52 [myles]
ericwilligers: the one that’s different from the others, is that a mistake and they should all the consistent?
23:27:02 [myles]
emilio: yes
23:27:48 [myles]
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
23:28:00 [myles]
emilio: Can we resolve on the special case being outside?
23:28:08 [myles]
fantasai: All the cases should be the same
23:28:10 [emilio]
s/outside/removed
23:28:12 [myles]
Rossen: yes
23:28:37 [myles]
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”
23:28:44 [myles]
fantasai: we’re trying to get rid of 3 values
23:29:19 [myles]
fantasai: we can resolve on 2 things: 1) all the serializsations should be the same, 2) we never serialize to the three value serializations, unless one of the three values is center, and 3)
23:29:57 [myles]
ericwilligers: What about always serialize to a valid <position>
23:30:13 [myles]
fantasai: bgposition should not be allowed in serialization
23:30:17 [myles]
Rossen: objections?
23:31:21 [myles]
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.
23:32:02 [myles]
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
23:32:07 [myles]
Rossen: yeeeeeup
23:32:25 [myles]
fantasai: Should we ask Edge to change? To match everyone else? Or are one-value serializations actually good
23:32:31 [myles]
TabAtkins: This decision applies to typed OM too.
23:33:12 [myles]
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
23:33:57 [myles]
heycam: Is this a general principle? Like pairs of numbers that are coordinates, they should always be serialized as two-values?
23:34:01 [myles]
fantasai: I don’t think that’s valuable
23:34:24 [Rossen]
s/Rossen: yeeeeeup//
23:34:39 [myles]
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
23:34:54 [myles]
fantasai: a more important reason is the transform-origin syntax, which becomes ambiguous if you only have one value
23:35:33 [myles]
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
23:35:52 [myles]
fantasai: The proposal: <position> always serializes at least two values
23:35:58 [myles]
TabAtkins: I’m down with that
23:36:08 [myles]
Rossen: It means some work for us, but ...
23:36:16 [myles]
TabAtkins: It means some work for all of us because we’re inconsistent
23:36:24 [myles]
Rossen: okay.
23:37:04 [myles]
RESOLVED: All the <position> values serialize to at least two values.
23:37:26 [myles]
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?
23:37:29 [myles]
fantasai: not really
23:38:01 [myles]
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
23:38:08 [myles]
heycam: I don’t like having to check
23:38:13 [myles]
fantasai: Are you volunteering to do the checking?
23:38:16 [myles]
heycam: No
23:38:29 [myles]
heycam: We should reflect our discussions back in the spec so we don’t have to check
23:38:42 [myles]
ericwilligers: We may not be testing in all 4 browsers
23:38:52 [myles]
heycam: So tests may serve this purpose?
23:39:17 [myles]
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
23:40:00 [myles]
Rossen: I looked at this a year ago int he 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 style serialization
23:40:36 [myles]
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 dont’ think we should use calc to shorten the result
23:40:45 [myles]
ericwilligers: We’re just talking about serialization, not computed value
23:40:51 [myles]
emilio: It’s essentially the same thing
23:40:54 [myles]
fantasai: yeah
23:41:03 [myles]
fantasai: We’re talking about specified values, not computed styles
23:41:10 [myles]
ericwilligers: Blink would never give you a keyword as a computed value
23:41:20 [fantasai]
s/fantasai/ericwilligers/
23:41:37 [myles]
Rossen: What are we thinkging about in terms of 4 value serialization?
23:41:44 [myles]
Rossen: Should we attempt to do 2 when possible?
23:41:55 [myles]
plinss: Turning a non-calc into a calc seems weird
23:42:24 [myles]
astearns: Ifwe 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
23:42:46 [myles]
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 to the 4-value syntax
23:43:11 [myles]
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
23:43:56 [myles]
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
23:44:04 [myles]
fantasai: Eric, do you have the test you used for the 4-value syntax?
23:44:35 [myles]
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
23:44:45 [myles]
ericwilligers: It takes me a while to get results because I use browser stack.
23:44:54 [myles]
ericwilligers: If you tell me what you want to know, we can figure it out
23:44:55 [astearns]
<position> in basic shapes is paragraph 2 of https://drafts.csswg.org/css-shapes/#basic-shape-serialization
23:45:03 [fantasai]
top 10% left 20%
23:45:31 [myles]
ericwilligers: With the suggestion that we go down do two unless it introduces a calc, what effect would that be fore background-position?
23:45:47 [myles]
Rossen: The minute you have top 10% and then center ..
23:45:55 [myles]
ericwilligers: Peopel were saying “we should never ever go to three”
23:46:04 [myles]
ericwilligers: right 10% top wil go to 4
23:46:33 [myles]
ericwilligers: 1 more question: right 10% top should serialize differently from left 10% top???
23:47:06 [myles]
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
23:47:12 [myles]
Rossen: but this is after the discussion int eh morning?
23:47:16 [myles]
fantasai: no, we can do it now
23:47:32 [Rossen]
s/int eh/in the/
23:47:36 [myles]
fantasai: Looka t the 3rd table: 30px center. Some of the serializations use 50%, some use the keyword center
23:47:48 [myles]
fantasai: The table after that: 40px top, some use 0% and some use the keyword top
23:48:03 [myles]
fantasai: So the question is, do we resolve on outputting the keyword when the percentage would work?
23:48:24 [myles]
dbaron: The bulk of the boxes are they keyword except 3 of them
23:48:42 [myles]
dbaron: That said, I don’t know if we should try to go through all of this
23:49:15 [myles]
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
23:49:26 [myles]
fantasai: We can look into that over the break.
23:49:51 [myles]
Rossen: This is where we are going to get a lot more calcs in percentages
23:49:59 [myles]
Rossen: okay that’s everything for this for now
23:50:14 [myles]
Topic: Issues for listifying border-color
23:50:26 [myles]
Github: https://github.com/w3c/csswg-drafts/issues/2532
23:51:46 [myles]
leaverou: There’s a very detailed write up in the issue of everything I’m going to say
23:53:15 [myles]
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
23:53:38 [myles]
leaverou: BUt when I actually tried to listifying border-color, there were several issues.
23:54:25 [myles]
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
23:54:34 [myles]
heycam: Wouldn’t this happen with any other listified properties?
23:54:50 [myles]
leaverou: Others don’t stack. Backgrounds and animations are independent. But border-width, they stack, they aren’t independent.
23:55:05 [myles]
tantek: Or you have to do weird math, which is worse.
23:55:54 [myles]
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
23:56:02 [myles]
leaverou: You can see an example in the issue
23:56:08 [myles]
leaverou: It’s quite unexpected.
23:57:54 [myles]
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
23:57:54 [myles]
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
23:58:09 [tantek]
Lea's proposal looks like an improvement to me
23:58:48 [myles]
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
23:58:55 [myles]
fantasai: You don’t want absolute positions
23:59:32 [fantasai]
s/positions the way gradient stops do them, but rather widths that stack/
23:59:42 [myles]
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 dont’ see border-color. In general, having properties that disable other properties is some fo the most confusing parts of css
23:59:54 [myles]
emilio: Firefox used to have multicolor border support, by using a new property
23:59:59 [myles]
leaverou: Yep, and it was confusing
00:00:08 [myles]
chris: We decided not to do it the Firefox way
00:00:20 [myles]
dbaron: It was a hack to create a certain button style without making extra dives
00:00:28 [myles]
leaverou: I used it 10 years ago to simulate box shadow
00:00:30 [myles]
TabAtkins: I like it
00:00:48 [myles]
astearns: What happens when the total sum of the width exceeds the border width?
00:00:58 [myles]
TabAtkins: You just only render the border-width of the stripes
00:01:19 [myles]
leaverou: We can just scale it down. We do it with border-radius, if the total radii overlap, then it gets clamped
00:01:40 [myles]
S/clamped/scaled equally across the entire box/
00:02:05 [myles]
astearns: That could work, but what about fractional widths? Those go to 0? So you have a 2px white fractional black, 2px white
00:02:24 [myles]
TabAtkins: *describes another example*
00:02:30 [myles]
fantasai: It’s better than clamping.
00:02:48 [myles]
fantasai: It gives you reasonable behavior when you grow and when you shrink
00:03:00 [myles]
TabAtkins: We already have mechanisms (percentages) to do this.
00:03:26 [myles]
TabAtkins: This allows you from putting in more stripes than you need
00:03:52 [myles]
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)
00:04:09 [myles]
frremy: Animations work better too
00:04:22 [myles]
leaverou: If you want to reveal stripes, you could always animate them from 0
00:04:30 [myles]
TabAtkins: Not if we scale the values
00:04:47 [myles]
leaverou: Non-zero lengths will be scaled down, but if you want to progressively animate,
00:04:56 [myles]
TabAtkins: You can alreadya chive accordian effect
00:05:14 [myles]
fantasai: What if you want 2px red, 2px white, 2px red. If the border grows, you want the white to grow
00:05:32 [astearns]
s/alreadya chive/already achieve/
00:05:33 [myles]
fantasai: When you scale up, you want red on the outside, you preserve the red, white, red
00:05:39 [myles]
TabAtkins: use min() and max() instead.
00:05:58 [myles]
leaverou: What do we do if we want a thinner width than what we have? In fantasai, what if our border is 10px
00:06:05 [myles]
TabAtkins: We follow gradients. The last color continues
00:06:11 [myles]
fantasai: Or the last color could be transparent
00:06:17 [myles]
TabAtkins: But then the border doesn’t look thick
00:06:26 [myles]
fantasai: If you want it to be thick, put 1fr at the end
00:06:45 [myles]
TabAtkins: When this is used in a 2 dimensional context, then this should be a gradient in some arbitrary direction
00:07:10 [myles]
fantasai: I don’t think he testing and implementation effort of making stripes in 2d only for an arbitrary direction makes any sense
00:07:16 [myles]
TabAtkins: Here we’re just talking about stretching and scaling
00:07:20 [myles]
Rossen: What if we repeat the pattern?
00:07:26 [myles]
leaverou: We can introduce that later. Let’s keep it simple.
00:07:35 [myles]
fantasai: It answers the question of what to do if you dont’ have enough stripes
00:07:48 [myles]
TabAtkins: Don’t be arbitrarily different. Do what gradients do
00:07:53 [myles]
fantasai: no
00:07:56 [myles]
TabAtkins: no
00:08:03 [myles]
TabAtkins: be consistent
00:08:10 [myles]
fantasai: this isn’t gradients
00:08:16 [myles]
TabAtkins: this is gradients
00:08:20 [myles]
fantasai: this is stripes
00:08:32 [myles]
leaverou: Gradient color stops are defined absolutely, and there is no fr
00:08:51 [myles]
Rossen: stop. Are we trying to add this to backgrounds-4?
00:08:52 [myles]
All: yes
00:08:57 [myles]
Rossen: We can work this out later
00:09:18 [myles]
Rossen: Was there anything else you wanted to go over technically as part of the proposal?
00:09:22 [myles]
leaverou: no
00:09:34 [myles]
Rossen: Should we add this? Are there still too many open issues for it to be added?
00:09:47 [myles]
TabAtkins: Using the stripes functions as a border color and not listifying border color makes more sense than what we already have
00:10:12 [tantek]
agreed
00:10:20 [myles]
fantasai: This is a better solution. 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
00:10:25 [myles]
astearns: border-color-stripes?
00:10:30 [myles]
fantasai: border-stripes is okay
00:10:36 [myles]
leaverou: What about the confusing interactions?
00:10:40 [myles]
fantasai: its okay.
00:10:50 [myles]
astearns: The behaviors fall out of the description
00:11:11 [fantasai]
s/The/Some/
00:11:25 [fantasai]
astearns: e.g. might answer question of what to do when you run out of stripes
00:12:14 [myles]
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
00:12:21 [myles]
fantasai: You should show border underneath this property
00:12:40 [myles]
leaverou: You often want them to stack, to have a fallback that you don’t have to repeat it in your gradient
00:12:57 [myles]
xidorn: I dont’ understand the integration here
00:13:11 [myles]
fantasai: border stripes and border color will disappear when you use border-image
00:13:17 [myles]
chris: This will need some good examples
00:13:29 [myles]
TabAtkins: Or we just do stripes() and we don’t have to deal with this stuff
00:13:32 [myles]
leaverou: yep
00:13:35 [myles]
fantasai: yep
00:13:47 [myles]
leaverou: If we do it with a stripes function and not a separate property, we can extend this to other properties
00:14:09 [myles]
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
00:14:16 [myles]
leaverou: i said “if it’s needed” and it may not be needed
00:14:28 [myles]
fantasai: We could re-use the syntax. It doesn’t have to be a functional notation
00:14:37 [myles]
leaverou: We would have to add a new property for each of those cases
00:14:39 [myles]
fantasai: That’s okay
00:14:50 [myles]
Rossen: Do we prefer the stripes functions? Or a new property
00:15:01 [myles]
fantasai: border-stripe
00:15:06 [myles]
TabAtkins: stripes function
00:15:10 [leaverou]
stripes function
00:15:16 [tantek]
stripes function
00:15:36 [myles]
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.
00:15:38 [myles]
leaverou: yes
00:15:54 [tantek]
s/all a/allow a
00:16:05 [myles]
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
00:16:14 [myles]
leaverou: So you can do them both in the same property
00:16:17 [myles]
Rossen: Yes.
00:16:20 [myles]
TabAtkins: Why do you need that?
00:16:33 [myles]
Rossen: So you can have the last value be transparent, and the default shows through
00:16:42 [tantek]
Is stripes a subset of gradients?
00:16:55 [myles]
fantasai: The main benefit of the border color being separate is so that they can cascade independently. If theyr’e not cascading independently, then there’s no point
00:17:23 [myles]
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.
00:17:29 [myles]
chris: Let’s not make a new property.
00:18:11 [myles]
tantek: Is stripes just a subset of gradients?
00:18:12 [leaverou]
tantek: No, gradients are 2D images. Also, gradient color stops define positions, not widths.
00:18:26 [myles]
Rossen: Proposal: adding stripes() to border-color and outline-color
00:18:39 [myles]
Rossen: Any additional concerns? Comments that would change this resolution, or objections?
00:18:48 [myles]
florian: How does it interact with border-style: double
00:18:54 [myles]
fantasai: You clip out the border shape.
00:19:04 [myles]
Rossen: Just like it would work with gradients
00:19:14 [myles]
leaverou: I think he’s asking about double borders ,not dotted and dashed.
00:19:21 [myles]
chris: It’s a clip mask effectively.
00:19:39 [myles]
leaverou: Double has two different colors, and inside and an outside
00:19:48 [myles]
florian: nope, that’s something else
00:19:51 [myles]
leaverou: You’re right
00:20:26 [myles]
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.
00:20:34 [myles]
florian: You can use it as fallback.
00:20:37 [myles]
leaverou: right!
00:20:41 [myles]
leaverou: I like that
00:20:43 [myles]
chris: yeah.
00:20:50 [myles]
Rossen: Any objections?
00:21:02 [myles]
RESOLVED: Add stripes() to border-color and outline-color
00:21:18 [TabAtkins]
tantek: It's *substantially* more work, yes, *and* it doesn't work well with border-radius either.
00:21:20 [myles]
Rossen: Do we now publish a new working draft?
00:21:29 [myles]
fantasai: I don’t know what state the rest of the draft is in
00:21:39 [myles]
leaverou: we’ve published a working draft before, right?
00:21:43 [myles]
fantasai: nope
00:21:46 [TabAtkins]
(You can't supply separate images for each border, just a single border-image that's 9-sliced to supply all the border regions.)
00:21:50 [myles]
Rossen: This is level 4, right?
00:21:58 [myles]
leaverou: yes, that needs lots of cleanup
00:21:59 [TabAtkins]
And yeah, probably so, which is fine with em.
00:22:05 [myles]
Rossen: Let’s not publish
00:22:18 [TabAtkins]
Just "gradient(...)"
00:22:22 [myles]
Topic: color-filter
00:22:36 [myles]
Github: https://github.com/w3c/csswg-drafts/issues/2875
00:23:05 [fantasai]
Topic: color-filter
00:34:07 [myles]
myles has joined #css
00:49:01 [fantasai]
github: https://github.com/w3c/csswg-drafts/issues/2875
00:49:07 [shane]
Restaurant tonight is Long Chim
00:49:15 [myles]
myles has joined #css
00:49:18 [fantasai]
dino: Some background...
00:49:25 [fantasai]
ScribeNick: fantasai
00:49:33 [shane]
address for Long Chim: Corner of Pitt Street &, Angel Pl, Sydney NSW 2000
00:50:19 [fantasai]
dino: Same way that Windows has done for decades, Apple's latest OS has a “dark theme”
00:50:29 [fantasai]
dino: Where user has a checkbox where they can choose between light or dark mode
00:50:34 [fantasai]
dino: You can see my browser is in dark mode atm
00:50:44 [fantasai]
dino: System apps have implemented this
00:50:47 [fantasai]
dino: Seems pretty popular
00:50:55 [fantasai]
dino: This is about how you can apply something like that to the Web
00:51:08 [fantasai]
dino: Particularly relevant to us for mail messages
00:51:11 [fantasai]
dino: which are web pages
00:51:20 [fantasai]
dino: What we wnated to do was automatically ocnvert a page to dark mode
00:51:30 [fantasai]
dino: To do that, you want white to go to black, but you want hues to stay the same
00:51:34 [fantasai]
dino: e.g. blue shouldn't become orange
00:51:39 [fantasai]
dino: We had the idea to use color-filter
00:51:47 [fantasai]
dino: This takes filters just like 'filter'
00:51:53 [fantasai]
dino: But doesn't have ability to omove pixels
00:52:04 [fantasai]
dino: It's a paint-time effect
00:52:18 [fantasai]
chris: Is this a straight 255 minus effect?
00:52:19 [fantasai]
dino: Yes
00:52:34 [fantasai]
dino shows off invert()
00:52:46 [fantasai]
dino: It's not like a regular filter. No stacking context. Just applies to colors
00:52:57 [fantasai]
dino: colors of gradients, anywhere a <color> appears
00:53:03 [fantasai]
dino: DOesn't affect images
00:53:30 [fantasai]
dino: Because when you switch to dark theme, you don't want to have images invert
00:53:37 [fantasai]
dino: or emoji colors to invert
00:53:39 [fantasai]
etc.
00:53:48 [fantasai]
dino: We don't actually wantto just invert the colors
00:54:09 [fantasai]
dino: Here's an example - invert(0.83) hue-rotate(180deg) saturate(3)
00:54:40 [fantasai]
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
00:54:58 [fantasai]
dino: Works nicely. Better on my laptop than on the projector here.
00:55:46 [fantasai]
dino: This other column does some additional tweaks using JS, to look a little better.
00:56:01 [fantasai]
dino: Anyway, this is what we're using to display mail messages now
00:56:21 [fantasai]
dino: We have heuristics, if a marketing mail sets bgcolor, we won't do it
00:56:35 [fantasai]
dino: but for plaintext or simple HTML messages, we'll apply the filter
00:56:43 [fantasai]
dino: What we've got here is not Web-exposed, just in Mail
00:57:03 [fantasai]
dino: We can talk more later about Media Queries and how to interact with the Web
00:57:30 [fantasai]
dino: But a Web page could e.g. change colors manually in response to a media query, or they could use color-filter
00:57:39 [fantasai]
dino: It's just maths on red/green/blue channels of the colors
00:57:43 [fantasai]
dino: images are untouched
00:57:49 [fantasai]
dino: No stacking context
00:57:57 [fantasai]
dino: It's inherited, so you can undo it in a subtree
00:58:12 [fantasai]
chris: Initial value?
00:58:13 [fantasai]
dino: none
00:58:24 [fantasai]
chris: You say not images, but some parts of CSS are <image>s...
00:59:04 [fantasai]
dino: Gradients is a good example. If your bgimage is a gradient, you apply it to the coors in the image
00:59:12 [fantasai]
leaverou: What about color variables?
00:59:19 [fantasai]
fantasai: Gets applied when you apply the color
00:59:28 [fantasai]
TabAtkins: But you don't want to double-apply for typed variables
00:59:29 [fantasai]
...
00:59:35 [leaverou]
s/What about color variables?/What about custom properties that have been defined to accept <color>?/
00:59:38 [fantasai]
xidorn: Is it applied during cascading or what?
00:59:42 [fantasai]
emilio: Computed value is not affected
00:59:48 [fantasai]
fantasai: used-value time operation
01:00:28 [fantasai]
astearns: currentColor
01:00:30 [fantasai]
fantasai: probalby fine
01:00:37 [fantasai]
heycam: <canvas> ?
01:00:55 [fantasai]
dino: Woudln't apply to canvas
01:01:07 [fantasai]
dino: Currently implemented not for Web, in apps ike Mail etc.
01:01:13 [fantasai]
dino: We think it makes sense for the Web
01:01:24 [fantasai]
dino: as a way to help authors adjust page
01:01:35 [fantasai]
leaverou: What about color modification functions?
01:01:46 [fantasai]
TabAtkins: Amelia asked that already in the issue. I think having both is useful
01:01:52 [fantasai]
leaverou: Are there uses other than dark themes?
01:01:59 [fantasai]
dino, chris: high-contrast
01:02:23 [fantasai]
dino: One of the greatest benefits we've found, before this people with vision issue sthat didn't like bright content would be constantly swapping between inverted/non-inverted mode
01:02:28 [fantasai]
dino: And that's a screen-time effect
01:02:38 [fantasai]
dino: And then we had to uninvert the images to make that useful for them
01:02:46 [fantasai]
dino: And then also create all these stackign contexts, which aaffects the page
01:02:50 [fantasai]
dino: So this is pretty nice.
01:02:55 [fantasai]
dino: So this might be a nice forced option
01:03:09 [fantasai]
dino: That the user could apply, e.g. "I want to see this web site dark"
01:03:20 [fantasai]
leaverou: Does it also apply to colors in inline SVG?
01:03:24 [fantasai]
dino: Yes
01:03:34 [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)
01:03:40 [fantasai]
leaverou: Woudn't this be ...
01:03:51 [fantasai]
leaverou: You can have bitmaps inside an SVG
01:03:57 [fantasai]
leaverou: Seems like it would interact badly
01:04:04 [fantasai]
dino: Could have a UA rule that sets it back to none
01:04:15 [fantasai]
dino: We've mostly experimented with Mail. Haven't tried to apply to the Web yet
01:04:39 [fantasai]
heycam: What if page wants to try handling it themselves?
01:04:54 [fantasai]
dino: This is a complicated topic, wanted to deal later, but let's talk about it now
01:05:13 [fantasai]
dino: If the browser is being told to apply dark mode automatically, what should we do?
01:05:24 [fantasai]
dino: If there's a media query that allows the page to detect if the user wants dark mod
01:05:30 [fantasai]
dino: Should the browser automatically flip th epage or not?
01:05:55 [fantasai]
dino: It would be very odd for MQ to trigger behavior change
01:05:59 [fantasai]
fantasai: We do have precedence
01:06:22 [fantasai]
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
01:06:38 [fantasai]
florian: That's not a media query. @viewport is *supposed* to have an effect on the page
01:06:53 [fantasai]
florian: Opera did that for projection media type.
01:06:57 [tantek]
similarly with full screen
01:07:08 [fantasai]
dbaron: Been done before, but not a good idea. Poor API
01:07:18 [fantasai]
dino: API I think that would provide it is also bad
01:07:24 [fantasai]
dino: it's <meta viewport>
01:07:31 [fantasai]
...
01:07:38 [fantasai]
florian: MS has an alternative to that, it's a property
01:07:50 [fantasai]
florian: can say "for this subtree, I've done it"
01:07:56 [fantasai]
emilio: Could say color-filter: noe
01:08:10 [fantasai]
florian: *If* the browser is doing this with color-filter and not some other mechanism
01:08:27 [fantasai]
dino: So you'd set that property on the body
01:08:39 [fantasai]
fantasai: Can we use html , not body?
01:08:48 [fantasai]
heycam: Is this about high-contrast?
01:08:50 [fantasai]
Rossen: yes
01:09:06 [fantasai]
dino: The only thing I dn't like about that is it forces you to resolve style before you decide whta you've got to do
01:09:14 [fantasai]
dino: meta tag doesn't have that problem
01:09:20 [fantasai]
dino: but then can't exclude part of the page
01:09:30 [fantasai]
Rossen: In practice, ppl tend to opt out of things like menus and ...
01:09:45 [fantasai]
dino: So that's actually main reason we don't want to do it automatically
01:09:49 [tantek]
what about where web devs have matched color related values with colors in images?
01:09:56 [fantasai]
dino: form-controls look weird
01:10:00 [fantasai]
s/form/built-in form/
01:10:22 [fantasai]
dino: but ppl don't use built-in form controls that much, they use boostrap etc.
01:10:27 [tantek]
Tab: WAT
01:10:36 [fantasai]
TabAtkins: Uhhh,, no???
01:10:51 [fantasai]
TabAtkins: The whole point is that built-in form controls work properly on.e.g. apple watch
01:11:15 [fantasai]
florian: We've discussed similar model for auto-adjustment of colors for printing
01:11:36 [fantasai]
florian: Where authro might want the browser to not make changes to the colors, because they already turned on colors and stuff
01:11:58 [fantasai]
florian: “Browser has magic adjustments. I want to opt out on this part of the page.”
01:12:16 [fantasai]
dino: It worries me a bit that including any style sheet could override this
01:12:38 [fantasai]
florian: meta tag seems the wrong layer to do it
01:12:48 [fantasai]
fantasai: That's true of viewport meta in general. SHould be in style sheet
01:12:58 [fantasai]
dino: Suppose you include your favorite UI library. It supports dark mode.
01:13:09 [fantasai]
dino: Should it put "I support dark mode" property on the html?
01:13:25 [fantasai]
frremy: No, you set the property on the elements in your framework. Not on the whole page
01:13:30 [fantasai]
dino: So bounding to a tree
01:13:54 [fantasai]
florian: It's just a property. You *can* use it on <html>, but could apply only to components.
01:14:29 [fantasai]
tantek: Did you talk about use case of matching colors in a JPEG?
01:14:38 [fantasai]
dino: Could just set the filter to none
01:14:44 [fantasai]
florian: Could use property to express two different things
01:15:05 [fantasai]
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”
01:15:27 [fantasai]
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
01:15:51 [dino]
dino has joined #css
01:15:57 [fantasai]
heycam: Are we considering possibility of meechanisms other than color-filter() being set to handle these cases?
01:16:09 [fantasai]
heycam: Because if not, then maybe we don't need a separate filter
01:16:32 [fantasai]
dino: So far color-filter has been enough for us, but we've only been looking at mail
01:16:44 [fantasai]
dino: Haven't tried browsing the web to see what happens on random content
01:16:52 [fantasai]
astearns: It's the exceptions I'm worried about
01:17:00 [fantasai]
astearns: In mail, generally the bg is set on the canvas
01:17:09 [fantasai]
astearns: but on web pages could be arbitrary div
01:17:17 [fantasai]
dino: We found a lot of messages that don't set a bgcolor
01:17:22 [astearns]
s/canvas/body/
01:17:23 [fantasai]
dino: but content sets bg the white
01:17:44 [fantasai]
dino: that's why we couldn't layer mail over a gray application background
01:17:55 [fantasai]
dino: had to put some smarts into analyzing the page
01:18:12 [fantasai]
dino: If we can detect that the page wants a white background, because it's set some things to white...
01:18:17 [fantasai]
dino: But so far color-filter has been enough
01:18:22 [fantasai]
dino: Good news is implementation is quite easy
01:18:35 [fantasai]
dino: Just at the point of where you're asking for the color value
01:18:42 [fantasai]
dino: It's great, makes it easy to be a render-time effect
01:18:45 [fantasai]
dino: math is pretty easy
01:18:49 [fantasai]
dino: can also cache the values
01:18:51 [myles]
myles has joined #css
01:19:03 [fantasai]
heycam: Some properties to control the color space that we interpolate in
01:19:09 [fantasai]
heycam: for animations and gradients
01:19:17 [fantasai]
heycam: That would happen with origianl color values before transofrming them?
01:19:32 [fantasai]
dino: Don't think there's case wher eyou d'want to change colors *and* change interpolation space
01:19:47 [fantasai]
dino: No idea why red-blue gradient, why if you invert it you'd want it to be in linear-rg
01:19:50 [fantasai]
rgb
01:20:04 [fantasai]
dino: If you ask for gradient colors, you get filtered colors, and then interpolate like gradient said to
01:20:09 [astearns]
s/wher eyou d'want/where you'd want/
01:20:14 [fantasai]
dino: Of course could put property with a media query if you wanted
01:20:22 [fantasai]
chris: So this modification happens last, just before rendering
01:20:26 [fantasai]
dino: Right.
01:20:34 [fantasai]
dino: Computed style is still the original color
01:20:42 [fantasai]
dino: While we're talkign about this, maybe talk about MQ
01:20:53 [fantasai]
dino: Our current one that we use internally, is prefers-dark-interface
01:20:59 [fantasai]
dino: Think it's more prefers-dark-content
01:21:05 [fantasai]
TabAtkins: prefers-dark
01:21:15 [fantasai]
dino: Lines up with prefers-*
01:21:23 [fantasai]
dino: User is requesting that they prefer this type of content
01:21:33 [fantasai]
florian: I'm supportive of prefers-type MQs,
01:21:40 [fantasai]
florian: Question is what is the other options?
01:21:54 [fantasai]
florian: Can you express no preference in addition to expressing preference for light?
01:22:20 [fantasai]
...
01:22:29 [fantasai]
dino: prefers-dark: light seems weird
01:22:30 [TabAtkins]
`color-pref: goth | prep;`
01:22:43 [fantasai]
fantasai: Just rename it to something else, e.g. prefers-colors: light | dark | any
01:22:45 [fantasai]
...
01:23:05 [fantasai]
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"?
01:23:12 [fantasai]
heycam: Are there options to keep it dark?
01:23:31 [fantasai]
dino: I think we need to be careful to say that "Please make this dark for me" can't be a universial hammer
01:23:35 [fantasai]
dino: It's hard to tell
01:23:49 [fantasai]
dino: E.g. we try with scrollbarls, to try to guess whether page is light or dark and make scrollbars match
01:24:00 [fantasai]
dino: Because DaringFireball sets bgcolor which is neither white nor back
01:24:06 [fantasai]
dino: we probably wouldn't change anything
01:24:17 [fantasai]
heycam: Is that a case where the author should indicate they already support dark?
01:24:28 [fantasai]
dino: Question is, does anyone want to force bright?
01:24:45 [fantasai]
dino: If you set bgcolor to hot pink, might say that you support dark and they'll get hot pink anyway
01:24:53 [fantasai]
dino: Also for mail you'd get hot pink
01:24:55 [fantasai]
dino: ...
01:25:08 [fantasai]
florian: Do ppl anticipate forced-darkening of pages?
01:25:17 [fantasai]
dino: There are a lot of users who seem to want that
01:25:31 [fantasai]
dino: They've set up shortcuts to invert the page
01:25:54 [fantasai]
dino: They toggle this on and off as they browse different pages
01:26:03 [fantasai]
florian: If you have prefers-dark and forced-dark on at the same time, what does that mean?
01:26:43 [fantasai]
dino: ...
01:26:52 [fantasai]
dino: If the page says 'I did dark mode' then we wouldn't force it
01:27:02 [fantasai]
dbaron: Did some experiments with this sort of color inversion maybe 8-10 yrs ago
01:27:27 [fantasai]
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 satuaration and lightness contrast at the same time
01:27:37 [fantasai]
dbaron: because the contributions of red green and blue channels to luminance is very very different
01:27:56 [fantasai]
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
01:28:10 [fantasai]
dbaron: which means that fully saturated blue is quite readable against white, but unreadable against black
01:28:24 [fantasai]
dbaron: and fullysaturated green is quite readable against black and unreadable against white
01:28:45 [fantasai]
dino: Which is why my third column was there, it bumped dark blues to lighter blues... blends a light-ish blue over every color ...
01:28:58 [fantasai]
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
01:29:05 [Zakim]
Zakim has left #css
01:29:07 [fantasai]
astearns: I can see the usefulness for this feature for browser UI
01:29:22 [fantasai]
astearns: as something you can toggle, and you can flip it back if it isn't working
01:29:25 [fantasai]
astearns: from a design perspective
01:29:29 [Zakim]
Zakim has joined #css
01:29:38 [fantasai]
astearns: I can't imagine someone wanting to tweak their colors with such a blunt hammer
01:29:59 [chris]
for sTGB it is 21.26% red 71.52% green 7.22% blue
01:30:09 [fantasai]
astearns: Create a light them and a dark theme as a designer, never going to be a filter that'll get you from one to the other
01:30:13 [chris]
s/sTGB/sRGB/
01:30:17 [fantasai]
astearns: So from UA perspective I see the usefulness
01:30:23 [fantasai]
astearns: But from author perspective I can't see the use case
01:30:40 [chris]
zakim, this meeting spans midnight
01:30:40 [Zakim]
I don't understand 'this meeting spans midnight', chris
01:30:51 [chris]
rrsagent, this meeting spans midnight
01:31:05 [astearns]
s/see the use case/see the use case for the color-filter property/
01:31:11 [fantasai]
Rossen: Thank you for demos and explanations, and that's a wrap for this issue.
01:31:20 [fantasai]
Topic: Images Level 3
01:31:34 [heycam]
ScribeNick: heycam
01:32:04 [fantasai]
github: https://github.com/w3c/csswg-drafts/issues/2852
01:32:27 [heycam]
leaverou: we were trying to define interoplation between crossfades more reasonably with Elika yesterday
01:32:38 [fantasai]
s/Elika/fantasai/
01:32:41 [heycam]
... when we're interpolating two cross fades with same images in a different order, A B , then B A
01:32:50 [heycam]
... it ends up creating a cross fade of the cross fade
01:32:59 [heycam]
... this comes up a lot, this interpolation happens when you're reversing a transition
01:33:23 [heycam]
... so fantasai suggested when adding a rule, when the images is the same and the order is different, we flip the order and change the percentages to account for it
01:33:27 [heycam]
... so 100% minus what it was
01:33:38 [heycam]
... is that OK? since it's CR we should check
01:35:00 [heycam]
fantasai: the use case for getting this to work simply is that when you're doing transitions between one image and another, when you interrupt that transition, you're half way between
01:35:07 [heycam]
... so you want to interpolate between a crossfade and a start point
01:35:17 [heycam]
... your computed value gets more and more complex
01:35:34 [heycam]
dbaron: is this the only interoplation type that has this problem?
01:35:39 [heycam]
emilio: I suspect it can happen with transform as well
01:35:42 [heycam]
dbaron: yes
01:35:44 [heycam]
birtles: with calc
01:35:58 [heycam]
ericwilligers: with transform didn't we define ...
01:36:02 [heycam]
TabAtkins: the interpolate() function
01:36:12 [heycam]
dbaron: so transform can do the same thing with interpolate() nesting in the same way
01:36:17 [heycam]
fantasai: we should probably do the same thing for transform then
01:36:28 [heycam]
ericwilligers: does interpolate() make cross-fade() redundant?
01:36:37 [heycam]
leaverou: it only helps you get the intermediate values
01:36:50 [heycam]
fantasai: there are use cases for cross fade where the author explicitly wants to fade between two things
01:36:58 [heycam]
... and there are differnet ways of interpolating images, cross fade is one of them
01:37:40 [heycam]
fantasai: the proposed resolution is that interpolating crossfade or the interpolate function, where the end point and start point have opposite order of arguments, you swap the order, so you don't nest the interpolating function
01:37:57 [heycam]
xidorn: shouldn't we just merge things when one side is crossfade A to B, and the other side is A or B?
01:38:01 [heycam]
fantasai: that's the next question
01:38:05 [heycam]
dbaron: what stage is this happening?
01:38:08 [heycam]
fantasai: computed value?
01:38:19 [heycam]
dbaron: so part of the process of computing the value of a nested cross fade is to un-nest
01:38:30 [heycam]
fantasai: no, when you're computing the mid point for
01:38:35 [heycam]
dbaron: so you're changing the interpolation rules
01:38:45 [heycam]
fantasai: yes
01:38:58 [heycam]
Rossen: does that sounds reasonable to people?
01:39:07 [heycam]
dbaron: yes, if you make it consistently apply to other places where this problem comes up
01:39:11 [heycam]
TabAtkins: yes
01:39:27 [heycam]
Rossen: any objections to this? do we need to add a note for the general interpolate function to be added as well?
01:40:46 [heycam]
birtles: I misunderstood
01:40:57 [heycam]
... I thought this was just about computed value simplification of nested cross-fade
01:41:01 [heycam]
ericwilligers: [writes examples on white board]
01:43:03 [heycam]
birtles: I'm just wondering why we're adding rules to interpolation. would the alternative be to say this is how nested crossfades are simplified at computed value time?
01:43:10 [heycam]
... then you don't need to do anything particular for interpolation
01:43:18 [heycam]
fantasai: we could do that
01:43:21 [heycam]
leaverou: I'd be fine with that
01:44:09 [heycam]
dino: cross-fade(A, B, 50%) is not the same as cross-fade(B, A, 50%)
01:44:19 [heycam]
... it's 50% of src-overing the second on top of the first
01:44:30 [heycam]
fantasai: and with transparency?
01:44:41 [heycam]
dino: you can tell the difference between B over A 50% and A over B 50%, yes
01:44:49 [heycam]
ericwilligers: would you advocate nested cross-fades()?
01:44:53 [heycam]
dino: I'd advocate not interpolating
01:44:57 [heycam]
fantasai: I don't think that's a good solution
01:45:04 [heycam]
dino: if we're going to do it, then nested cross-fade(), maybe
01:45:12 [heycam]
leaverou: nested cross-fades() should be supported anyway
01:45:24 [heycam]
dino: so, yes, nested cross-fades() would be my preferred solution
01:45:37 [heycam]
leaverou: I think it's Safari and Chrome at the moment
01:45:40 [heycam]
birtles: pre-fork, so one implementation
01:47:07 [heycam]
TabAtkins: dino your point before about A B 50% and B A 50% being different is wrong, since it's a dissolve
01:47:32 [heycam]
... dissolve op rather than src-over op
01:47:43 [heycam]
... since that's the correct way to fade between two images with potential transparencies
01:48:36 [heycam]
Rossen: do we need a whiteboarding breakout for this?
01:49:23 [heycam]
leaverou: if reversing the order does produce the same image, what's the argument against it
01:49:29 [heycam]
... if nobody has any then why do we need to break out
01:50:12 [fantasai]
http://drafts.csswg.org/css-images-3/
01:50:19 [fantasai]
https://drafts.csswg.org/css-images-3/#cross-fade-function
01:51:32 [heycam]
TabAtkins: only options are (a) do nothing, allowing nesting, (b) accept these rules for interpolation simplification, or (b) accept these rules for computed value simplification and allow interpolation to fall out
01:51:35 [heycam]
emilio: why (c)?
01:51:47 [heycam]
leaverou: then it also allows us to simplify computed values returned
01:51:53 [heycam]
emilio: I thought the point was nested cross fade is hard
01:52:08 [heycam]
TabAtkins: it's not that it's hard, but in common cases, like repeatedly interrupting a transition, it resutls in a stack of cross-fade()s
01:52:11 [heycam]
... when you could simplify it down
01:52:21 [heycam]
emilio: the difference between (b) and (c) is not observable
01:52:36 [heycam]
TabAtkins: yes it is
01:52:39 [heycam]
emilio: I think I prefer (b)
01:52:43 [heycam]
leaverou: [shows demo]
01:53:43 [heycam]
emilio: if you want to simplify what you interpolate, to avoid growing stacks of cross-fades(), you do it there
01:53:49 [heycam]
... but you also need to do it at computed values
01:54:00 [heycam]
... because the author might have specified a nested cross-fade()
01:54:08 [heycam]
fantasai: the interoplated intermediate value must be a computed value
01:54:18 [TabAtkins]
Note that if we *do* finally do the "any number of images" extension, then we can simplify *all* nested cross-fades, in all situations.
01:54:31 [heycam]
leaverou: if I'm understanding emilio correctly, you don't want to create this thing if you're going to simplify it anyway
01:54:45 [heycam]
... if you're already going to simplify serialization of a specified (and computed) value
01:54:53 [heycam]
emilio: it complicates the code
01:55:08 [heycam]
birtles: I wonder if you're going to need to simplify it first anyway, in order to interpolate potentially nested inputs that you get
01:55:13 [heycam]
ericwilligers: yes
01:55:28 [heycam]
birtles: also will need to do it for addition, assuming that makes sense
01:55:42 [heycam]
leaverou: ideally it would be nice if cross-fade() accepted any number of arguments, and flatten them down to a single one
01:55:48 [heycam]
ericwilligers: then you've got more computations
01:55:57 [heycam]
s/computations/permutations/
01:56:12 [heycam]
leaverou: if you could collapse the tree down to a flat cross fade list of values, it's simpler to apply
01:56:21 [heycam]
TabAtkins: since dissolve commutes, you can collapse all cross fades
01:56:25 [heycam]
dino: plus commutes, dissolve doesn't
01:56:40 [heycam]
dino: what I got wrong is I'm src-overing not plusing
01:56:56 [heycam]
TabAtkins: plusing an appropriate dissolved image commutes, such that you can take nested cross fades and flatten it to a list of images that plus together
01:57:06 [heycam]
leaverou: should we just do that, allow cross-fade() to take a list of arguments
01:57:31 [heycam]
birtles: I think it's nicer from an authoring point of view too
01:57:55 [birtles]
that is, parsing the result of getComputedStyle is easier if you don't need to handle nested cross-fade functions
01:59:25 [heycam]
leaverou: another issue, if you're interpolating between A and cross-fade(A, ...), with the current rules you'll get a nested cross-fade()
01:59:40 [heycam]
... we could define that the A gets promoted to 100% cross-fade, and just interpolate percentage
01:59:49 [leaverou]
https://github.com/w3c/csswg-drafts/issues/2853
02:00:30 [heycam]
fantasai: I think the proposal one this one is you get a single cross-fade() with A and B with arguments and the appropriate percentage
02:00:40 [heycam]
leaverou: we can, but if we're collapsing trees of cross-fade()s, it's less important
02:00:47 [heycam]
fantasai: collapsing trees is different from merging
02:00:55 [heycam]
TabAtkins: depends how we collapse
02:01:28 [heycam]
dino: [looking at the issue] wouldn't it be x is between 0 and p, not p and 100?
02:01:38 [heycam]
leaverou: you're interpolating between full A and the cross-fade
02:01:45 [heycam]
... you want it to start at 100
02:01:52 [heycam]
dbaron: I think we should try to resolve both at the same tim
02:01:55 [heycam]
s/tim/time/
02:02:07 [heycam]
... where the simplification happens, turning into multi arg cross-fade(), applies to both
02:02:26 [heycam]
myles: the proposal is change the behavior because it makes it easier to compute?
02:02:40 [heycam]
leaverou: this way you wouldn't need to interpolate to make a new cross-fade() at all
02:03:16 [heycam]
myles: there is a difference between having a tree of cross fades and not having a tree
02:03:21 [heycam]
TabAtkins: nobody has trees yet
02:03:25 [heycam]
... we're trying to avoid that now
02:03:42 [heycam]
TabAtkins: overall proposal is, avoid all trees of cross-fades, in all situations, by making it accept more than two arguments, just dissolve and plus throughout those
02:03:46 [fantasai]
fantasai explains that interpolating cross-fade(x% A, B) and cross-fade(y% A, B) results in cross-fade(z% A, B), not a tree of cross-fades()s
02:04:04 [heycam]
... and make nested cross-fade() invalid, and make interpolations between them build the appropriate multi-arg value
02:04:46 [fantasai]
this issue about treating interpolation of A & cross-fade(y% A, B) and cross-fade(100% A, B) & cross-fade(y% A, B) the same way
02:04:47 [dbaron]
q+ to comment on (a) nesting through other functions and (b) validity of percentages that add to more than 100%
02:05:59 [heycam]
[whiteboard discussion of particular interpolations]
02:06:42 [heycam]
leaverou: I still think nested cross-fades() should be valid, since they could come from variables
02:07:08 [heycam]
myles: if the goal is to avoid avoiding trees, by making a list that has all the nodes of the tree, I don't see why that's better
02:07:17 [heycam]
TabAtkins: you don't need to generate all the intermediate images
02:07:22 [heycam]
myles: is there a behaviour change?
02:07:23 [heycam]
TabAtkins: no
02:07:31 [heycam]
myles: then we should just say "as if", a browser optimization
02:08:02 [heycam]
myles: so we're talking about computed values
02:08:27 [heycam]
florian: do we disallow in specified value?
02:08:35 [heycam]
TabAtkins: before we decide on that, let's look at the core thing
02:08:46 [heycam]
... multi-arg cross-fade(), does it sound reasonable
02:08:55 [heycam]
dino: and you must provide %s up to the last one?
02:09:00 [heycam]
... allowed to go over 100%?
02:09:06 [heycam]
TabAtkins: yes [for first], and no.
02:09:24 [heycam]
TabAtkins: if the percentages add up to over a 100%, you sum them and normalize to 100%
02:09:28 [heycam]
... then the last one gets zero
02:09:34 [heycam]
myles: every time gets a percentage
02:09:36 [heycam]
TabAtkins: except the last
02:09:42 [heycam]
... last one gets what's left over
02:09:51 [heycam]
dino: complete error if you did (A 10%, B, C)?
02:09:53 [heycam]
TabAtkins: syntax error
02:10:16 [innovati]
innovati has joined #css
02:10:40 [heycam]
myles: is the purpose of this that humans will write this? or just to make the getCS output smaller?
02:11:00 [heycam]
TabAtkins: so clearly we want this for interpolation
02:11:23 [fantasai]
heycam: Simplifying trees down to one level is same as flat list
02:11:38 [fantasai]
heycam: Want to collapse list to minimum number of items
02:11:47 [fantasai]
TabAtkins: If the goal is to avoid explosion...
02:12:09 [heycam]
myles: if this is for humans to use, it's useful
02:12:14 [heycam]
ericwilligers: negative %s allowed?
02:12:21 [heycam]
TabAtkins: no, individual %s above 100% should be disallowed
02:12:28 [fantasai]
s/disallowed/invalid/
02:12:36 [fantasai]
TabAtkins: But we can't syntacitcally restrict the sum
02:12:42 [heycam]
birtles: I'm not 100% sure about the normalization part
02:12:45 [heycam]
... the syntax I like
02:12:54 [heycam]
ericwilligers: not sure about normalization when you have interpolations between lists
02:13:29 [heycam]
birtles: I was thinking, once the bucket's full, the overflow could be dropped
02:13:42 [heycam]
myles: should make it possible for the last one to have a %
02:13:48 [heycam]
florian: to use them as 'fr's?
02:13:54 [heycam]
leaverou: right now, cross-fade() percentage is optional
02:13:58 [heycam]
... probably it should retain this
02:14:05 [heycam]
... right now (A, B), the 50% is implied
02:14:15 [heycam]
... (A 20%, B, C) should make sense
02:14:20 [heycam]
shans: distribute the rest
02:14:22 [heycam]
leaverou: yes
02:14:37 [heycam]
myles: allow the last percentage to be specified, then just weight them
02:14:51 [astearns]
q?
02:15:04 [heycam]
fantasai: if you have (A 20%, C 20%, C 20%)
02:15:15 [heycam]
... you could simply transparent black to take the slack
02:15:29 [heycam]
florian: rather than normalizing to 100%?
02:15:31 [heycam]
fantasai: if you're under
02:15:51 [heycam]
shans: one problem with diff behaviours on either side of 100% gets you non-linearities, bad for animation
02:15:56 [heycam]
ericwilligers: like opacity:1
02:16:16 [astearns]
ack dbaron
02:16:16 [Zakim]
dbaron, you wanted to comment on (a) nesting through other functions and (b) validity of percentages that add to more than 100%
02:16:55 [heycam]
TabAtkins: the suggest grammar is, cross-fade() takes one or more args, each has an optional %
02:16:59 [heycam]
... we'll work out what missing %s mean
02:17:04 [heycam]
Rossen: any objections to that?
02:17:14 [heycam]
RESOLVED: cross-fade() takes one or more args, each has an optional %
02:17:23 [heycam]
leaverou: next, collapsing trees of cross-fade()s
02:17:32 [heycam]
... it's much easier to define interpolatino that way
02:17:36 [heycam]
... for authors reading it back
02:17:47 [heycam]
... don't know why we wouldn't collapse it down, esp given it's commutative
02:18:08 [heycam]
emilio: can we disallow nested cross-fade() in specified values?
02:18:16 [heycam]
TabAtkins: no for the same reason you allow nested calc()s
02:18:20 [heycam]
leaverou: with variables
02:18:52 [heycam]
dbaron: two other points
02:18:58 [Rossen]
q?
02:19:00 [heycam]
... there are going to be other image-ish functions
02:19:13 [heycam]
... cross-fade() one of these other functions continaing a cross-fade() will be a reasonable thing
02:19:40 [heycam]
... I think the other piece is that I think one of the things that results from disallowing it, everyone has to go and implement that, then later we'll allow it, which is more work
02:19:44 [heycam]
... so we should just allow it now
02:19:47 [heycam]
TabAtkins: agreed
02:19:55 [heycam]
... specified values should allow it. interpolated values collapse to a single value
02:19:59 [heycam]
... interpolated values, don't care?
02:20:02 [heycam]
leaverou: I would collapse
02:20:05 [heycam]
birtles: collapse
02:20:09 [heycam]
fantasai: I thin kso
02:20:39 [heycam]
s/thin kso/think so/
02:20:58 [heycam]
florian: both kinds of smooshing down, flattening tree, and merging items in the list?
02:21:03 [heycam]
leaverou: they are separate issues but I support both
02:21:30 [heycam]
myles: so it's not just a simple substitution, there are formulas to calcalate the %s
02:21:41 [heycam]
TabAtkins: yes. it's just mulitplican tho
02:22:27 [heycam]
RESOLVED: At computed value time, simplify directly nested cross-fade()s into a single cross-fade()
02:22:33 [heycam]
xidorn: that means the flattened value is the canonical form of that
02:22:36 [heycam]
TabAtkins: yes
02:22:44 [heycam]
leaverou: now dropping duplicated images
02:22:50 [heycam]
TabAtkins: if you have multiple args which are the same image
02:23:00 [heycam]
... should the canonical form automatically collapse those together and add their percentage
02:23:13 [heycam]
leaverou: do we have an algorithm for same image?
02:23:21 [heycam]
fantasai: the compued value of the <url> is the absolute URL
02:23:47 [heycam]
Rossen: the reason for simplifying is avoiding growth of the values
02:24:32 [heycam]
leaverou: we should not only combine the duplicates but also sort them
02:24:48 [heycam]
fantasai: I think we need to simplify this, to avoid growing lists
02:24:54 [heycam]
... we can do it very simply
02:25:59 [heycam]
emilio: how do you define sorting images?
02:26:19 [heycam]
myles: if you didn't want this, didn't want to collapse -- internally you want to
02:26:55 [Rossen]
heycam: are the cases where we want avoid this?
02:27:01 [heycam]
fantasai: I don't think so
02:27:09 [heycam]
... it's going to be the same when you collapse it all down
02:27:17 [heycam]
fantasai: notion of equality we want is "computed values are the same"
02:27:46 [heycam]
frremy: with gradients, with px and %s ....
02:27:49 [heycam]
fantasai: that's not computed value
02:27:52 [heycam]
... that's used value
02:29:03 [heycam]
RESOLVED: At computed value time we collapse same <image> values in cross-fade()s and adding their percentages
02:29:27 [heycam]
leaverou: sorting
02:29:53 [heycam]
fantasai: you don't want computed value of cross-fade() where you randomly swap the order
02:29:59 [heycam]
fantasai: re-sort into the target order and go from there?
02:30:04 [heycam]
... so don't sort the computed value
02:30:12 [heycam]
... but when interpolating, you re-sort the start point into the end point order
02:30:23 [heycam]
myles: that's cool then CSS doesn't have to define order
02:32:28 [heycam]
so no sorting occurs, for interpolation it falls out of the simplification process
02:32:36 [TabAtkins]
When interpolating be3tween A and B, you just cross-fade(A,B) then collapse; whatever that results in is the answer.
02:32:59 [fantasai]
Topic: Deferring gradient interpolation to L4
02:33:00 [Rossen]
Topic: Defer gradient interpolation to L4?
02:33:31 [fantasai]
i/myles/fantasai: order for interpolations falls out of cross-fade(start, end) and flattening/
02:33:39 [heycam]
Rossen: anyone objection to deferring gradient interpolation to L4, to move L3 quicker?
02:33:46 [heycam]
RESOLVED: Gradient interpolation is moved to Images L4
02:34:00 [heycam]
fantasai: we should clarify the spec to say we do abrupt transitions
02:34:09 [heycam]
... (and not cross-fade)
02:34:39 [dbaron]
leaverou: people can still wrap in cross-fade to force interpolation by cross-fade?
02:34:43 [dbaron]
TabAtkins: fantasai: yes
02:35:40 [heycam]
Topic: Deferring cross-fade() to L4?
02:35:42 [heycam]
Rossen: nobody implements it
02:35:46 [heycam]
... Images L3 is in a good shape
02:35:49 [heycam]
TabAtkins: let's do that
02:36:08 [heycam]
RESOLVED: cross-fade() is moved to Images L4
02:36:34 [leaverou]
https://drafts.csswg.org/issues?spec=css-images-3&doc=cr-2012
02:37:56 [leaverou]
Gamma issue: https://www.w3.org/Mail/flatten/index?subject=https://lists.w3.org/Archives/Public/www-style/2014Nov/0114.html&list=www-style
02:38:13 [heycam]
<br type="lunch" until="1:36pm">
03:11:39 [heycam]
heycam has joined #css
03:51:49 [fantasai]
Topic: Does all reset custom properties?
03:51:52 [fantasai]
github-bot:
03:51:52 [github-bot]
fantasai, Sorry, I don't understand that command. Try 'help'.
03:52:02 [fantasai]
github: https://github.com/w3c/csswg-drafts/issues/2518
03:52:36 [fantasai]
TabAtkins: Two questions to this issue. First is does all reset custom properties? I say yes
03:53:05 [fantasai]
TabAtkins: second, should we have something that does? I say yes, Emilio says no
03:53:10 [fantasai]
emilio: I don't remember why...
03:53:28 [fantasai]
astearns: Proposed that custom properties don't get reset by all. Any objections?
03:53:37 [fantasai]
dbaron: Have ppl checked implementations?
03:53:51 [fantasai]
frremy: Edge doesn't
03:54:07 [fantasai]
xidorn: In Gecko it doesn't reset custom properties either
03:54:22 [fantasai]
emilio: We have an invariant that only have one longhand in a given declaration block
03:54:45 [fantasai]
emilio: We only store longhands, we don't store shorthands
03:55:02 [fantasai]
emilio: That's why it doesn't reset custom properties
03:55:09 [fantasai]
emilio: We'd need to rewrite everything.
03:55:13 [myles]
myles has joined #css
03:55:24 [fantasai]
TabAtkins: Chrome also does not reset custom properties
03:55:30 [fantasai]
RESOLVED: all shorthand does not reset custom properties
03:55:33 [TabAtkins]
test: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6017
03:55:43 [frremy]
frremy has joined #css
03:55:45 [fantasai]
Next question, should something reset all custom properties
03:56:21 [fantasai]
emilio: custom properties are inherited, so if you had a -- property that resets everything, an dit would inhherit, so it resets everything all the way down the subtree?
03:56:27 [fantasai]
fantasai: It would have to be a non-custom property
03:56:52 [heycam]
heycam has joined #css
03:57:01 [fantasai]
leaverou: What's the usecase?
03:57:31 [fantasai]
TabAtkins: If you have some component, you want to make sure you don't get the outer page inheriting stuff into it that disrupts your stuff because of name clashes
03:57:38 [fantasai]
...
03:57:41 [fantasai]
TabAtkins: So it would be a shorthand
03:57:56 [fantasai]
s/.../emilio: So it would be a longhand/
03:58:16 [fantasai]
fantasai: It would be a longhand from engine's perpsective, has effect of reseting the prperties, so it looks like a shorthand to the author
03:58:33 [fantasai]
emilio: Reason why it's hard is, it's hard to know when do you need to reset it. and hard to make it do the right thing
03:58:41 [fantasai]
emilio: When do you check the value of this property?
03:58:52 [fantasai]
emilio: Presumably you want it to work like all property
03:58:56 [fantasai]
emilio: --: reset;
03:59:01 [fantasai]
emilio: vs --: foo;
03:59:27 [fantasai]
emilio: What properties is it resetting, we don't know what the properties are that we're resetting
03:59:38 [fantasai]
emilio: until we've cascaded/inherited the custom props
03:59:59 [fantasai]
TabAtkins: ... I understand the problem now
04:00:21 [fantasai]
TabAtkins: If you say --foo: red; --: initial; --bar: blue;
04:00:38 [fantasai]
TabAtkins: The --foo needs to be reset to initial, but --bar needs to still be blue
04:01:04 [fantasai]
TabAtkins: That's problematic because you have no idea that -- needs to expand into --foo until you see that --foo is declared on or inherited into that element
04:01:19 [fantasai]
frremy: In Edge we have a registry of all properties, which need to be handled before ...
04:01:35 [fantasai]
TabAtkins: So you would expand it to all the properties on th epage?
04:01:44 [fantasai]
emilio: That's not the point of the feature
04:01:59 [fantasai]
emilio: You can't expand it at parse time
04:02:04 [fantasai]
frremy: You don't expand at parse time
04:02:10 [fantasai]
xidorn: ...
04:02:27 [fantasai]
emilio: Also, magic of "every prop htat has aappeared on the page so far" is really bad
04:02:33 [fantasai]
frremy: Not proposing that
04:02:52 [xidorn]
s/.../Expanding at parse time is how shorthand is supposed to work/
04:03:05 [fantasai]
TabAtkins: If you do it as that type of prescan, then you can do this. Otherwise you can't
04:03:18 [fantasai]
emilio: You can't implement as a shorthand, because you don't know for serialization what it expands to
04:03:41 [fantasai]
emilio: You have to treate it as a longhand, but then you need to look at that property before you look for custom properties
04:03:52 [fantasai]
emilio: Let's say you specify this as a longhand property, then you can do what eric said
04:04:15 [fantasai]
emilio: But you needto look at the value of this property before computing the custom properties.. which you need to compute the values of the rest of the poperties (in case they're used)
04:04:24 [fantasai]
emilio: Right now we have different phases
04:04:31 [fantasai]
emilio: This would convert it from 2 to 3 phases.
04:04:36 [fantasai]
emilio: First figure out magic property's computed value
04:04:42 [fantasai]
emilio: Then figure out custom properties
04:04:46 [fantasai]
emilio: then figure out the rest
04:04:50 [fantasai]
emilio: which is kindof annoying
04:05:19 [fantasai]
...
04:05:28 [fantasai]
frremy: ...
04:05:35 [fantasai]
emilio: We don't want a global index of custom properties
04:05:55 [fantasai]
xidorn: Maybe we can have a longhand property which doesn't affect element itself, but cuts inheritance to its children, which doesn't have this problem
04:06:23 [fantasai]
TabAtkins: This would change the inherited value of your custom properties on the children to the value of --
04:06:49 [myles]
myles has joined #css
04:06:56 [fantasai]
TabAtkins: But then can't both block inheirtance from parent and set specific custom props for inehritance to your children
04:07:11 [fantasai]
TabAtkins: on the same element
04:07:32 [fantasai]
TabAtkins: Possibility is to make -- take a list of properties to *not* reset
04:07:43 [TabAtkins]
Possibility is to make -- take a list of custom properties to *not* reset, and then it alters the way that all unspecified custom properties inherit to the element's children.
04:07:44 [fantasai]
TabAtkins: And then it alters the way that all unspecified custom properties inherit to the element's children
04:07:51 [fantasai]
frremy: I don't think we like this
04:08:03 [fantasai]
TabAtkins: I think it's the only way to make -- work on a single element without being a shorthand
04:08:19 [fantasai]
astearns: You would be duplicating the properites that you want to declare on that element
04:08:22 [fantasai]
TabAtkins: Correct.
04:08:54 [fantasai]
fantasai: Think that this means we should not add the feature. Nobody's been clamoring for it anyway.
04:09:01 [fantasai]
RESOLVED: -- is reserved
04:09:15 [fantasai]
RESOLVED: Don't add shorthand for custom props
04:09:22 [fantasai]
Topic: env()
04:09:59 [fantasai]
Topic: process for adding env() variables
04:10:01 [fantasai]
github: https://github.com/w3c/csswg-drafts/issues/2820
04:10:09 [fantasai]
TabAtkins: I agree.
04:10:25 [fantasai]
astearns: Currently spec says “
04:10:25 [fantasai]
user agents may define additional undocumented environment variables
04:10:26 [fantasai]
”
04:10:51 [fantasai]
TabAtkins: I think Apple agrees with proposal, too
04:11:09 [fantasai]
dino: When original discussion happened, there was some mumblings that some platforms might want to expose system colors specific to that platform in some way
04:11:13 [fantasai]
dino: But I don't know if anyone still believes that
04:11:47 [fantasai]
RESOLVED: Accept proposal in the issue.
04:11:57 [fantasai]
“UA vendors MUST NOT expose built-in env() features to the web without going through that process”
04:12:12 [fantasai]
Topic: Accept safe-area-inset*
04:12:27 [fantasai]
github: https://github.com/w3c/csswg-drafts/issues/2868
04:12:44 [fantasai]
dino: We proposed this last year
04:12:53 [fantasai]
dino: I think this one is hopefully not so controversial
04:13:06 [fantasai]
dino: We expose it so ppl can avoid notch in iPhone and rounded corners
04:13:20 [fantasai]
dino: But can also be used for e.g. safe area for televisions
04:13:27 [fantasai]
fantasai: Would be really usefl for printing as well
04:13:35 [astearns]
https://drafts.csswg.org/css-env-1/#safe-area-insets
04:13:40 [fantasai]
dino: Having experimented with this, it makes sense for insets
04:14:04 [fantasai]
dino: But let's imagine that what you're trying to do is get ppl to avoid X in thet top corner of the screen
04:14:10 [fantasai]
dino: page shouldn't put anything there
04:14:20 [fantasai]
dino: Should we inset the entire top/left sides?
04:14:28 [fantasai]
dino: Or just a note saying avoid that part of the screen?
04:14:50 [fantasai]
dino: Let's pause and talk about that later?
04:15:02 [fantasai]
dbaron: There was some prec prose that Rebecca Hughes and I iterated over
04:15:14 [fantasai]
dbaron: Because I didn't want Google to ship without a spec for it
04:15:21 [fantasai]
dbaron: What I suggested there, and which I thin kis now in the draft,
04:15:33 [fantasai]
dbaron: Was that the insets together should define a rectangle such that everything in that rectangel is safe
04:15:49 [fantasai]
dbaron: But what you're showing is your insets are more than that
04:16:07 [fantasai]
dbaron: You could use any pair of them... but that doesn't work for the notch
04:16:27 [fantasai]
dino: Right, for notch, we have top and bottom insets and it's fine
04:16:40 [fantasai]
dino: But if your rotate sideways, then you have left and right insets
04:16:49 [fantasai]
dbaron: I'm wondering if the diagram is intentional
04:17:06 [fantasai]
dbaron: I'm suggesting that the rectangle inside the insets was safe
04:17:28 [fantasai]
dbaron: but if you move any of those lines outward, then it's no longe rsafe
04:18:08 [fantasai]
(dbaron is talking about taking the largest rectangle that would fully fit within the safe area, and using its edges as the inset edges vs. considering each inset individually, making sure the entire screen is safe along that edge or inward from it)
04:18:47 [fantasai]
dbaron: Specced that the UA is allowed to pick whatever it wants that would maximize the the usuable space
04:18:59 [fantasai]
dbaron: There are multiple solutions, might want a narrower or wider rectangle, that affects how tall it can be
04:19:28 [fantasai]
myles: The UA is the one that decides what safe me
04:19:36 [fantasai]
myles: We could say that the innermost rectangle is safe
04:19:50 [fantasai]
dbaron: Prose we put it said something like
04:20:07 [fantasai]
“There is some nonrectangular safe region. The insets define some maximal rectangle within that region”
04:21:43 [fantasai]
fantasai restates what dbaron was saying
04:21:53 [fantasai]
dino: I think this definition would be acceptable...
04:22:09 [fantasai]
dino: User agent could also be free to pick a rectangle where it only specifies a top and a bototm inset in this case, and uses the entire width
04:22:16 [fantasai]
dino: Would be overagressive in saying what's safe
04:22:28 [fantasai]
fantasai: there might be different use cases for each definition...
04:22:46 [fantasai]
myles: For TV example, there's no horizontal line that's afe all the way across
04:22:56 [stryx`]
stryx` has joined #css
04:23:06 [fantasai]
dino: TV wants more like the green example (individal insets)
04:23:21 [fantasai]
dino: whereas a rounded display needs more like the red one (dbaron's definition)
04:23:26 [astearns]
q?
04:23:37 [fantasai]
iank_: Another take is that the green is the same as the red plus a margin
04:24:04 [fantasai]
fantasai: Could have two different sets of variables, safe-area-inset and safe-rect-inset...
04:24:29 [fantasai]
heycam: With scrolling, might have different preferences on whether to maximize horizontal or vertical areas
04:24:42 [fantasai]
myles: UA could alter these
04:24:59 [fantasai]
astearns: Hroizontal vs vertical orientation of device, would UA reset them depending on orientation?
04:25:02 [fantasai]
dino: Currently does, yes
04:25:37 [fantasai]
myles: ...
04:25:47 [fantasai]
astearns: Are you unsure whether having these four insets is the right design?
04:25:57 [fantasai]
dino: I was sure, now wondering whether we should define them as the red rectangle
04:26:33 [fantasai]
dino: With the green rectangle you can be safe, if I pad enough from the top, I know I'm going to be visible in that case, even though I wo'n't be safe...
04:26:41 [fantasai]
dino: Maybe we should hold this.
04:27:07 [fantasai]
dino: I will take this back and discuss with other ppl
04:27:15 [fantasai]
dbaron: I think the text needs adjusting for the TV use case, also.
04:27:28 [fantasai]
Topic: Full-screen insets
04:27:29 [dbaron]
https://drafts.csswg.org/css-env-1/#safe-area-insets
04:27:39 [fantasai]
github: https://github.com/w3c/csswg-drafts/issues/2871
04:27:57 [dbaron]
(that URL was for the previous topic)
04:28:18 [fantasai]
dino draws a fullscreen video player
04:28:23 [fantasai]
There's a title in the top left corner
04:28:26 [fantasai]
there's controls along the bottom
04:28:43 [fantasai]
dino: Works fine on a desktop machien because everyone knows you can get out with escape or whatever
04:28:50 [fantasai]
dbaron: But touch interface doens't have escape key
04:28:59 [fantasai]
dino: So we need to provide some UI for escaping
04:29:05 [fantasai]
dino: e.g. an X in the top left corner
04:29:16 [fantasai]
dino: Fades away if you haven't touched the screen much lately
04:29:29 [fantasai]
dino: Trying to come up with avriables to take the page where it can draw content when the browser UI is available
04:29:45 [fantasai]
florian: We kindof alked about that when we were doing round display, with different approach
04:29:57 [fantasai]
florian: MQ with coordinate, if I put something there, will it be visible?
04:30:14 [fantasai]
florian: Rather than browser trying to prove geometry, can just ask "can I put the box there"?
04:30:24 [fantasai]
myles: Why would you want to binary search for an available space? seems awful
04:30:30 [fantasai]
dino writes an example
04:30:39 [fantasai]
title { pos: abs; top: env(fs-inset-top);
04:30:51 [fantasai]
dino: Can even say title { transition: top 1s; }
04:31:07 [fantasai]
dino: then the title shifts as the browser UI desappears and appears
04:31:21 [fantasai]
dino: While we specify top/left/bottom/right
04:31:38 [fantasai]
dino: top effectively reserves the entire top
04:31:52 [fantasai]
dino: We might do {various things } in this area
04:32:45 [fantasai]
dino: In safe mode, would also have put the left side offset, but we decided to just do the top
04:32:48 [fantasai]
...
04:32:50 [fantasai]
astearns: ...
04:33:08 [fantasai]
dino: The issue is that we did that for awhile, and it looks weird if the title is not at the top. Looks lik they've got a weird design
04:33:30 [astearns]
s/.../so the space taken up by the browser UI is only known when the UI is showing/
04:33:34 [fantasai]
dino: Other issue I link to, because we fade out the X, it's a good example where YouTube fades out their UI as well
04:33:44 [fantasai]
dino: Might want to expose timers on our fading so they can synchronize
04:33:57 [fantasai]
heycam: Maybe use events rather than time?
04:34:10 [fantasai]
dino: Events makes more sense, usually we're responding to those in JS anyway
04:34:16 [fantasai]
heycam: ...
04:34:32 [fantasai]
dino: We'd also have to publish and make sure everyone's listening to the same events
04:34:46 [fantasai]
dino: That's basically the two proposals. Happy for any suggestions or comments
04:34:55 [fantasai]
florian: What we started with seemed nice and simple
04:35:04 [heycam]
s/.../also you don't know when exactly to start counting those seconds/
04:35:27 [fantasai]
florian: but semes like maye they're overly simplified, and as you get into more complicated situations we keep having to add mroe and more tricks
04:35:34 [dbaron]
s/dbaron:/?:/
04:35:39 [fantasai]
dino: It's veyr specific to our design, but we want to have something that works for others as well.
04:36:29 [rego]
rego has joined #css
04:36:47 [fantasai]
florian draws a dashboard display and asks about how far are we going to go
04:37:05 [fantasai]
dino: safe-area-* is about hardward shapes. fs-inset is about on-screen displays
04:37:11 [fantasai]
florian: ...
04:37:20 [fantasai]
myles: System with arbitrary shapes would be so difficult to use that no developer would do it
04:37:34 [astearns]
s/hardward/hardware/
04:37:40 [fantasai]
Rossen: Similar to this, we had a value called device-fixed
04:37:47 [fantasai]
Rossen: Worked exactly you describe,
04:38:00 [fantasai]
Rossen: When onscreen keyboard came in, didn't want to resize the entire window
04:38:06 [fantasai]
Rossen: But i fyou wanted to attach UI on top of the keyboard, e.g.
04:38:11 [fantasai]
Rossen: Insteadd of positoin: fixed
04:38:17 [fantasai]
Rossen: You'd do position: device-fixed
04:38:30 [fantasai]
Rossen: And it would adjust
04:38:45 [fantasai]
Rossen: You won't have to resynch or compute any numeric values like top/bottom etc.
04:38:48 [astearns]
s/?:/dino:/
04:38:50 [fantasai]
dino: You wouldn't be able to animate
04:39:00 [fantasai]
Rossen: That would be done for you
04:39:07 [fantasai]
Rossen: Basically saying that the device now is going up
04:39:13 [fantasai]
Rossen: on-screen keyboard is cming up
04:39:29 [fantasai]
Rossen: If this UI was important for YouTupe, they'd simply position this as device-fixed
04:39:38 [fantasai]
Rossen: And then this simply becomes bottom: 0;
04:39:44 [fantasai]
Rossen: And they don't need to do anything else
04:39:50 [fantasai]
Rossen: They don't even know, it's still the same thing
04:40:03 [fantasai]
florian: If you are sizing things, would that affect viewort units?
04:40:16 [fantasai]
Rossen: This is ovekill
04:40:32 [fantasai]
Rossen: Another example put forward was if you have, suppose some vertical sidebar
04:40:47 [fantasai]
Rossen: Same thing, a bit more work for us, but if you have positioned top and obttom it would respond
04:41:09 [fantasai]
Rossen: From what I know, it was very successful because very simple
04:41:18 [fantasai]
Rossen: position: fixed vs position: device-fixed
04:41:29 [heycam]
fantasai: why isn't position:fixed have the behavior of device-fied?
04:41:42 [fantasai]
Rossen: We weren't actually resizing the viewport, it was an overlay UI
04:42:02 [fantasai]
Rossen: e.g. keyboard uses semitranslucent colors
04:42:11 [heycam]
fantasai: but what if you want to clearly see the content at the bottom of the page?
04:42:15 [heycam]
Rossen: just dismiss the keyboard
04:42:25 [fantasai]
fantasai: What if you need to type into a form field at the bottom of the page?
04:43:15 [fantasai]
frremy: Then you can dock your keyboard.
04:43:39 [fantasai]
dino: Do you still support device-fixed?
04:43:41 [fantasai]
Rossen: yes
04:43:57 [fantasai]
Rossen: We were doing this for action center, which is something that swipes from the right
04:44:05 [fantasai]
Rossen: If you have some UI that's really important to your app
04:44:09 [fantasai]
Rossen: you can attach it
04:44:16 [fantasai]
myles: Does it work if the window is not full screen?
04:44:23 [fantasai]
Rossen: No, this is only for full-screen
04:44:47 [fantasai]
iank_: What is the box?
04:45:03 [fantasai]
dino: In our case the device-fixed box would be what remains after the inset here.
04:45:12 [fantasai]
iank_: But it wouldn't solve this use case?
04:45:22 [fantasai]
dino: It would, but ti wouldn't solve use case of wanting ot fade all controls at once
04:45:28 [fantasai]
iank_: What aobut tile shifting to the right?
04:45:38 [fantasai]
dino: We'r ereserving the right ot put more things up there
04:46:07 [fantasai]
dino: Would be up to browser to animate the the device-fixed box.
04:46:11 [fantasai]
myles: Animation is different
04:46:16 [fantasai]
myles: we want the animation to fade out
04:46:26 [fantasai]
myles: whereas you want it to slide out
04:46:51 [fantasai]
Rossen: You can fade out the keyboard or slide it?
04:47:05 [fantasai]
myles: How does the page know to fade out or side out things?
04:47:19 [fantasai]
dino: Say youtube uses a 3s fade, and we use a 4s fade.
04:47:33 [fantasai]
dino: Wnat to tell youtube to use 4s if it wants to be in sync
04:48:26 [fantasai]
fantasai: In Apple's case, could just use the transition time value in the 'transition' property
04:48:56 [fantasai]
Rossen: Reason we wanted it done in browser was because syncing timers was not working
04:49:19 [fantasai]
astearns: weirdly shaped things will need to use a lot of environment variables
04:49:56 [fantasai]
dino: OK, we'll take back this feedback
04:50:12 [fantasai]
fantasai: Also, you might want to consider s/fullscreen/overlay in the names... it's not really about the fullscreening
04:50:38 [fantasai]
Rossen: If we are looking to solve the tying of author-defined controls with UA controls animation
04:50:47 [fantasai]
Rossen: You can have a start and an end event
04:51:31 [fantasai]
Rossen: Just also need to know how long between the two
04:51:38 [fantasai]
myles: Could be part of the start event
04:51:52 [fantasai]
astearns: Maybe you only need one set of environment variables
04:52:33 [fantasai]
Topic: Media Queries
04:52:48 [fantasai]
dino: Talked about prefers-dark mode ones.
04:52:58 [fantasai]
dino: Other one is prefers-high-contrast
04:53:10 [fantasai]
dino: Apple has a simple toggle for this. Prefer high contrast? Yes/NO
04:53:22 [fantasai]
dino: It's much more complicated in Windows
04:53:31 [fantasai]
dino: Would want auto | yes| no
04:53:53 [fantasai]
dino: Blocked on not knowing what Windows or Android do, what granualrity do they have, how much do they want to expose.
04:54:18 [fantasai]
frremy: We have states [light | dark ] high-contrast?
04:54:34 [fantasai]
florian: In Apple contrast vs light/dark are separate
04:54:56 [fantasai]
Rossen: That's different
04:55:08 [fantasai]
Rossen: There's “high contrast” which could be user-defined, e.g. yellow and black
04:55:18 [fantasai]
Rossen: There are themes, dark theme and light theme, and blue theme, etc.
04:55:21 [fantasai]
Rossen: Nothing to do with conrast
04:55:27 [fantasai]
Rossen: Can have bad contrast with dark theme
04:55:33 [fantasai]
Rossen: they're just dark
04:55:40 [fantasai]
Rossen: What frremy is talking about is high contrast
04:55:46 [fantasai]
Rossen: not about themes
04:56:23 [fantasai]
florian: MS conrast MQ has two options, white-on-black and black-on-white
04:57:08 [fantasai]
florian: Apple has independent control of hgih-contrast vs not and dark bg vs light bg
04:57:30 [fantasai]
Rossen: What we wanted to do in high conrast was to guarantee readability. That's what high-contrast is all about
04:57:38 [fantasai]
Rossen: Had to figure out how to isolate text and make it readable
04:57:44 [fantasai]
Rossen: Make sure it has ghigh contrast, regardless of colors
04:58:03 [fantasai]
Rossen: Two options are white-on-black and black-on-white, nothing to do with dark theme
04:58:22 [fantasai]
florian: I disagree with frremy's statement that this si the smaething as what Apple is doing
04:59:07 [fantasai]
myles: You said high-contrast is a collection of themes and you also talked about how Window shas theming
04:59:16 [fantasai]
myles: You can choose one of the many high contrasts or your own theme but not both?
05:00:25 [fantasai]
iank_ explores the Android Settings men
05:00:27 [fantasai]
menu
05:00:40 [fantasai]
Rossen projects Windows
05:00:49 [fantasai]
Rossen: Here is Edge browser in dark theme
05:00:54 [fantasai]
Rossen: UI of browser is dark
05:01:10 [fantasai]
Rossen: Current theme f windows is dark
05:01:22 [fantasai]
Rossen: In terms of readability, having images with text on top of them is not the best for readability
05:01:39 [fantasai]
Rossen projects browser with dark chrome, but web pages are rendering as normal
05:01:49 [fantasai]
Rossen: If I turn on high contrast
05:02:04 [fantasai]
Rossen: Now what you see is that inside fo the browser, we have applied a numbe rof techniques
05:02:15 [fantasai]
Rossen: Firstly, all fo the UI is in high contrast
05:02:30 [fantasai]
Rossen: This current page, as you can see on the images wher epreviously this text was not high-contrast because on top of the image
05:02:55 [fantasai]
Rossen: Here we compute theb oundign areas of text, and make sure that we have a backing plate that preserves the contrast between the background and the text
05:03:00 [fantasai]
Rossen: This is not observable by the web author
05:03:16 [fantasai]
Rossen: In the past we would strip bgimgaes entirely, b/c we didn't know how to deal with it
05:03:21 [fantasai]
Rossen: but htis is high contrast
05:03:25 [fantasai]
Rossen: So that was high contrast
05:03:30 [fantasai]
Rossen: So themes, are something esparate
05:03:39 [fantasai]
florian: Within constrat, you can pick different styles of high contrast
05:03:57 [fantasai]
Rossen: Right, so I can change the colors instead of having yellow on black, I can flip the colors
05:04:09 [fantasai]
dino: Apple does that, but only for subtitles in videos
05:04:15 [fantasai]
dino: We allow complete customization of captions
05:04:20 [fantasai]
Rossen: We do this for everything
05:05:10 [fantasai]
Rossen: We have predefined high contrast themes, e.g. white on black and black on white
05:05:15 [fantasai]
Rossen: Also can have themes
05:05:25 [fantasai]
Rossen: I can change the UI colors like this
05:05:42 [fantasai]
Rossen: I can change just the borwser theme, even though the OS is dark theme
05:06:16 [heycam]
ScribeNick: heycam
05:06:16 [TabAtkins]
ScribeNice: TabAtkins
05:07:06 [heycam]
dino: do you have any mode to say turn off the transparency [in the panel]?
05:07:12 [heycam]
frremy: yes
05:07:15 [heycam]
dino: in accessibility?
05:07:16 [heycam]
frremy: no
05:07:33 [heycam]
dino: we have that option too, might be worth considering that for a MQ in the future, since some people find that distracting
05:07:44 [fantasai]
q+
05:07:55 [astearns]
ack fantasai
05:07:57 [heycam]
fantasai: I think there's several things here we're talking about
05:07:58 [heycam]
... not the same thing
05:08:11 [heycam]
... 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
05:08:20 [heycam]
... that is outside the scope of what we're doing here
05:08:24 [heycam]
Rossen: that's what I wanted to point out
05:08:38 [heycam]
fantasai: we could make it in scope, if you wanted to try to match the theme, but we're not concerned with that today
05:08:45 [heycam]
... rather cases where the user wants changes in the content of pages
05:08:56 [heycam]
... then there's the request for: I want high constrast, and I want dark or not
05:09:01 [heycam]
... four states possible here
05:09:03 [heycam]
... actually more than that
05:09:21 [heycam]
... two axes here
05:10:09 [heycam]
... (whatever, high constrast, low contrast) x (whatever, light, dark)
05:10:39 [heycam]
... default state is whatever, page shows whatever. "light" would mean force dark backgrounds to be light etc.
05:11:18 [heycam]
... for (whatever, light), you don't care what the contrast is
05:11:41 [heycam]
... Windows doesn't have a (whatever, high constrast)
05:11:43 [heycam]
Rossen: that's not true
05:11:46 [heycam]
... you can choose some colors
05:11:52 [heycam]
fantasai: but you're not responding to what the author said
05:12:05 [heycam]
... there's no setting that says I see there are white colors on dark bgs
05:12:19 [heycam]
... which tries to detect "is this a dark themed page or light themed page"
05:12:20 [heycam]
Rossen: I agree
05:12:28 [heycam]
... this is how it will be for the forseeable future
05:12:32 [heycam]
astearns: you're talking about forcing things
05:12:37 [heycam]
... I thought we're talking about MQs
05:12:52 [heycam]
... where authors can key off of, and provide a high constrast experience, not forcing something
05:12:55 [heycam]
... if they're cared to provide one
05:12:58 [heycam]
fantasai: that's separate
05:13:10 [heycam]
Rossen: what francois was trying to describe is available
05:13:36 [heycam]
... currently we provide MQ to say y/n for high-contrast. and for the two default themes, light or dark, what it is
05:13:55 [heycam]
florian: when you say "y", in your MQ, you have something to let the author know high contrast has been forced with some colors
05:14:09 [heycam]
... fantasai is asking about a way with MQ to know if the page is forced constrast with its existing page colors
05:14:11 [heycam]
Rossen: of course not
05:14:35 [myles]
Q+
05:14:44 [heycam]
chris_: [demos what Android does]
05:14:59 [heycam]
... has a Negative Colors option
05:15:04 [heycam]
dino: we have a MQ for that
05:15:09 [heycam]
... similar to the color-invert stuff
05:15:17 [heycam]
chris_: and there's a color lens thing
05:15:32 [heycam]
... lastly, color adjustment for different color blindness
05:15:50 [astearns]
ack myles
05:15:56 [heycam]
myles: I have a question about Edge's MQs
05:16:07 [heycam]
myles: I turn on high constrast on Windows
05:16:13 [heycam]
... web page has a MQ that matches that
05:16:21 [heycam]
... in the MQ that says make text blue, whatever
05:16:34 [heycam]
... does Edge then take that as a signal the web page is handling high constrast itself? and the UA doesn't need to do anything?
05:16:54 [heycam]
Rossen: basically what was mentioned this moring, we have a property that lets you opt out an element and its subtree, from high constrast imposed by the OS
05:17:01 [heycam]
... for that particular element and its subtree, you can define whatever colors you want
05:17:08 [heycam]
... if you want to guarantee high constrast go ahead and do it
05:17:09 [heycam]
myles: got it
05:17:50 [heycam]
Rossen: if it's one the two default high constraints options, black on white, white on black, if you can use a MQ to handle it yourself
05:18:17 [heycam]
myles: is it possible to use that property to turn off high constrast handling outside the MQ?
05:18:19 [heycam]
Rossen: yes
05:18:56 [heycam]
florian: we have the thing Apple brought, is different from this
05:19:05 [heycam]
... because the Windows mode is about forcing the page into one of several high constrast modes
05:19:15 [heycam]
... and letting the author detect this has happend, and through the property let the author opt out
05:19:30 [heycam]
... the thing Apple brought is not detecting it has forced high constrast, but the user requested the page does it to itself
05:19:44 [heycam]
frremy: sure
05:20:02 [heycam]
Rossen: so your assertion is that the high constrast mode will by default never apply to content, unless the content decides yeah I'll do it
05:20:09 [heycam]
dino: for Apple, yes, we don't force high constrast on any content
05:20:20 [heycam]
florian: there are multiple types of high constrast. some are preferences, some are enforced
05:20:25 [heycam]
... which you may be able to opt out or not
05:20:48 [heycam]
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
05:21:00 [heycam]
... we're not going to specify anything that says "here's what happens when a browser forces changes on content"
05:21:02 [fantasai]
Chart on the board: x-axis has whatever | forced high-contrast | forced low-contrast | prefers high-contrast | prefers low-contrast
05:21:16 [fantasai]
y-axis has whatever | forced light | forced dark | prefers light | prefers dark
05:21:25 [heycam]
... the only thing we can do is provide a MQ that says the user prefers a certain high constrast scenario, or that your content decisions have been hijacked by the UA
05:21:27 [heycam]
dino: I agree
05:21:32 [heycam]
... and our request is only for the former
05:21:40 [heycam]
... we just want the user to indicate to the dev of the page they've made a preference decision
05:21:56 [heycam]
... 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
05:22:19 [heycam]
florian: I was also thinking that combinations of preferences is easier to handle
05:22:28 [heycam]
florian: the MS things are reasonable but more complex
05:22:47 [heycam]
... I tried to devise a single MQ query that dealt with all of that, preferences and enforcements
05:22:56 [heycam]
... so I suggest we don't try to solve all these with the one MQ
05:22:59 [heycam]
... the preference thing is simple
05:23:01 [myles]
Q+
05:23:06 [heycam]
... the MS is not as simple, we should solve them separately
05:23:22 [heycam]
... exactly what the page should do if force high constrast and prefer low constrast... shouldn't be exposed to the page
05:23:24 [astearns]
ack myles
05:23:31 [heycam]
myles: I understand there are these two ideas how to implement these features
05:23:36 [heycam]
... is MS making a proposal to standarized their way?
05:23:39 [heycam]
Rossen: we made this a long time ago
05:23:44 [heycam]
astearns: but it's not the currenty issue
05:23:50 [heycam]
frremy: we'd be find having a pref to high constrast
05:24:04 [heycam]
frremy: if we force high constrats the user prefers constrast
05:24:14 [heycam]
... if the user forces high constrast they prefer high constrast
05:24:27 [skk]
Current description on the board: http://www.tsukune.org/skk/tmp/mq.jpg
05:24:35 [heycam]
TabAtkins: what do you think people will do when the MQ is true? prefer high constrast true?
05:24:41 [heycam]
frremy: make it high consrast
05:24:47 [heycam]
TabAtkins: but it's already happened by the UA
05:25:07 [heycam]
myles: he is imagining the content would turn on the property to say "don't do high constrast" and do it themselves
05:25:18 [heycam]
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
05:25:21 [heycam]
... it will work
05:25:27 [heycam]
... if the define everything for prefer, it'll work
05:25:30 [heycam]
florian: in that direction it works
05:25:42 [heycam]
... if the page has been devised with Apple semantics in mind, and the browser does what you says, it'll work.
05:26:31 [heycam]
... if it has been designed for Edge design, assumes that prefers high constrats means I've been forced, so I should do nothing, if you run it in Safari the page won't do it
05:26:39 [heycam]
myles: if the page will do nothing why would it have this MQ
05:26:44 [heycam]
florian: it would turn off some subtle things?
05:26:50 [heycam]
frremy: this is not worse
05:27:07 [heycam]
fantasai: [whiteboard, chart of different combinations of preferences and forcing]
05:27:19 [heycam]
... you can get all the info you want on what kind of constrast you like or are forced into
05:27:49 [heycam]
... there really seems to be two sets of prefs
05:27:57 [heycam]
... one is about constrast, one is about light on dark and vv
05:28:06 [heycam]
... the MS MQ mixes them into the same thing
05:28:12 [heycam]
... you can have no pref, but also pref for high constrast
05:28:20 [heycam]
... or prefer high constrast, or I've been forced into high constrast
05:28:27 [heycam]
... you can treat them the same or distinct, as an author
05:28:43 [heycam]
... in terms of whether you're forced into dark on light or vv, then having a brightness preferecne will tell you which one you're in already
05:28:53 [heycam]
... these are MQ values I've written
05:28:59 [heycam]
frremy: I would be find without these four values
05:29:12 [heycam]
s/four/force/
05:29:21 [heycam]
... you can use the property to opt out of them
05:29:28 [heycam]
frremy: if people want to know about them they can use the MQs
05:29:35 [heycam]
florian: MSDN says the high constrast MQ has been removed
05:29:37 [heycam]
Rossen: that's wrong
05:29:50 [skk]
fantasai's description: http://www.tsukune.org/skk/tmp/mq2.jpg
05:29:52 [heycam]
fantasai: frremy your suggestion someone doing the same as MS must create their own vendor specific features to interop with you?
05:30:00 [heycam]
frremy: there is no browser who wants to match with us right now
05:30:07 [heycam]
astearns: if they want to we can bring something to the group
05:30:17 [heycam]
fantasai: we have to standardize their extensions with their syntax
05:30:24 [heycam]
dbaron: interoperate with what aspect of what MS does?
05:30:37 [heycam]
... Gecko has certainly to reacted to windows high constrast theme settings in various ways, probably differently from Edge
05:30:41 [heycam]
... it doesn't override a lot of colors
05:30:49 [heycam]
emilio: we disable alpha colors
05:30:57 [heycam]
astearns: my suggestion is, we've had a discussion, put it into the issue
05:31:02 [emilio]
s/alpha/cauthor
05:31:06 [heycam]
... sounds like we do want these MQs in some form
05:31:11 [emilio]
s/cauthor/author :)
05:31:13 [heycam]
... and then come back to it at a later meeting
05:31:59 [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)
05:32:20 [heycam]
dino: one point, I don't know if we need a prefers-contrast:low
05:32:33 [heycam]
Rossen: actually there is a dyslexia adaptation ...
05:33:09 [heycam]
florian: we described the way you react to high constrast 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 constrast, [...]
05:33:14 [heycam]
Rossen: if you're responsibel you will query the colors
05:33:16 [heycam]
fantasai: you can't do that
05:33:18 [heycam]
Rossen: you can
05:33:22 [heycam]
fantasai: not in a x platform way
05:33:50 [heycam]
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...
05:33:55 [heycam]
fantasai: I just put that up because I needed a word
05:34:04 [heycam]
florian: I would go with something like "color theme", but that might be confused with UI theme...
05:34:08 [heycam]
... preferred color scheme?
05:34:12 [heycam]
fantasai: it's about the content
05:34:27 [heycam]
... there's the theming scheme, which we might expose at some point in the future, and the prefers light vs dark
05:35:10 [heycam]
<br type="afternoon-tea">
05:35:29 [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
05:36:32 [myles_]
myles_ has joined #css
05:42:50 [stryx`]
stryx` has joined #css
05:52:47 [fantasai]
alternately prefers-contrast: none | high | low | forced
05:52:57 [fantasai]
or prefers-contrast: none | [ high | low ] || forced
05:53:20 [astearns]
not sure preferring no contrast is a thing
05:56:41 [astearns]
topic: end
05:56:49 [astearns]
ah, no issue
05:57:02 [fantasai]
lol
05:57:26 [fantasai]
Florian says the actual keyword for these things is no-preferences to avoid such nonsense :)
05:59:37 [myles]
myles has joined #css
06:00:25 [heycam]
heycam has joined #css
06:01:39 [heycam]
Topic: prefers-reducued-data MQ
06:01:47 [heycam]
github: https://github.com/w3c/csswg-drafts/issues/2370
06:02:04 [heycam]
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
06:02:13 [heycam]
... which informs the web server that you would prefer lightweight content
06:02:19 [heycam]
... there has been a suggestion to have a MQ to match that
06:02:33 [heycam]
... in the same circumstances, the page author would also know that the user may be directly / through some heuristic, prefers some lightweight content
06:02:37 [heycam]
... images as a bg instead of a video, e.g.
06:02:40 [heycam]
... seems reasonable to me
06:02:45 [heycam]
myles: how does chrome know when to send the header?
06:02:51 [heycam]
philipwalton: I think it's from the OS on Android
06:03:05 [heycam]
iank_: there's a setting Chrome, prefer lightweight data, then we send everything through potentially an HTTP proxy
06:03:09 [heycam]
... few other things as well
06:03:21 [heycam]
florian: is it user triggered
06:03:21 [heycam]
iank_: yes
06:03:29 [heycam]
... but I'm not sure, might be varied on country basis
06:03:47 [heycam]
... we run HTTP proxies where we'll send traffic through that, then do a bunch of compression for the user
06:03:52 [heycam]
myles: so the proxy might turn on the header?
06:03:53 [heycam]
iank_: no
06:04:02 [heycam]
... the proxy is one of the side effects from turning on this option
06:04:18 [heycam]
... and I think the bit of information that we give devs is on navigator.connection.saveData
06:04:26 [heycam]
philipwalton: it's a client hints header, in the clients hint spec
06:04:39 [heycam]
florian: somebody proposed to detect this via MQ
06:04:41 [heycam]
fantasai: seems reasonable to me
06:04:51 [heycam]
astearns: is that header, are there plans for other browsers to implement this?
06:04:55 [heycam]
fantasai: wht values does the header have?
06:05:00 [heycam]
philipwalton: I think it's just a boolean at this point
06:05:08 [heycam]
... but the spec is written in a way that it could apply additional values
06:05:35 [heycam]
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
06:05:37 [astearns]
http://httpwg.org/http-extensions/client-hints.html#save-data
06:06:06 [heycam]
iank_: quickly looking through the additional things we expose, we also give as headers (what we think is the effective) roundtrip time
06:06:12 [heycam]
... an estimate of the downlink speed
06:06:21 [heycam]
philipwalton: and effective connection type
06:06:25 [heycam]
heycam: mobile vs fixed?
06:06:31 [heycam]
iank_: 3g, 4g, slow 2g, ....
06:06:36 [heycam]
florian: don't think we'd expose all that
06:06:38 [heycam]
... via the MQ
06:06:57 [heycam]
... having something that can be used in a boolean context, where one case is no preference, and may have other "yes please" levels
06:07:10 [heycam]
iank_: one thing I'd like to see here is use cases for where it's used in CSS
06:07:23 [heycam]
florian: use image bg instead of video bg
06:07:33 [heycam]
iank_: do that with script
06:07:37 [heycam]
philipwalton: 1x vs 2x?
06:07:41 [heycam]
florian: browser should do that already
06:08:06 [heycam]
[side discussion about font-display:optional]
06:08:30 [heycam]
philipwalton: with save data, 1x vs 2x, could be your device supports 2x but you only want a smaller version of the image
06:08:39 [heycam]
florian: mostly you should not be using resolution MQ feature, but instead srcset
06:08:48 [heycam]
... then the load data preference could influence that
06:09:01 [heycam]
s/srcset/image-set/
06:09:20 [heycam]
myles: maybe terribly idea, can we extend that mechanism to allow switching between videos and images as backgrounds, instead of a MQ?
06:09:26 [heycam]
fantasai: MQs are not only used in CSS
06:10:01 [heycam]
emilio: responsive images
06:10:08 [heycam]
iank_: I'm not saying no, but I want to see web developer demand for this
06:10:12 [heycam]
astearns: that's the general tone I'm hearing
06:10:30 [heycam]
... 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
06:10:32 [heycam]
florian: sounds ok
06:11:02 [heycam]
koji: this is an Android OS setting
06:11:07 [heycam]
ericwilligers: it's both Android and a Chrome setting
06:11:56 [heycam]
Topic: porting media groups
06:12:04 [heycam]
github: https://github.com/w3c/csswg-drafts/issues/2413
06:12:15 [heycam]
florian: CSS 2.1 has a section, media groups, which decribes what media groups are
06:12:19 [heycam]
... visual, interactive, static, things like this
06:12:27 [heycam]
... it doesn't define what they are, just lists what exists
06:12:33 [heycam]
... then says visual is print or screen or tv or handheld
06:12:42 [heycam]
... interactive is print or screen or somet tvs
06:12:49 [heycam]
... this is used in the propdef for every property definition
06:12:52 [heycam]
... Media: Visual
06:12:57 [heycam]
... fantasai suggested porting this to something else
06:13:01 [heycam]
... but I don't think it does anything useful
06:13:13 [heycam]
... unllike the Applies line, which says browsers will do nothing on some elements
06:13:22 [heycam]
... this basically says "on some browsers this property won't be supported"
06:13:26 [heycam]
... they're insufficiently described
06:13:37 [heycam]
... the way we've used the Media line, 95% say Visual, the few that say something else are using it wrong
06:13:43 [heycam]
... I suggest we stop having a Media line
06:14:01 [heycam]
dbaron: I think the reality is there's been not a lot of implementation of CSS for anything other than visual media
06:14:16 [heycam]
... and what implementation there has been hasn't provided feedback to the WG, so the specs don't account for it well
06:14:26 [heycam]
florian: the animations and transitions properties claim to work on interatctive media, not visual
06:14:46 [heycam]
... if you look at how interactie is defined, it would seem to mean the transitions and aanimations work on a kindle with buttons, but not on a digital signage screen with no buttons
06:14:47 [heycam]
... which is wrong
06:14:54 [heycam]
... so we could define it in a way that's correct
06:14:58 [heycam]
... but it's still not useful
06:15:00 [heycam]
frremy: makes sense to me
06:15:18 [heycam]
myles: is it valuable to say you can't animate on a piece of paper?
06:16:05 [heycam]
RESOLVED: Remove Media line from all propdef tables
06:17:16 [heycam]
Topic: <mf-range>
06:17:18 [heycam]
github: https://github.com/w3c/csswg-drafts/issues/2791
06:17:32 [heycam]
florian: (width < 100px) is allowed in MQ L4
06:17:52 [heycam]
... it also lets you do (100px > width) which people don't care about strongly
06:18:08 [heycam]
... but they also let you do (50px < width < 100px)
06:18:13 [heycam]
... Firefox has implemented the first one
06:18:20 [heycam]
... and claimed that the second two are more difficult to implement
06:18:28 [heycam]
emilio: it's not that I'd like not to, it's that it's somewhat annoying
06:18:59 [heycam]
... the way we parts 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
06:19:05 [heycam]
... and identifiers can also be media feature values
06:19:27 [heycam]
... 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, biut...
06:19:38 [heycam]
florian: I think the third option is nice
06:20:02 [heycam]
... Tab'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
06:20:16 [heycam]
emilio: I think if we're going to keep the last one, we may as well keep the previous one
06:20:20 [heycam]
astearns: doesn't make it much easier
06:20:42 [heycam]
astearns: are you the only ones implementing this?
06:20:45 [heycam]
emilio: I think so, so far
06:20:49 [heycam]
frremy: that was two weeks ago
06:21:24 [heycam]
ericwilligers: I think this is clear:
06:21:26 [heycam]
width < 100
06:21:28 [heycam]
100 <= width < 200
06:21:29 [heycam]
200 < width
06:21:35 [heycam]
ericwilligers: with the last one the width on the RHS
06:21:50 [heycam]
florian: if removing the middle one was a signficiant simplification, we can do it, but sounds like not
06:22:00 [heycam]
RESOLVED: Close this issue with no change
06:22:13 [astearns]
topic:end
06:22:41 [heycam]
Topic: porting media groups
06:22:45 [heycam]
github: https://github.com/w3c/csswg-drafts/issues/2413
06:22:55 [heycam]
fantasai: I ran a grep through the tree
06:23:00 [heycam]
... almost everything is Visual, some exceptiosn
06:23:05 [heycam]
... interactive vs not is not interesting
06:23:17 [heycam]
... but we distinguish between CSS props that shuld affect the accessibility tree, and the ones that shouldn't
06:23:19 [heycam]
... or don't
06:23:26 [heycam]
... content prop affects what shows up to a screen reader
06:23:28 [heycam]
... display does
06:23:35 [heycam]
astearns: how is that expressed?
06:23:38 [heycam]
florian: by Media: all
06:23:49 [heycam]
astearns: are we consistent about that?
06:23:51 [heycam]
fantasai: yes
06:24:00 [heycam]
... props that should add or remove content from the a11y tool
06:24:14 [heycam]
... it's an indicator to the screen reader as to what content should be added or skipped
06:24:23 [heycam]
florian: I think it's not about screen readers
06:24:27 [heycam]
... it's about audio rendering
06:24:46 [heycam]
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
06:24:54 [heycam]
dbaron: I think if that was the intent of the spec, I suspect most implementors missed it
06:25:00 [heycam]
... I think it would be good to have the wording in some other way
06:25:09 [heycam]
astearns: I think it would be an improvement to be explicit, rather than hide it here
06:25:23 [heycam]
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
06:25:41 [heycam]
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
06:25:44 [heycam]
astearns: it should be more explicit
06:25:50 [heycam]
... "such as, screen readers"
06:25:50 [heycam]
florian: no
06:25:54 [heycam]
... they don't work like that
06:25:56 [heycam]
... they're a visual media
06:26:02 [heycam]
fantasai: but they're also not handling gencon properly
06:26:04 [heycam]
Rossen: they do
06:26:09 [heycam]
frremy: in Edge it works perfectly
06:26:18 [heycam]
fantasai: but it is a common bug
06:26:52 [heycam]
frremy: the content thing is defined precisely in the ARIA specs
06:26:58 [heycam]
... I don't believe we need to say anything in the CSS specs
06:27:09 [heycam]
... it says gencon should be exposed
06:27:15 [heycam]
... but it shouldn't require any specific wording
06:27:36 [heycam]
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
06:27:48 [heycam]
... not specifically to a11y, e.g. audio rendering without a screen reader, don't forget this property
06:27:52 [heycam]
astearns: would that be enough?
06:27:53 [heycam]
dbaron: sure
06:28:12 [heycam]
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
06:28:16 [heycam]
... but it takes up a lot of space
06:28:22 [heycam]
... removing from the propdef table is a benefit overall
06:28:39 [heycam]
... we should add a statement explaining normatively that CSS requires these to work
06:28:54 [heycam]
... we're defining what the properties mean and how they're interpreted, ARIA then uses that
06:29:21 [heycam]
RESOLVED: Add a normative statement for properties that say "Media: all" explaining what "Media: all" meant.
06:30:00 [florian]
ScribeNick: Florian
06:30:22 [florian]
Topic: Bikeshed the 0 specificity alternative to :matches()
06:30:38 [leaverou]
Table: https://github.com/w3c/csswg-drafts/issues/2143#issuecomment-360586470
06:31:09 [dbaron]
github: https://github.com/w3c/csswg-drafts/issues/2143#issuecomment-360586470
06:31:41 [florian]
ericwilligers: [projets the issue]
06:32:06 [florian]
fantasai: if we have :not and :is, they should have the same specificity
06:33:00 [florian]
ericwilligers: matches has changed specificity recently
06:33:06 [florian]
fantasai: that's out of scope here
06:33:31 [florian]
ericwilligers: :when was time based, so I proposed :where, haven't heard back
06:34:04 [florian]
astearns: does anyone have problem with :where ?
06:34:23 [florian]
leaverou: has does that avoid the problems that :is has?
06:34:42 [florian]
fantasai: because :is and :not need to be opposite
06:35:01 [florian]
leaverou: how about having :is-not be the opposite of :is
06:35:20 [florian]
all: Noooo
06:35:34 [florian]
frremy: :where works for me
06:35:45 [florian]
ericwilligers: has to combine well with :not()
06:36:11 [florian]
leaverou: why can't we change :matches? it has shipped, but nobody uses it yet
06:36:26 [florian]
astearns: we've discussed doing it several time, and failed to reach consensus
06:36:58 [florian]
fantasai: lea propose to just change the specificity of :matches, and add a new one for the other specificity
06:37:11 [florian]
frremy: why use the :match name at all, it's a bad name
06:37:18 [florian]
leaverou: we're stuck with it anyway
06:38:02 [florian]
fantasai: I want a short list so that we can think about it
06:39:10 [florian]
leaverou: would you object to :is if it did what matches currently does, and :match() is the 0 specificity one?
06:39:13 [florian]
fantasai: no, I would not
06:39:41 [florian]
leaverou: what if we just have one, with an argument for specificity
06:39:44 [florian]
fantasai: too confusing
06:40:41 [florian]
shane: :where makes sense for people who have used SQL, but for others it is confusing, and seems to involve position
06:41:04 [dbaron]
Whiteboard:
06:41:40 [florian]
leaverou: I find SQL readable, but that's because it's a full sentence, which isn't the case in css
06:41:49 [florian]
fantasai: I like 2 and 4
06:41:52 [Rossen]
Here are the options
06:41:56 [dbaron]
1. :is()
06:41:56 [dbaron]
2. :matches() + replace existing :matches() with :is()
06:42:00 [Rossen]
1. :is()
06:42:13 [Rossen]
3. :if()
06:42:19 [Rossen]
4. :also()
06:42:25 [Rossen]
5. :where()
06:42:26 [florian]
frremy: :and means nothing to me, all selectors already imply that
06:42:30 [Rossen]
6. :selects()
06:42:47 [florian]
fantasai: yes, but :also doesn't have that implication
06:42:52 [florian]
leaverou: in favor of :also
06:43:22 [florian]
Rossen: [makes funny inaudible jokes]
06:43:33 [florian]
dbaron: we have an html element called select
06:43:45 [florian]
Rossen: let's start removing
06:43:49 [florian]
Rossen: kill select
06:44:05 [florian]
ericwilligers: I think we can also kill :if
06:44:18 [florian]
Rossen: :if would need an :else
06:44:21 [florian]
frremy: why?
06:46:01 [Rossen]
7. :also() + replace existing :matches() with :is()
06:46:10 [florian]
leaverou: I'd like 7
06:46:26 [florian]
frremy: this was called that way because the DOM API is called that
06:46:40 [florian]
fantasai: actually, it's very old and it's the other way around
06:46:57 [florian]
ericwilligers: it has been in webkit for a long time
06:47:06 [florian]
astearns: how much web content uses :matches?
06:47:17 [florian]
iank_: not a lot, looking at usecounter
06:47:37 [florian]
ericwilligers: usecounter may be wrong
06:47:40 [dbaron]
"the other way around" was in reference to original name being :any or :matches.
06:48:24 [florian]
Rossen: is either 2 or 7 an option? they involve changing :matches. webkit people, can we do that?
06:48:37 [florian]
myles: we could
06:49:13 [florian]
myles: we would be moderately interested in updating, but it's low priority
06:49:31 [florian]
dino: why ?
06:50:30 [florian]
fantasai: because a best named proposal otherwise is :is, but it is bad if it's specificity doesn't match :not
06:50:55 [florian]
fantasai: so we could change :matches to be the 0 specificity one, freeing the room for :is to do what :matches does now
06:51:31 [florian]
leaverou: maybe we can resolve on that in parts
06:51:38 [florian]
fantasai: removing option 1
06:51:58 [dbaron]
I implemented :-moz-any() in Gecko in 2010 in https://bugzilla.mozilla.org/show_bug.cgi?id=544834
06:52:28 [florian]
fantasai: the web compat impact of 2 and 7 are different
06:52:57 [florian]
ericwilligers: does anyone want 2?
06:53:00 [florian]
fantasai: removing 2
06:53:20 [florian]
[lots of people]: I don't like also.
06:53:35 [florian]
[lots of people]: [lots of jokes]
06:53:40 [florian]
leaverou: what's wrong with :also ?
06:54:04 [Rossen]
:soso()
06:54:14 [florian]
dbaron: :also comes after something, but it doesn't come after anything particular
06:54:49 [florian]
Rossen: agreed (with a pun)
06:55:12 [florian]
ericwilligers: :where implies position OR situation
06:55:22 [florian]
fantasai: does :where not have the same problem as :also?
06:55:35 [florian]
fantasai: :matches does not have that problem
06:55:58 [florian]
frremy: I prefer :where and :if, and :if makes a lot of sense when you read it
06:56:26 [dbaron]
The thing I was talking about was called a "simple selector" in CSS 2, a "sequence of simple selectors" in selectors-3, and a "compound selector" in selectors-4.
06:56:28 [florian]
astearns: :if clashes with JS?
06:56:38 [florian]
[lots of people]: it doesn't
06:57:04 [florian]
...: :if calls for :else
06:57:11 [florian]
...: it doesn't
06:57:51 [florian]
philipwalton: ??????
06:58:06 [florian]
heycam: one option was to have a specificity parameter in :matches
06:58:45 [florian]
astearns: we have agreed that renaming :matches is not necessary to solve this
06:59:24 [dbaron]
s/??????/was the reason for doing this that the specificity was bad, or to give control over specificity? [answer: latter] It seems like a pseudo-class isn't the right tool for that, but I guess that's the right tool for the job./
06:59:40 [florian]
astearns: we rejected some of the options, we should make a smaller list of plausible
06:59:59 [florian]
fantasai: we should make a strawpoll, and then call for objections on the most popular
07:00:18 [florian]
fantasai: :if gets 7 votes
07:00:37 [florian]
fantasai: :also gets 1.5votes
07:01:03 [florian]
fantasai: :where gets 7 votes
07:01:15 [florian]
astearns: objections to :if ?
07:01:38 [florian]
astearns: objections to :where ?
07:01:52 [florian]
leaverou, fantasai, iank_: strong reservations
07:02:11 [tantek]
let's strawpoll if vs where!
07:02:54 [florian]
astearns: I am not declaring consensus
07:03:34 [florian]
astearns: we will ask outsiders about :if vs :where
07:04:03 [florian]
topic: getComputedStyles and shorthands
07:04:08 [florian]
github: https://github.com/w3c/csswg-drafts/issues/2529
07:05:00 [florian]
emilio: FF and Edge only support getComputedStyle on shorthands that used to be longhands, Blink supports more
07:05:31 [florian]
emilio: shorthands in the computed style object are exposed as properties
07:05:42 [florian]
emilio: I want to know what people want. Fine with changing, but it's work
07:05:58 [florian]
ericwilligers: if it was a longhand, it would serialize
07:06:05 [florian]
TabAtkins: it needs to
07:06:23 [florian]
emilio: there are bugs on the grid shorthands
07:06:43 [myles]
myles has joined #css
07:06:54 [florian]
emilio: People have argued various ways.
07:07:10 [florian]
TabAtkins: this is an obvious forward compat mistake
07:07:26 [florian]
TabAtkins: all properties from now on should support it
07:07:58 [florian]
TabAtkins: and if we can, all the legacy shorthands should as well, when a value can be constructed if it's not a a webcompat problem
07:08:04 [florian]
TabAtkins: which doesn't seem to be the case
07:08:19 [florian]
dbaron: if it's not possible to represent, then we have to go for empty string
07:08:22 [florian]
TabAtkins: that's fine
07:08:41 [TabAtkins]
It's still forward-compatible; adding a new property to the shorthand will never make it, by *default*, stop serializing
07:08:59 [florian]
emilio: there's also the question of computed values vs resolved values
07:09:36 [florian]
heycam: it would be very weird if the longhands resolved but the shorthands didn't, so we should match
07:10:02 [florian]
heycam: Edge is the only other browser not doing it. So Edge?
07:10:59 [florian]
emilio: Edge, are you OK with doing it? the only ones you have on top of used-to-be-longhands are grid properties.
07:11:36 [florian]
Rossen: I don't believe I've seen compat issues. I am reluctant to write a bunch of code for something that's not needed.
07:11:43 [florian]
TabAtkins: going forward, we need
07:12:00 [florian]
s/we need/we need to./
07:12:33 [florian]
TabAtkins: for legacy props, it wouldn't be the end of the world if we didn't do it, but it would be inconsistant and unfortunate.
07:12:51 [florian]
emilio: It can be done quite easily for lots of properties
07:13:59 [florian]
Florian: can we resolve to do on all, even if priorities means it might take a while
07:14:20 [florian]
Rossen: we need consistency, so let's have it everywhere.
07:15:43 [florian]
RESOLVED: all shorthands must show up in getComputedStyles
07:16:36 [florian]
xidorn: I wonder if you should see the shorthands in the iterator
07:17:22 [florian]
xidorn: I think there's a usecase for copying computed values from one element to another, and they just iterate through
07:17:32 [florian]
myles: This should be a separate issue.
07:17:39 [Ms2ger]
Ms2ger has joined #css
07:17:50 [florian]
[mumble mumble]
07:18:17 [florian]
topic: What should getComputedStyle return for an element which isn't in the flat tree?
07:18:27 [florian]
github: https://github.com/w3c/csswg-drafts/issues/1964
07:18:48 [florian]
emilio: frremy added that, but we already resolved
07:18:59 [florian]
frremy: it's a bot bug, nothing to talk about
07:19:03 [emilio]
Was resolved on https://github.com/w3c/csswg-drafts/issues/1548#issuecomment-380383455
07:19:03 [astearns]
topic: none
07:19:35 [florian]
Topic: Consider disallowing NULL code points in stylesheets
07:19:42 [florian]
github: https://github.com/w3c/csswg-drafts/issues/2757
07:19:46 [emilio]
myles: lol
07:20:05 [florian]
TabAtkins: [trying to find the original bug]
07:20:50 [florian]
Rossen: what's left to do?
07:21:09 [florian]
Florian: for TabAtkins to argue his case against our previous almost-consensus
07:21:31 [florian]
github: none
07:21:48 [florian]
topic: css nesting
07:21:54 [florian]
github: https://github.com/w3c/csswg-drafts/issues/2701
07:22:51 [florian]
TabAtkins: we tried to discuss that a while back, but didn't have time to conclude. Should we rediscuss, or re-resolve
07:22:55 [TabAtkins]
https://tabatkins.github.io/specs/css-nesting/
07:22:57 [florian]
myles: I want an overview
07:23:39 [florian]
TabAtkins: nesting style rules is a common request, and a feature of every css preporsessor in existence
07:23:56 [florian]
TabAtkins: and one of their most popular feature
07:24:12 [florian]
TabAtkins: makes stylesheets much easier to maintain
07:24:36 [florian]
TabAtkins: it is purely syntatic sugar, but is worth covering because of the huge demand
07:24:55 [florian]
TabAtkins: the way they're done in preprocessors are ambiguous with properties
07:25:15 [florian]
TabAtkins: My propose spec disambiguate with by using &
07:25:53 [florian]
TabAtkins: you can use & at the front, and if you want it elsewhere, you can use @nest to keep things unambiguous
07:26:10 [TabAtkins]
a:hover ....
07:26:39 [florian]
TabAtkins: the above looks like a "a" property with a "hover" value
07:26:54 [frremy]
q+
07:27:09 [florian]
TabAtkins: CSS parsing only requires a finite amount of lookahead, and we'd like to keep it that way
07:27:38 [florian]
leaverou: isn't it only a problem when the tag selector is the first part of the selector
07:27:54 [florian]
TabAtkins: I don't like that because it's not obvious, and hard to teach
07:28:09 [Rossen]
q?
07:28:20 [florian]
fantasai: you could pick a random character to start any rule with
07:28:24 [astearns]
ack frremy
07:28:30 [fantasai]
s/any/every/
07:28:40 [florian]
TabAtkins: yes, that's what "@nest" do
07:29:05 [florian]
frremy: replace @nest with &
07:29:12 [TabAtkins]
& &.foo {...}{
07:29:13 [florian]
TabAtkins: it's ambiguous
07:29:27 [heycam]
q+
07:29:33 [florian]
Florian: I don't like it, @nest is nicer
07:29:48 [florian]
leaverou: that would be hard to read
07:29:49 [frremy]
&:hover
07:30:00 [frremy]
& > span > &
07:30:02 [florian]
frremy: you only include it if needed
07:30:27 [TabAtkins]
& span:not(&) {...}
07:30:29 [Rossen]
q?
07:30:30 [florian]
TabAtkins: other bad example ^
07:31:14 [astearns]
ack heycam
07:31:22 [myles]
Q+
07:31:32 [frremy]
(I was convinced by the clarification that the & can be replaced more than one in the selector , which I didn't know)
07:31:53 [myles]
-q
07:31:58 [florian]
heycam: can we require starting with a combinator (and use an explicit descendant combinator)
07:32:17 [florian]
TabAtkins: doesn't solve it for & in the middle
07:33:12 [florian]
fantasai: if you use @nest, use it everywhere
07:33:16 [florian]
TabAtkins: too verbose
07:33:22 [florian]
heycam: @nest introduces a block?
07:33:47 [florian]
leaverou: ????
07:33:49 [fantasai]
s/everywhere/everywhere. If you think that's too verbose, choose a different disambiguator. Alternating between using @nest and not is not great/
07:34:02 [florian]
TabAtkins: very hard to express in grammars
07:34:26 [florian]
TabAtkins: in the most common cases, stating with an ampersand is short, which is important
07:34:50 [florian]
fantasai: just use something shorter than @nest
07:35:08 [fantasai]
s/just//
07:35:08 [florian]
Florian, fantasai: how about naked @
07:35:49 [myles_]
myles_ has joined #css
07:36:02 [florian]
myles: we don't have to bikeshed the syntax if we're just talking about adopting the module
07:36:03 [leaverou]
fantasai: or naked & to introduce a nested block? /* just throwing ideas! */
07:36:05 [florian]
astearns: objections?
07:36:16 [fantasai]
s/fantasai:/fantasai,/
07:36:21 [florian]
frremy: does it need to be a new module?
07:36:30 [florian]
florian: no, but it's nice that way
07:36:35 [florian]
astearns: objections?
07:36:49 [florian]
fantasai: ED is fine, want to bikeshed the syntax before FPWD
07:37:10 [fantasai]
fantasai: Seems like nobody is really happy with the spec as-i
07:37:15 [fantasai]
s/as-i/as-is/
07:37:34 [florian]
xidorn: no objection, but my concern is that it expands in some cases into :matches() like things
07:37:41 [florian]
xidorn: and that's hard to optimize
07:38:11 [florian]
TabAtkins: you can expand them out fully
07:38:18 [florian]
emilio: how about the OM?
07:38:25 [florian]
TabAtkins: not expanded in the OM
07:38:50 [florian]
xidorn: that makes it hard
07:39:06 [fantasai]
s/in the OM/in the OM, rules get a .childRules object/
07:39:06 [florian]
xidorn: because of the combinatorial explosion
07:39:22 [florian]
florian: we still have to deal with that in preprocessor generated sylesheets
07:39:39 [fantasai]
ScribeNick: fantasai
07:39:51 [fantasai]
astearns: Hearing no objections to starting work on the module. Hearing a lot of issues against it.
07:40:03 [fantasai]
astearns: Anyone else interested in heping Tab?
07:40:45 [fantasai]
RESOLVED: add css-nesting as an ED, Tab Atkins as editor, file issues until ppl are overall kinda happy with what it's like before we consider FPWD
07:40:54 [fantasai]
Topic: serialization of <position>
07:41:14 [TabAtkins]
The preprocessor features that are :matches()-equivalent explode combinatorially, so the preprocessors trim what they generate. In the common case, nesting expands merely multiplicatively , so they fully expand; so you are already *parsing* a fully-expanded set of selectors.
07:41:27 [ericwilligers]
github: https://github.com/w3c/csswg-drafts/issues/2274
07:41:49 [ericwilligers]
"<position> is always serialized as 2 or 4 values." or "Neither component may be omitted when serializing."
07:42:52 [fantasai]
ericwilligers: I thin we've completely resolved serialization of <position>
07:43:10 [fantasai]
fantasai: We already resolved that <bg-position> should serialize same as <position>
07:43:17 [ericwilligers]
How exactly does "left 10% center" serialize?
07:44:14 [fantasai]
fantasai: Need to resolve that keywords are serialized out in specified value if originally specified as keywords (and not otherwise)
07:45:01 [fantasai]
emilio: In which order?
07:45:07 [fantasai]
ericwilligers: Horizontal first
07:45:11 [fantasai]
emilio: And always both
07:45:16 [fantasai]
ericwilligers: Yes
07:45:45 [fantasai]
dbaron: It feels like this is saying you have to remember the syntax level, but you don't preserve the number of values in the syntax
07:45:52 [fantasai]
dbaron: But you preserve the keywords
07:46:16 [fantasai]
ericwilligers: ...
07:46:23 [fantasai]
ericwilligers: We're talking about specified values only atm
07:46:39 [fantasai]
ericwilligers: Edge sometimes serializes as percentages rather than keywords
07:46:44 [fantasai]
ericwilligers: For certian properties
07:46:56 [fantasai]
https://github.com/w3c/csswg-drafts/issues/2274#issuecomment-402330108
07:47:16 [ericwilligers]
Existing spec: "If only one value is specified, the second value is assumed to be center." "The canonical order when serializing is the horizontal component followed by the vertical component."
07:49:17 [fantasai]
...
07:49:33 [ericwilligers]
https://drafts.csswg.org/css-values/#position
07:49:47 [ericwilligers]
https://drafts.csswg.org/css-backgrounds-3/#propdef-background-position
07:49:57 [fantasai]
astearns: Any objections to specifying that specified values are serialized as keywords if specified as keyword sand percentages if specified as percentages?
07:50:04 [fantasai]
RESOLVED: above
07:50:19 [fantasai]
RESOLVED: Any objections to specifying that specified values are serialized
07:50:19 [fantasai]
as keywords if specified as keyword sand percentages if specified as
07:50:22 [fantasai]
percentages?
07:51:10 [fantasai]
ericwilligers: If 3 values are specified, we'll need to turn into 4 values
07:52:45 [heycam]
ScribeNick: heycam
07:53:29 [heycam]
ericwilligers: : "left 10% right" -> "left 10% right 0%"
07:53:38 [dbaron]
There was a discussion about 'left 1% center" which is apparently no longer a valid <position> but is a <bg-position>.
07:53:46 [heycam]
ericwilligers: "left 10% 20%" -> "left 10% top 20%"
07:54:11 [heycam]
s/"left 10% right"/"left 10% bottom"/
07:54:18 [heycam]
s/"left 10% right 0%"/"left 10% bottom 0%"/
07:54:30 [heycam]
fantasai: if we need a keyword we use top or left, if we need an offset we add a percentage
07:54:33 [heycam]
ericwilligers: plus a weird case for center
07:54:36 [dbaron]
ericwilligers: we can convert 3 values to 4 values by converting "center" to "top 50%", "bottom" to "bottom 0%", and "20%" to "top 20%"
07:54:47 [heycam]
astearns: and there's text in Shapes that does everything you said, except that shapes will convert bottom to top 100%
07:54:58 [heycam]
ericwilligers: we've resolved to remove that text, but I can reuse it
07:55:06 [heycam]
astearns: I don't mind if it stays as bottom or converts to top
07:55:38 [heycam]
fantasai: so left 10% bottom 0% would stay as is, but left 10% bottom would become left 10% top 90%?
07:55:39 [heycam]
astearns: yes
07:55:50 [heycam]
fantasai: if we're preserving the keyword in the case we have the offset, may as well when we don't too
07:56:21 [heycam]
emilio: does everyone support 3 values on background-position?
07:56:23 [heycam]
fantasai: yes
07:56:29 [heycam]
astearns: we ripped it out everywhere we could, but had to leave it there
07:56:38 [heycam]
emilio: ok, I'm fine with that
07:57:45 [heycam]
RESOLVED: For <bg-position>, preserve keywords where we can, center turns to top 50%, and where we need to add a keyword use top/left, where we add an offset, use percentages.
07:58:00 [heycam]
ericwilligers: earlier talking about computed values, I was incorrect to say we never give keywords. we do sometimes!
07:58:03 [heycam]
... but I don't think we should
07:58:10 [heycam]
... I propose for computed values, it's always <length-percentage>
07:58:11 [heycam]
Rossen: or calc()
07:59:54 [heycam]
astearns: so for computed values of <bg-position> and <position>, they are always two <length-percentage> values
08:00:02 [heycam]
... no keywords, calc() if needed
08:00:17 [heycam]
RESOLVED: For computed values of <bg-position> and <position>, they are always two <length-percentage> values.
08:04:23 [dbaron]
github-bot, end topic
08:04:28 [dbaron]
trackbot, end meeting
08:04:28 [trackbot]
Zakim, list attendees
08:04:28 [Zakim]
As of this point the attendees have been tantek
08:04:36 [trackbot]
RRSAgent, please draft minutes
08:04:36 [RRSAgent]
I have made the request to generate https://www.w3.org/2018/07/03-css-minutes.html trackbot
08:04:37 [trackbot]
RRSAgent, bye
08:04:37 [RRSAgent]
I see no action items