<color> in <shadow> should default to currentColor

<myles> Github: https://github.com/w3c/csswg-drafts/issues/2766

<myles> Fantasai: any objections?

<myles> Rossen: We need to make sure the people who care have a chance to look

<myles> xidorn: the issue is that if it isn’t specify, the used color is taken from the current property

<myles> xidorn: I think the text should just be “it defaults to currentColor”

<myles> dbaron: the spec may have evolved from something that was more flexible

<myles> chris: (sarcastically) let’s say it’s user defined

<myles> Rossen: are we okay with the proposed resolution?

<myles> Rossen: any objections? <silence> resolved

RESOLUTION: <color> in <shadow> should default to currentcolor

<myles> chris: There’s also the same problem with drop-shadow as well as shadow

<myles> leaverou: it doesn’t work that way already?

<myles> Rossen: any additional comments?

<myles> Rossen: <silence> Any objections?

RESOLUTION: drop-shadow and shadow will also default to currentColor

Inconsistent position serialization

<myles> Github: https://github.com/w3c/csswg-drafts/issues/2274

<myles> ericwilligers: For one of the properties, the spec is explicit about serialization, and that’s different from all the other ones

<myles> ericwilligers: another inconsistency is that all the browsers behave differently from one another

<myles> ericwilligers: suggestions?

<myles> leaverou: don’t we have a principle that shorter serializations are better?

<myles> TabAtkins: yes

<myles> leaverou: if we follow that, 50% should not be introduced

<myles> leaverou: do that mean if it was specified explicitly, it should be introduced?

<myles> dbaron: there are cases where you do need it to be disambiguated. center 10% and 10% center are different

<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

<myles> ericwilligers: the one that’s different from the others, is that a mistake and they should all the consistent?

<myles> emilio: yes

<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

<myles> emilio: Can we resolve on the special case being removed?

<myles> fantasai: All the cases should be the same

<myles> Rossen: yes

<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”

<myles> fantasai: we’re trying to get rid of 3 values

<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)

<myles> ericwilligers: What about always serialize to a valid <position>

<myles> fantasai: bgposition should not be allowed in serialization

<myles> Rossen: objections?

RESOLUTION: 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.

<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

<myles> fantasai: Should we ask Edge to change? To match everyone else? Or are one-value serializations actually good

<myles> TabAtkins: This decision applies to typed OM too.

<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

<myles> heycam: Is this a general principle? Like pairs of numbers that are coordinates, they should always be serialized as two-values?

<myles> fantasai: I don’t think that’s valuable

<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

<myles> fantasai: a more important reason is the transform-origin syntax, which becomes ambiguous if you only have one value

<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

<myles> fantasai: The proposal: <position> always serializes at least two values

<myles> TabAtkins: I’m down with that

<myles> Rossen: It means some work for us, but ...

<myles> TabAtkins: It means some work for all of us because we’re inconsistent

<myles> Rossen: okay.

RESOLUTION: All the <position> values serialize to at least two values.

<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?

<myles> fantasai: not really

<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

<myles> heycam: I don’t like having to check

<myles> fantasai: Are you volunteering to do the checking?

<myles> heycam: No

<myles> heycam: We should reflect our discussions back in the spec so we don’t have to check

<myles> ericwilligers: We may not be testing in all 4 browsers

<myles> heycam: So tests may serve this purpose?

<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

<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

<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

<myles> ericwilligers: We’re just talking about serialization, not computed value

<myles> emilio: It’s essentially the same thing

<myles> fantasai: yeah

<myles> ericwilligers: We’re talking about specified values, not computed styles

<myles> ericwilligers: Blink would never give you a keyword as a computed value

<myles> Rossen: What are we thinkging about in terms of 4 value serialization?

<myles> Rossen: Should we attempt to do 2 when possible?

<myles> plinss: Turning a non-calc into a calc seems weird

<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

<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

<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

<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

<myles> fantasai: Eric, do you have the test you used for the 4-value syntax?

<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

<myles> ericwilligers: It takes me a while to get results because I use browser stack.

<myles> ericwilligers: If you tell me what you want to know, we can figure it out

<astearns> <position> in basic shapes is paragraph 2 of https://drafts.csswg.org/css-shapes/#basic-shape-serialization

<fantasai> top 10% left 20%

<myles> ericwilligers: With the suggestion that we go down do two unless it introduces a calc, what effect would that be fore background-position?

<myles> Rossen: The minute you have top 10% and then center ..

<myles> ericwilligers: Peopel were saying “we should never ever go to three”

<myles> ericwilligers: right 10% top wil go to 4

<myles> ericwilligers: 1 more question: right 10% top should serialize differently from left 10% top???

<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

<myles> Rossen: but this is after the discussion in the morning?

<myles> fantasai: no, we can do it now

<myles> fantasai: Looka t the 3rd table: 30px center. Some of the serializations use 50%, some use the keyword center

<myles> fantasai: The table after that: 40px top, some use 0% and some use the keyword top

<myles> fantasai: So the question is, do we resolve on outputting the keyword when the percentage would work?

<myles> dbaron: The bulk of the boxes are they keyword except 3 of them

<myles> dbaron: That said, I don’t know if we should try to go through all of this

<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

<myles> fantasai: We can look into that over the break.

<myles> Rossen: This is where we are going to get a lot more calcs in percentages

<myles> Rossen: okay that’s everything for this for now

Issues for listifying border-color

<myles> Github: https://github.com/w3c/csswg-drafts/issues/2532

<myles> leaverou: There’s a very detailed write up in the issue of everything I’m going to say

<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

<myles> leaverou: BUt when I actually tried to listifying border-color, there were several issues.

<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

<myles> heycam: Wouldn’t this happen with any other listified properties?

<myles> leaverou: Others don’t stack. Backgrounds and animations are independent. But border-width, they stack, they aren’t independent.

<myles> tantek: Or you have to do weird math, which is worse.

<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

<myles> leaverou: You can see an example in the issue

<myles> leaverou: It’s quite unexpected.

<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

<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

<tantek> Lea's proposal looks like an improvement to me

<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

<myles> fantasai: You don’t want absolute positions

<fantasai> s/positions the way gradient stops do them, but rather widths that stack/

<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

<myles> emilio: Firefox used to have multicolor border support, by using a new property

<myles> leaverou: Yep, and it was confusing

<myles> chris: We decided not to do it the Firefox way

<myles> dbaron: It was a hack to create a certain button style without making extra dives

<myles> leaverou: I used it 10 years ago to simulate box shadow

<myles> TabAtkins: I like it

<myles> astearns: What happens when the total sum of the width exceeds the border width?

<myles> TabAtkins: You just only render the border-width of the stripes

<myles> leaverou: We can just scale it down. We do it with border-radius, if the total radii overlap, then it gets clamped

<myles> S/clamped/scaled equally across the entire box/

<myles> astearns: That could work, but what about fractional widths? Those go to 0? So you have a 2px white fractional black, 2px white

<myles> TabAtkins: *describes another example*

<myles> fantasai: It’s better than clamping.

<myles> fantasai: It gives you reasonable behavior when you grow and when you shrink

<myles> TabAtkins: We already have mechanisms (percentages) to do this.

<myles> TabAtkins: This allows you from putting in more stripes than you need

<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)

<myles> frremy: Animations work better too

<myles> leaverou: If you want to reveal stripes, you could always animate them from 0

<myles> TabAtkins: Not if we scale the values

<myles> leaverou: Non-zero lengths will be scaled down, but if you want to progressively animate,

<myles> TabAtkins: You can already achieve accordian effect

<myles> fantasai: What if you want 2px red, 2px white, 2px red. If the border grows, you want the white to grow

<myles> fantasai: When you scale up, you want red on the outside, you preserve the red, white, red

<myles> TabAtkins: use min() and max() instead.

<myles> leaverou: What do we do if we want a thinner width than what we have? In fantasai, what if our border is 10px

<myles> TabAtkins: We follow gradients. The last color continues

<myles> fantasai: Or the last color could be transparent

<myles> TabAtkins: But then the border doesn’t look thick

<myles> fantasai: If you want it to be thick, put 1fr at the end

<myles> TabAtkins: When this is used in a 2 dimensional context, then this should be a gradient in some arbitrary direction

<myles> fantasai: I don’t think he testing and implementation effort of making stripes in 2d only for an arbitrary direction makes any sense

<myles> TabAtkins: Here we’re just talking about stretching and scaling

<myles> Rossen: What if we repeat the pattern?

<myles> leaverou: We can introduce that later. Let’s keep it simple.

<myles> fantasai: It answers the question of what to do if you dont’ have enough stripes

<myles> TabAtkins: Don’t be arbitrarily different. Do what gradients do

<myles> fantasai: no

<myles> TabAtkins: no

<myles> TabAtkins: be consistent

<myles> fantasai: this isn’t gradients

<myles> TabAtkins: this is gradients

<myles> fantasai: this is stripes

<myles> leaverou: Gradient color stops are defined absolutely, and there is no fr

<myles> Rossen: stop. Are we trying to add this to backgrounds-4?

<myles> All: yes

<myles> Rossen: We can work this out later

<myles> Rossen: Was there anything else you wanted to go over technically as part of the proposal?

<myles> leaverou: no

<myles> Rossen: Should we add this? Are there still too many open issues for it to be added?

<myles> TabAtkins: Using the stripes functions as a border color and not listifying border color makes more sense than what we already have

<tantek> agreed

<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

<myles> astearns: border-color-stripes?

<myles> fantasai: border-stripes is okay

<myles> leaverou: What about the confusing interactions?

<myles> fantasai: its okay.

<myles> astearns: Some behaviors fall out of the description

<fantasai> astearns: e.g. might answer question of what to do when you run out of stripes

<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

<myles> fantasai: You should show border underneath this property

<myles> leaverou: You often want them to stack, to have a fallback that you don’t have to repeat it in your gradient

<myles> xidorn: I dont’ understand the integration here

<myles> fantasai: border stripes and border color will disappear when you use border-image

<myles> chris: This will need some good examples

<myles> TabAtkins: Or we just do stripes() and we don’t have to deal with this stuff

<myles> leaverou: yep

<myles> fantasai: yep

<myles> leaverou: If we do it with a stripes function and not a separate property, we can extend this to other properties

<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

<myles> leaverou: i said “if it’s needed” and it may not be needed

<myles> fantasai: We could re-use the syntax. It doesn’t have to be a functional notation

<myles> leaverou: We would have to add a new property for each of those cases

<myles> fantasai: That’s okay

<myles> Rossen: Do we prefer the stripes functions? Or a new property

<myles> fantasai: border-stripe

<myles> TabAtkins: stripes function

<leaverou> stripes function

<tantek> stripes function

<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.

<myles> leaverou: yes

<tantek> s/all a/allow a

<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

<myles> leaverou: So you can do them both in the same property

<myles> Rossen: Yes.

<myles> TabAtkins: Why do you need that?

<myles> Rossen: So you can have the last value be transparent, and the default shows through

<tantek> Is stripes a subset of gradients?

<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

<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.

<myles> chris: Let’s not make a new property.

<myles> tantek: Is stripes just a subset of gradients?

<leaverou> tantek: No, gradients are 2D images. Also, gradient color stops define positions, not widths.

<myles> Rossen: Proposal: adding stripes() to border-color and outline-color

<myles> Rossen: Any additional concerns? Comments that would change this resolution, or objections?

<myles> florian: How does it interact with border-style: double

<myles> fantasai: You clip out the border shape.

<myles> Rossen: Just like it would work with gradients

<myles> leaverou: I think he’s asking about double borders ,not dotted and dashed.

<myles> chris: It’s a clip mask effectively.

<myles> leaverou: Double has two different colors, and inside and an outside

<myles> florian: nope, that’s something else

<myles> leaverou: You’re right

<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.

<myles> florian: You can use it as fallback.

<myles> leaverou: right!

<myles> leaverou: I like that

<myles> chris: yeah.

<myles> Rossen: Any objections?

RESOLUTION: Add stripes() to border-color and outline-color

<TabAtkins> tantek: It's *substantially* more work, yes, *and* it doesn't work well with border-radius either.

<myles> Rossen: Do we now publish a new working draft?

<myles> fantasai: I don’t know what state the rest of the draft is in

<myles> leaverou: we’ve published a working draft before, right?

<myles> fantasai: nope

<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.)

<myles> Rossen: This is level 4, right?

<myles> leaverou: yes, that needs lots of cleanup

<TabAtkins> And yeah, probably so, which is fine with em.

<myles> Rossen: Let’s not publish

<TabAtkins> Just "gradient(...)"

color-filter

<myles> Github: https://github.com/w3c/csswg-drafts/issues/2875

<fantasai> github: https://github.com/w3c/csswg-drafts/issues/2875

<shane> Restaurant tonight is Long Chim

<fantasai> dino: Some background...

<fantasai> ScribeNick: fantasai

<shane> address for Long Chim: Corner of Pitt Street &, Angel Pl, Sydney NSW 2000

dino: Same way that Windows has done for decades, Apple's latest OS has a “dark theme”
... Where user has a checkbox where they can choose between light or dark mode
... You can see my browser is in dark mode atm
... System apps have implemented this
... Seems pretty popular
... This is about how you can apply something like that to the Web
... Particularly relevant to us for mail messages
... which are web pages
... What we wnated to do was automatically ocnvert a page to dark mode
... To do that, you want white to go to black, but you want hues to stay the same
... e.g. blue shouldn't become orange
... We had the idea to use color-filter
... This takes filters just like 'filter'
... But doesn't have ability to omove pixels
... It's a paint-time effect

chris: Is this a straight 255 minus effect?

dino: Yes

dino shows off invert()

dino: It's not like a regular filter. No stacking context. Just applies to colors
... colors of gradients, anywhere a <color> appears
... DOesn't affect images
... Because when you switch to dark theme, you don't want to have images invert
... or emoji colors to invert

etc.

dino: We don't actually wantto just invert the colors
... Here's an example - invert(0.83) hue-rotate(180deg) saturate(3)
... 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
... Works nicely. Better on my laptop than on the projector here.
... This other column does some additional tweaks using JS, to look a little better.
... Anyway, this is what we're using to display mail messages now
... We have heuristics, if a marketing mail sets bgcolor, we won't do it
... but for plaintext or simple HTML messages, we'll apply the filter
... What we've got here is not Web-exposed, just in Mail
... We can talk more later about Media Queries and how to interact with the Web
... But a Web page could e.g. change colors manually in response to a media query, or they could use color-filter
... It's just maths on red/green/blue channels of the colors
... images are untouched
... No stacking context
... It's inherited, so you can undo it in a subtree

chris: Initial value?

dino: none

chris: You say not images, but some parts of CSS are <image>s...

dino: Gradients is a good example. If your bgimage is a gradient, you apply it to the coors in the image

leaverou: What about custom properties that have been defined to accept <color>?

fantasai: Gets applied when you apply the color

TabAtkins: But you don't want to double-apply for typed variables
...

xidorn: Is it applied during cascading or what?

emilio: Computed value is not affected

fantasai: used-value time operation

astearns: currentColor

fantasai: probalby fine

heycam: <canvas> ?

dino: Woudln't apply to canvas
... Currently implemented not for Web, in apps ike Mail etc.
... We think it makes sense for the Web
... as a way to help authors adjust page

leaverou: What about color modification functions?

TabAtkins: Amelia asked that already in the issue. I think having both is useful

leaverou: Are there uses other than dark themes?

dino, chris: high-contrast

dino: One of the greatest benefits we've found, before this people with vision issue sthat didn't like bright content would be constantly swapping between inverted/non-inverted mode
... And that's a screen-time effect
... And then we had to uninvert the images to make that useful for them
... And then also create all these stackign contexts, which aaffects the page
... So this is pretty nice.
... So this might be a nice forced option
... That the user could apply, e.g. "I want to see this web site dark"

leaverou: Does it also apply to colors in inline SVG?

dino: Yes

<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)

leaverou: Woudn't this be ...
... You can have bitmaps inside an SVG
... Seems like it would interact badly

dino: Could have a UA rule that sets it back to none
... We've mostly experimented with Mail. Haven't tried to apply to the Web yet

heycam: What if page wants to try handling it themselves?

dino: This is a complicated topic, wanted to deal later, but let's talk about it now
... If the browser is being told to apply dark mode automatically, what should we do?
... If there's a media query that allows the page to detect if the user wants dark mod
... Should the browser automatically flip th epage or not?
... It would be very odd for MQ to trigger behavior change

fantasai: We do have precedence

frremy: On Windows 8, if you resize an application to be in phone mode, we would scale the website down, except if it used @viewport

florian: That's not a media query. @viewport is *supposed* to have an effect on the page
... Opera did that for projection media type.

<tantek> similarly with full screen

dbaron: Been done before, but not a good idea. Poor API

dino: API I think that would provide it is also bad
... it's <meta viewport>
...

florian: MS has an alternative to that, it's a property
... can say "for this subtree, I've done it"

emilio: Could say color-filter: noe

florian: *If* the browser is doing this with color-filter and not some other mechanism

dino: So you'd set that property on the body

fantasai: Can we use html , not body?

heycam: Is this about high-contrast?

Rossen: yes

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
... meta tag doesn't have that problem
... but then can't exclude part of the page

Rossen: In practice, ppl tend to opt out of things like menus and ...

dino: So that's actually main reason we don't want to do it automatically

<tantek> what about where web devs have matched color related values with colors in images?

dino: built-in form-controls look weird
... but ppl don't use built-in form controls that much, they use boostrap etc.

<tantek> Tab: WAT

TabAtkins: Uhhh,, no???
... The whole point is that built-in form controls work properly on.e.g. apple watch

florian: We've discussed similar model for auto-adjustment of colors for printing
... Where authro might want the browser to not make changes to the colors, because they already turned on colors and stuff
... “Browser has magic adjustments. I want to opt out on this part of the page.”

dino: It worries me a bit that including any style sheet could override this

florian: meta tag seems the wrong layer to do it

fantasai: That's true of viewport meta in general. SHould be in style sheet

dino: Suppose you include your favorite UI library. It supports dark mode.
... Should it put "I support dark mode" property on the html?

frremy: No, you set the property on the elements in your framework. Not on the whole page

dino: So bounding to a tree

florian: It's just a property. You *can* use it on <html>, but could apply only to components.

tantek: Did you talk about use case of matching colors in a JPEG?

dino: Could just set the filter to none

florian: Could use property to express two different things
... “Dear Browser, don't do it, because I've done it myself.” vs “Dear Browser, don't do it, because here it's not appropriate”

dino: So property is nice there, can say "Don't use on this color of red, because it has to match the red of these shoes" but rest of page is fine

heycam: Are we considering possibility of meechanisms other than color-filter() being set to handle these cases?
... Because if not, then maybe we don't need a separate filter

dino: So far color-filter has been enough for us, but we've only been looking at mail
... Haven't tried browsing the web to see what happens on random content

astearns: It's the exceptions I'm worried about
... In mail, generally the bg is set on the body
... but on web pages could be arbitrary div

dino: We found a lot of messages that don't set a bgcolor
... but content sets bg the white
... that's why we couldn't layer mail over a gray application background
... had to put some smarts into analyzing the page
... If we can detect that the page wants a white background, because it's set some things to white...
... But so far color-filter has been enough
... Good news is implementation is quite easy
... Just at the point of where you're asking for the color value
... It's great, makes it easy to be a render-time effect
... math is pretty easy
... can also cache the values

heycam: Some properties to control the color space that we interpolate in
... for animations and gradients
... That would happen with origianl color values before transofrming them?

dino: Don't think there's case where you'd want to change colors *and* change interpolation space
... No idea why red-blue gradient, why if you invert it you'd want it to be in linear-rg

rgb

dino: If you ask for gradient colors, you get filtered colors, and then interpolate like gradient said to
... Of course could put property with a media query if you wanted

chris: So this modification happens last, just before rendering

dino: Right.
... Computed style is still the original color
... While we're talkign about this, maybe talk about MQ
... Our current one that we use internally, is prefers-dark-interface
... Think it's more prefers-dark-content

TabAtkins: prefers-dark

dino: Lines up with prefers-*
... User is requesting that they prefer this type of content

florian: I'm supportive of prefers-type MQs,
... Question is what is the other options?
... Can you express no preference in addition to expressing preference for light?
...

dino: prefers-dark: light seems weird

<TabAtkins> `color-pref: goth | prep;`

fantasai: Just rename it to something else, e.g. prefers-colors: light | dark | any
...

heycam: Say you have a site which is already dark, like DaringFireball, and you turn on the browser option "Please automatically make this dark for me"?
... Are there options to keep it dark?

dino: I think we need to be careful to say that "Please make this dark for me" can't be a universial hammer
... It's hard to tell
... E.g. we try with scrollbarls, to try to guess whether page is light or dark and make scrollbars match
... Because DaringFireball sets bgcolor which is neither white nor back
... we probably wouldn't change anything

heycam: Is that a case where the author should indicate they already support dark?

dino: Question is, does anyone want to force bright?
... If you set bgcolor to hot pink, might say that you support dark and they'll get hot pink anyway
... Also for mail you'd get hot pink
... ...

florian: Do ppl anticipate forced-darkening of pages?

dino: There are a lot of users who seem to want that
... They've set up shortcuts to invert the page
... They toggle this on and off as they browse different pages

florian: If you have prefers-dark and forced-dark on at the same time, what does that mean?

dino: ...
... If the page says 'I did dark mode' then we wouldn't force it

dbaron: Did some experiments with this sort of color inversion maybe 8-10 yrs ago
... 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
... because the contributions of red green and blue channels to luminance is very very different
... In the difference of white vs black, the luminance perception of that is 70% green 23% red and 7% blue or something like that
... which means that fully saturated blue is quite readable against white, but unreadable against black
... and fullysaturated green is quite readable against black and unreadable against white

dino: Which is why my third column was there, it bumped dark blues to lighter blues... blends a light-ish blue over every color ...

astearns: I expect as your designer looks at more and more pages, they would find additional tweaks they'd want to make to the filter
... I can see the usefulness for this feature for browser UI
... as something you can toggle, and you can flip it back if it isn't working
... from a design perspective
... I can't imagine someone wanting to tweak their colors with such a blunt hammer

<chris> for sRGB it is 21.26% red 71.52% green 7.22% blue

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
... So from UA perspective I see the usefulness
... But from author perspective I can't see the use case for the color-filter property

Rossen: Thank you for demos and explanations, and that's a wrap for this issue.

Images Level 3

<heycam> ScribeNick: heycam

<fantasai> github: https://github.com/w3c/csswg-drafts/issues/2852

leaverou: we were trying to define interoplation between crossfades more reasonably with fantasai yesterday
... when we're interpolating two cross fades with same images in a different order, A B , then B A
... it ends up creating a cross fade of the cross fade
... this comes up a lot, this interpolation happens when you're reversing a transition
... 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
... so 100% minus what it was
... is that OK? since it's CR we should check

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
... so you want to interpolate between a crossfade and a start point
... your computed value gets more and more complex

dbaron: is this the only interoplation type that has this problem?

emilio: I suspect it can happen with transform as well

dbaron: yes

birtles: with calc

ericwilligers: with transform didn't we define ...

TabAtkins: the interpolate() function

dbaron: so transform can do the same thing with interpolate() nesting in the same way

fantasai: we should probably do the same thing for transform then

ericwilligers: does interpolate() make cross-fade() redundant?

leaverou: it only helps you get the intermediate values

fantasai: there are use cases for cross fade where the author explicitly wants to fade between two things
... and there are differnet ways of interpolating images, cross fade is one of them
... 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

xidorn: shouldn't we just merge things when one side is crossfade A to B, and the other side is A or B?

fantasai: that's the next question

dbaron: what stage is this happening?

fantasai: computed value?

dbaron: so part of the process of computing the value of a nested cross fade is to un-nest

fantasai: no, when you're computing the mid point for

dbaron: so you're changing the interpolation rules

fantasai: yes

Rossen: does that sounds reasonable to people?

dbaron: yes, if you make it consistently apply to other places where this problem comes up

TabAtkins: yes

Rossen: any objections to this? do we need to add a note for the general interpolate function to be added as well?

birtles: I misunderstood
... I thought this was just about computed value simplification of nested cross-fade

ericwilligers: [writes examples on white board]

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?
... then you don't need to do anything particular for interpolation

fantasai: we could do that

leaverou: I'd be fine with that

dino: cross-fade(A, B, 50%) is not the same as cross-fade(B, A, 50%)
... it's 50% of src-overing the second on top of the first

fantasai: and with transparency?

dino: you can tell the difference between B over A 50% and A over B 50%, yes

ericwilligers: would you advocate nested cross-fades()?

dino: I'd advocate not interpolating

fantasai: I don't think that's a good solution

dino: if we're going to do it, then nested cross-fade(), maybe

leaverou: nested cross-fades() should be supported anyway

dino: so, yes, nested cross-fades() would be my preferred solution

leaverou: I think it's Safari and Chrome at the moment

birtles: pre-fork, so one implementation

TabAtkins: dino your point before about A B 50% and B A 50% being different is wrong, since it's a dissolve
... dissolve op rather than src-over op
... since that's the correct way to fade between two images with potential transparencies

Rossen: do we need a whiteboarding breakout for this?

leaverou: if reversing the order does produce the same image, what's the argument against it
... if nobody has any then why do we need to break out

<fantasai> http://drafts.csswg.org/css-images-3/

<fantasai> https://drafts.csswg.org/css-images-3/#cross-fade-function

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

emilio: why (c)?

leaverou: then it also allows us to simplify computed values returned

emilio: I thought the point was nested cross fade is hard

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
... when you could simplify it down

emilio: the difference between (b) and (c) is not observable

TabAtkins: yes it is

emilio: I think I prefer (b)

leaverou: [shows demo]

emilio: if you want to simplify what you interpolate, to avoid growing stacks of cross-fades(), you do it there
... but you also need to do it at computed values
... because the author might have specified a nested cross-fade()

fantasai: the interoplated intermediate value must be a computed value

<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.

leaverou: if I'm understanding emilio correctly, you don't want to create this thing if you're going to simplify it anyway
... if you're already going to simplify serialization of a specified (and computed) value

emilio: it complicates the code

birtles: I wonder if you're going to need to simplify it first anyway, in order to interpolate potentially nested inputs that you get

ericwilligers: yes

birtles: also will need to do it for addition, assuming that makes sense

leaverou: ideally it would be nice if cross-fade() accepted any number of arguments, and flatten them down to a single one

ericwilligers: then you've got more permutations

leaverou: if you could collapse the tree down to a flat cross fade list of values, it's simpler to apply

TabAtkins: since dissolve commutes, you can collapse all cross fades

dino: plus commutes, dissolve doesn't
... what I got wrong is I'm src-overing not plusing

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

leaverou: should we just do that, allow cross-fade() to take a list of arguments

birtles: I think it's nicer from an authoring point of view too

<birtles> that is, parsing the result of getComputedStyle is easier if you don't need to handle nested cross-fade functions

leaverou: another issue, if you're interpolating between A and cross-fade(A, ...), with the current rules you'll get a nested cross-fade()
... we could define that the A gets promoted to 100% cross-fade, and just interpolate percentage

<leaverou> https://github.com/w3c/csswg-drafts/issues/2853

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

leaverou: we can, but if we're collapsing trees of cross-fade()s, it's less important

fantasai: collapsing trees is different from merging

TabAtkins: depends how we collapse

dino: [looking at the issue] wouldn't it be x is between 0 and p, not p and 100?

leaverou: you're interpolating between full A and the cross-fade
... you want it to start at 100

dbaron: I think we should try to resolve both at the same time
... where the simplification happens, turning into multi arg cross-fade(), applies to both

myles: the proposal is change the behavior because it makes it easier to compute?

leaverou: this way you wouldn't need to interpolate to make a new cross-fade() at all

myles: there is a difference between having a tree of cross fades and not having a tree

TabAtkins: nobody has trees yet
... we're trying to avoid that now
... 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

<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

TabAtkins: and make nested cross-fade() invalid, and make interpolations between them build the appropriate multi-arg value

<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

[whiteboard discussion of particular interpolations]

leaverou: I still think nested cross-fades() should be valid, since they could come from variables

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

TabAtkins: you don't need to generate all the intermediate images

myles: is there a behaviour change?

TabAtkins: no

myles: then we should just say "as if", a browser optimization
... so we're talking about computed values

florian: do we disallow in specified value?

TabAtkins: before we decide on that, let's look at the core thing
... multi-arg cross-fade(), does it sound reasonable

dino: and you must provide %s up to the last one?
... allowed to go over 100%?

TabAtkins: yes [for first], and no.
... if the percentages add up to over a 100%, you sum them and normalize to 100%
... then the last one gets zero

myles: every time gets a percentage

TabAtkins: except the last
... last one gets what's left over

dino: complete error if you did (A 10%, B, C)?

TabAtkins: syntax error

myles: is the purpose of this that humans will write this? or just to make the getCS output smaller?

TabAtkins: so clearly we want this for interpolation

<fantasai> heycam: Simplifying trees down to one level is same as flat list

<fantasai> heycam: Want to collapse list to minimum number of items

<fantasai> TabAtkins: If the goal is to avoid explosion...

myles: if this is for humans to use, it's useful

ericwilligers: negative %s allowed?

TabAtkins: no, individual %s above 100% should be invalid

<fantasai> TabAtkins: But we can't syntacitcally restrict the sum

birtles: I'm not 100% sure about the normalization part
... the syntax I like

ericwilligers: not sure about normalization when you have interpolations between lists

birtles: I was thinking, once the bucket's full, the overflow could be dropped

myles: should make it possible for the last one to have a %

florian: to use them as 'fr's?

leaverou: right now, cross-fade() percentage is optional
... probably it should retain this
... right now (A, B), the 50% is implied
... (A 20%, B, C) should make sense

shans: distribute the rest

leaverou: yes

myles: allow the last percentage to be specified, then just weight them

fantasai: if you have (A 20%, C 20%, C 20%)
... you could simply transparent black to take the slack

florian: rather than normalizing to 100%?

fantasai: if you're under

shans: one problem with diff behaviours on either side of 100% gets you non-linearities, bad for animation

ericwilligers: like opacity:1

<Zakim> dbaron, you wanted to comment on (a) nesting through other functions and (b) validity of percentages that add to more than 100%

TabAtkins: the suggest grammar is, cross-fade() takes one or more args, each has an optional %
... we'll work out what missing %s mean

Rossen: any objections to that?

RESOLUTION: cross-fade() takes one or more args, each has an optional %

leaverou: next, collapsing trees of cross-fade()s
... it's much easier to define interpolatino that way
... for authors reading it back
... don't know why we wouldn't collapse it down, esp given it's commutative

emilio: can we disallow nested cross-fade() in specified values?

TabAtkins: no for the same reason you allow nested calc()s

leaverou: with variables

dbaron: two other points
... there are going to be other image-ish functions
... cross-fade() one of these other functions continaing a cross-fade() will be a reasonable thing
... 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
... so we should just allow it now

TabAtkins: agreed
... specified values should allow it. interpolated values collapse to a single value
... interpolated values, don't care?

leaverou: I would collapse

birtles: collapse

fantasai: I think so

florian: both kinds of smooshing down, flattening tree, and merging items in the list?

leaverou: they are separate issues but I support both

myles: so it's not just a simple substitution, there are formulas to calcalate the %s

TabAtkins: yes. it's just mulitplican tho

RESOLUTION: At computed value time, simplify directly nested cross-fade()s into a single cross-fade()

xidorn: that means the flattened value is the canonical form of that

TabAtkins: yes

leaverou: now dropping duplicated images

TabAtkins: if you have multiple args which are the same image
... should the canonical form automatically collapse those together and add their percentage

leaverou: do we have an algorithm for same image?

fantasai: the compued value of the <url> is the absolute URL

Rossen: the reason for simplifying is avoiding growth of the values

leaverou: we should not only combine the duplicates but also sort them

fantasai: I think we need to simplify this, to avoid growing lists
... we can do it very simply

emilio: how do you define sorting images?

myles: if you didn't want this, didn't want to collapse -- internally you want to

<Rossen> heycam: are the cases where we want avoid this?

fantasai: I don't think so
... it's going to be the same when you collapse it all down
... notion of equality we want is "computed values are the same"

frremy: with gradients, with px and %s ....

fantasai: that's not computed value
... that's used value

RESOLUTION: At computed value time we collapse same <image> values in cross-fade()s and adding their percentages

leaverou: sorting

fantasai: you don't want computed value of cross-fade() where you randomly swap the order
... re-sort into the target order and go from there?
... so don't sort the computed value
... but when interpolating, you re-sort the start point into the end point order

<inserted> fantasai: order for interpolations falls out of cross-fade(start, end) and flattening

myles: that's cool then CSS doesn't have to define order

so no sorting occurs, for interpolation it falls out of the simplification process

<TabAtkins> When interpolating be3tween A and B, you just cross-fade(A,B) then collapse; whatever that results in is the answer.

Deferring gradient interpolation to L4

Defer gradient interpolation to L4?

Rossen: anyone objection to deferring gradient interpolation to L4, to move L3 quicker?

RESOLUTION: Gradient interpolation is moved to Images L4

fantasai: we should clarify the spec to say we do abrupt transitions
... (and not cross-fade)

<dbaron> leaverou: people can still wrap in cross-fade to force interpolation by cross-fade?

<dbaron> TabAtkins: fantasai: yes

Deferring cross-fade() to L4?

Rossen: nobody implements it
... Images L3 is in a good shape

TabAtkins: let's do that

RESOLUTION: cross-fade() is moved to Images L4

<leaverou> https://drafts.csswg.org/issues?spec=css-images-3&doc=cr-2012

<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

<br type="lunch" until="1:36pm">

Does all reset custom properties?

<fantasai> github-bot:

<github-bot> fantasai, Sorry, I don't understand that command. Try 'help'.

<fantasai> github: https://github.com/w3c/csswg-drafts/issues/2518

<fantasai> TabAtkins: Two questions to this issue. First is does all reset custom properties? I say yes

<fantasai> TabAtkins: second, should we have something that does? I say yes, Emilio says no

<fantasai> emilio: I don't remember why...

<fantasai> astearns: Proposed that custom properties don't get reset by all. Any objections?

<fantasai> dbaron: Have ppl checked implementations?

<fantasai> frremy: Edge doesn't

<fantasai> xidorn: In Gecko it doesn't reset custom properties either

<fantasai> emilio: We have an invariant that only have one longhand in a given declaration block

<fantasai> emilio: We only store longhands, we don't store shorthands

<fantasai> emilio: That's why it doesn't reset custom properties

<fantasai> emilio: We'd need to rewrite everything.

<fantasai> TabAtkins: Chrome also does not reset custom properties

RESOLUTION: all shorthand does not reset custom properties

<TabAtkins> test: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6017

<fantasai> Next question, should something reset all custom properties

<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?

<fantasai> fantasai: It would have to be a non-custom property

<fantasai> leaverou: What's the usecase?

<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

<fantasai> emilio: So it would be a longhand

<fantasai> TabAtkins: So it would be a shorthand

<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

<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

<fantasai> emilio: When do you check the value of this property?

<fantasai> emilio: Presumably you want it to work like all property

<fantasai> emilio: --: reset;

<fantasai> emilio: vs --: foo;

<fantasai> emilio: What properties is it resetting, we don't know what the properties are that we're resetting

<fantasai> emilio: until we've cascaded/inherited the custom props

<fantasai> TabAtkins: ... I understand the problem now

<fantasai> TabAtkins: If you say --foo: red; --: initial; --bar: blue;

<fantasai> TabAtkins: The --foo needs to be reset to initial, but --bar needs to still be blue

<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

<fantasai> frremy: In Edge we have a registry of all properties, which need to be handled before ...

<fantasai> TabAtkins: So you would expand it to all the properties on th epage?

<fantasai> emilio: That's not the point of the feature

<fantasai> emilio: You can't expand it at parse time

<fantasai> frremy: You don't expand at parse time

<fantasai> xidorn: Expanding at parse time is how shorthand is supposed to work

<fantasai> emilio: Also, magic of "every prop htat has aappeared on the page so far" is really bad

<fantasai> frremy: Not proposing that

<fantasai> TabAtkins: If you do it as that type of prescan, then you can do this. Otherwise you can't

<fantasai> emilio: You can't implement as a shorthand, because you don't know for serialization what it expands to

<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

<fantasai> emilio: Let's say you specify this as a longhand property, then you can do what eric said

<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)

<fantasai> emilio: Right now we have different phases

<fantasai> emilio: This would convert it from 2 to 3 phases.

<fantasai> emilio: First figure out magic property's computed value

<fantasai> emilio: Then figure out custom properties

<fantasai> emilio: then figure out the rest

<fantasai> emilio: which is kindof annoying

<fantasai> ...

<fantasai> frremy: ...

<fantasai> emilio: We don't want a global index of custom properties

<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

<fantasai> TabAtkins: This would change the inherited value of your custom properties on the children to the value of --

<fantasai> TabAtkins: But then can't both block inheirtance from parent and set specific custom props for inehritance to your children

<fantasai> TabAtkins: on the same element

<fantasai> TabAtkins: Possibility is to make -- take a list of properties to *not* reset

<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.

<fantasai> TabAtkins: And then it alters the way that all unspecified custom properties inherit to the element's children

<fantasai> frremy: I don't think we like this

<fantasai> TabAtkins: I think it's the only way to make -- work on a single element without being a shorthand

<fantasai> astearns: You would be duplicating the properites that you want to declare on that element

<fantasai> TabAtkins: Correct.

<fantasai> fantasai: Think that this means we should not add the feature. Nobody's been clamoring for it anyway.

RESOLUTION: -- is reserved

RESOLUTION: Don't add shorthand for custom props

env()

process for adding env() variables

<fantasai> github: https://github.com/w3c/csswg-drafts/issues/2820

<fantasai> TabAtkins: I agree.

<fantasai> astearns: Currently spec says “

<fantasai> user agents may define additional undocumented environment variables

<fantasai> ”

<fantasai> TabAtkins: I think Apple agrees with proposal, too

<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

<fantasai> dino: But I don't know if anyone still believes that

RESOLUTION: Accept proposal in the issue.

<fantasai> “UA vendors MUST NOT expose built-in env() features to the web without going through that process”

Accept safe-area-inset*

<fantasai> github: https://github.com/w3c/csswg-drafts/issues/2868

<fantasai> dino: We proposed this last year

<fantasai> dino: I think this one is hopefully not so controversial

<fantasai> dino: We expose it so ppl can avoid notch in iPhone and rounded corners

<fantasai> dino: But can also be used for e.g. safe area for televisions

<fantasai> fantasai: Would be really usefl for printing as well

<astearns> https://drafts.csswg.org/css-env-1/#safe-area-insets

<fantasai> dino: Having experimented with this, it makes sense for insets

<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

<fantasai> dino: page shouldn't put anything there

<fantasai> dino: Should we inset the entire top/left sides?

<fantasai> dino: Or just a note saying avoid that part of the screen?

<fantasai> dino: Let's pause and talk about that later?

<fantasai> dbaron: There was some prec prose that Rebecca Hughes and I iterated over

<fantasai> dbaron: Because I didn't want Google to ship without a spec for it

<fantasai> dbaron: What I suggested there, and which I thin kis now in the draft,

<fantasai> dbaron: Was that the insets together should define a rectangle such that everything in that rectangel is safe

<fantasai> dbaron: But what you're showing is your insets are more than that

<fantasai> dbaron: You could use any pair of them... but that doesn't work for the notch

<fantasai> dino: Right, for notch, we have top and bottom insets and it's fine

<fantasai> dino: But if your rotate sideways, then you have left and right insets

<fantasai> dbaron: I'm wondering if the diagram is intentional

<fantasai> dbaron: I'm suggesting that the rectangle inside the insets was safe

<fantasai> dbaron: but if you move any of those lines outward, then it's no longe rsafe

<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)

<fantasai> dbaron: Specced that the UA is allowed to pick whatever it wants that would maximize the the usuable space

<fantasai> dbaron: There are multiple solutions, might want a narrower or wider rectangle, that affects how tall it can be

<fantasai> myles: The UA is the one that decides what safe me

<fantasai> myles: We could say that the innermost rectangle is safe

<fantasai> dbaron: Prose we put it said something like

<fantasai> “There is some nonrectangular safe region. The insets define some maximal rectangle within that region”

<fantasai> fantasai restates what dbaron was saying

<fantasai> dino: I think this definition would be acceptable...

<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

<fantasai> dino: Would be overagressive in saying what's safe

<fantasai> fantasai: there might be different use cases for each definition...

<fantasai> myles: For TV example, there's no horizontal line that's afe all the way across

<fantasai> dino: TV wants more like the green example (individal insets)

<fantasai> dino: whereas a rounded display needs more like the red one (dbaron's definition)

<fantasai> iank_: Another take is that the green is the same as the red plus a margin

<fantasai> fantasai: Could have two different sets of variables, safe-area-inset and safe-rect-inset...

<fantasai> heycam: With scrolling, might have different preferences on whether to maximize horizontal or vertical areas

<fantasai> myles: UA could alter these

<fantasai> astearns: Hroizontal vs vertical orientation of device, would UA reset them depending on orientation?

<fantasai> dino: Currently does, yes

<fantasai> myles: ...

<fantasai> astearns: Are you unsure whether having these four insets is the right design?

<fantasai> dino: I was sure, now wondering whether we should define them as the red rectangle

<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...

<fantasai> dino: Maybe we should hold this.

<fantasai> dino: I will take this back and discuss with other ppl

<fantasai> dbaron: I think the text needs adjusting for the TV use case, also.

Full-screen insets

<dbaron> https://drafts.csswg.org/css-env-1/#safe-area-insets

<fantasai> github: https://github.com/w3c/csswg-drafts/issues/2871

<dbaron> (that URL was for the previous topic)

<fantasai> dino draws a fullscreen video player

<fantasai> There's a title in the top left corner

<fantasai> there's controls along the bottom

<fantasai> dino: Works fine on a desktop machien because everyone knows you can get out with escape or whatever

<fantasai> dino: But touch interface doens't have escape key

<fantasai> dino: So we need to provide some UI for escaping

<fantasai> dino: e.g. an X in the top left corner

<fantasai> dino: Fades away if you haven't touched the screen much lately

<fantasai> dino: Trying to come up with avriables to take the page where it can draw content when the browser UI is available

<fantasai> florian: We kindof alked about that when we were doing round display, with different approach

<fantasai> florian: MQ with coordinate, if I put something there, will it be visible?

<fantasai> florian: Rather than browser trying to prove geometry, can just ask "can I put the box there"?

<fantasai> myles: Why would you want to binary search for an available space? seems awful

<fantasai> dino writes an example

<fantasai> title { pos: abs; top: env(fs-inset-top);

<fantasai> dino: Can even say title { transition: top 1s; }

<fantasai> dino: then the title shifts as the browser UI desappears and appears

<fantasai> dino: While we specify top/left/bottom/right

<fantasai> dino: top effectively reserves the entire top

<fantasai> dino: We might do {various things } in this area

<fantasai> dino: In safe mode, would also have put the left side offset, but we decided to just do the top

<fantasai> ...

<fantasai> astearns: so the space taken up by the browser UI is only known when the UI is showing

<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

<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

<fantasai> dino: Might want to expose timers on our fading so they can synchronize

<fantasai> heycam: Maybe use events rather than time?

<fantasai> dino: Events makes more sense, usually we're responding to those in JS anyway

<fantasai> heycam: also you don't know when exactly to start counting those seconds

<fantasai> dino: We'd also have to publish and make sure everyone's listening to the same events

<fantasai> dino: That's basically the two proposals. Happy for any suggestions or comments

<fantasai> florian: What we started with seemed nice and simple

<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

<fantasai> dino: It's veyr specific to our design, but we want to have something that works for others as well.

<fantasai> florian draws a dashboard display and asks about how far are we going to go

<fantasai> dino: safe-area-* is about hardware shapes. fs-inset is about on-screen displays

<fantasai> florian: ...

<fantasai> myles: System with arbitrary shapes would be so difficult to use that no developer would do it

<fantasai> Rossen: Similar to this, we had a value called device-fixed

<fantasai> Rossen: Worked exactly you describe,

<fantasai> Rossen: When onscreen keyboard came in, didn't want to resize the entire window

<fantasai> Rossen: But i fyou wanted to attach UI on top of the keyboard, e.g.

<fantasai> Rossen: Insteadd of positoin: fixed

<fantasai> Rossen: You'd do position: device-fixed

<fantasai> Rossen: And it would adjust

<fantasai> Rossen: You won't have to resynch or compute any numeric values like top/bottom etc.

<fantasai> dino: You wouldn't be able to animate

<fantasai> Rossen: That would be done for you

<fantasai> Rossen: Basically saying that the device now is going up

<fantasai> Rossen: on-screen keyboard is cming up

<fantasai> Rossen: If this UI was important for YouTupe, they'd simply position this as device-fixed

<fantasai> Rossen: And then this simply becomes bottom: 0;

<fantasai> Rossen: And they don't need to do anything else

<fantasai> Rossen: They don't even know, it's still the same thing

<fantasai> florian: If you are sizing things, would that affect viewort units?

<fantasai> Rossen: This is ovekill

<fantasai> Rossen: Another example put forward was if you have, suppose some vertical sidebar

<fantasai> Rossen: Same thing, a bit more work for us, but if you have positioned top and obttom it would respond

<fantasai> Rossen: From what I know, it was very successful because very simple

<fantasai> Rossen: position: fixed vs position: device-fixed

fantasai: why isn't position:fixed have the behavior of device-fied?

<fantasai> Rossen: We weren't actually resizing the viewport, it was an overlay UI

<fantasai> Rossen: e.g. keyboard uses semitranslucent colors

fantasai: but what if you want to clearly see the content at the bottom of the page?

Rossen: just dismiss the keyboard

<fantasai> fantasai: What if you need to type into a form field at the bottom of the page?

<fantasai> frremy: Then you can dock your keyboard.

<fantasai> dino: Do you still support device-fixed?

<fantasai> Rossen: yes

<fantasai> Rossen: We were doing this for action center, which is something that swipes from the right

<fantasai> Rossen: If you have some UI that's really important to your app

<fantasai> Rossen: you can attach it

<fantasai> myles: Does it work if the window is not full screen?

<fantasai> Rossen: No, this is only for full-screen

<fantasai> iank_: What is the box?

<fantasai> dino: In our case the device-fixed box would be what remains after the inset here.

<fantasai> iank_: But it wouldn't solve this use case?

<fantasai> dino: It would, but ti wouldn't solve use case of wanting ot fade all controls at once

<fantasai> iank_: What aobut tile shifting to the right?

<fantasai> dino: We'r ereserving the right ot put more things up there

<fantasai> dino: Would be up to browser to animate the the device-fixed box.

<fantasai> myles: Animation is different

<fantasai> myles: we want the animation to fade out

<fantasai> myles: whereas you want it to slide out

<fantasai> Rossen: You can fade out the keyboard or slide it?

<fantasai> myles: How does the page know to fade out or side out things?

<fantasai> dino: Say youtube uses a 3s fade, and we use a 4s fade.

<fantasai> dino: Wnat to tell youtube to use 4s if it wants to be in sync

<fantasai> fantasai: In Apple's case, could just use the transition time value in the 'transition' property

<fantasai> Rossen: Reason we wanted it done in browser was because syncing timers was not working

<fantasai> astearns: weirdly shaped things will need to use a lot of environment variables

<fantasai> dino: OK, we'll take back this feedback

<fantasai> fantasai: Also, you might want to consider s/fullscreen/overlay in the names... it's not really about the fullscreening

<fantasai> Rossen: If we are looking to solve the tying of author-defined controls with UA controls animation

<fantasai> Rossen: You can have a start and an end event

<fantasai> Rossen: Just also need to know how long between the two

<fantasai> myles: Could be part of the start event

<fantasai> astearns: Maybe you only need one set of environment variables

Media Queries

<fantasai> dino: Talked about prefers-dark mode ones.

<fantasai> dino: Other one is prefers-high-contrast

<fantasai> dino: Apple has a simple toggle for this. Prefer high contrast? Yes/NO

<fantasai> dino: It's much more complicated in Windows

<fantasai> dino: Would want auto | yes| no

<fantasai> dino: Blocked on not knowing what Windows or Android do, what granualrity do they have, how much do they want to expose.

<fantasai> frremy: We have states [light | dark ] high-contrast?

<fantasai> florian: In Apple contrast vs light/dark are separate

<fantasai> Rossen: That's different

<fantasai> Rossen: There's “high contrast” which could be user-defined, e.g. yellow and black

<fantasai> Rossen: There are themes, dark theme and light theme, and blue theme, etc.

<fantasai> Rossen: Nothing to do with conrast

<fantasai> Rossen: Can have bad contrast with dark theme

<fantasai> Rossen: they're just dark

<fantasai> Rossen: What frremy is talking about is high contrast

<fantasai> Rossen: not about themes

<fantasai> florian: MS conrast MQ has two options, white-on-black and black-on-white

<fantasai> florian: Apple has independent control of hgih-contrast vs not and dark bg vs light bg

<fantasai> Rossen: What we wanted to do in high conrast was to guarantee readability. That's what high-contrast is all about

<fantasai> Rossen: Had to figure out how to isolate text and make it readable

<fantasai> Rossen: Make sure it has ghigh contrast, regardless of colors

<fantasai> Rossen: Two options are white-on-black and black-on-white, nothing to do with dark theme

<fantasai> florian: I disagree with frremy's statement that this si the smaething as what Apple is doing

<fantasai> myles: You said high-contrast is a collection of themes and you also talked about how Window shas theming

<fantasai> myles: You can choose one of the many high contrasts or your own theme but not both?

<fantasai> iank_ explores the Android Settings men

<fantasai> menu

<fantasai> Rossen projects Windows

<fantasai> Rossen: Here is Edge browser in dark theme

<fantasai> Rossen: UI of browser is dark

<fantasai> Rossen: Current theme f windows is dark

<fantasai> Rossen: In terms of readability, having images with text on top of them is not the best for readability

<fantasai> Rossen projects browser with dark chrome, but web pages are rendering as normal

<fantasai> Rossen: If I turn on high contrast

<fantasai> Rossen: Now what you see is that inside fo the browser, we have applied a numbe rof techniques

<fantasai> Rossen: Firstly, all fo the UI is in high contrast

<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

<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

<fantasai> Rossen: This is not observable by the web author

<fantasai> Rossen: In the past we would strip bgimgaes entirely, b/c we didn't know how to deal with it

<fantasai> Rossen: but htis is high contrast

<fantasai> Rossen: So that was high contrast

<fantasai> Rossen: So themes, are something esparate

<fantasai> florian: Within constrat, you can pick different styles of high contrast

<fantasai> Rossen: Right, so I can change the colors instead of having yellow on black, I can flip the colors

<fantasai> dino: Apple does that, but only for subtitles in videos

<fantasai> dino: We allow complete customization of captions

<fantasai> Rossen: We do this for everything

<fantasai> Rossen: We have predefined high contrast themes, e.g. white on black and black on white

<fantasai> Rossen: Also can have themes

<fantasai> Rossen: I can change the UI colors like this

<fantasai> Rossen: I can change just the borwser theme, even though the OS is dark theme

<scribe> ScribeNick: heycam

<TabAtkins> ScribeNice: TabAtkins

dino: do you have any mode to say turn off the transparency [in the panel]?

frremy: yes

dino: in accessibility?

frremy: no

dino: we have that option too, might be worth considering that for a MQ in the future, since some people find that distracting

fantasai: I think there's several things here we're talking about
... not the same thing
... 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
... that is outside the scope of what we're doing here

Rossen: that's what I wanted to point out

fantasai: we could make it in scope, if you wanted to try to match the theme, but we're not concerned with that today
... rather cases where the user wants changes in the content of pages
... then there's the request for: I want high constrast, and I want dark or not
... four states possible here
... actually more than that
... two axes here
... (whatever, high constrast, low contrast) x (whatever, light, dark)
... default state is whatever, page shows whatever. "light" would mean force dark backgrounds to be light etc.
... for (whatever, light), you don't care what the contrast is
... Windows doesn't have a (whatever, high constrast)

Rossen: that's not true
... you can choose some colors

fantasai: but you're not responding to what the author said
... there's no setting that says I see there are white colors on dark bgs
... which tries to detect "is this a dark themed page or light themed page"

Rossen: I agree
... this is how it will be for the forseeable future

astearns: you're talking about forcing things
... I thought we're talking about MQs
... where authors can key off of, and provide a high constrast experience, not forcing something
... if they're cared to provide one

fantasai: that's separate

Rossen: what francois was trying to describe is available
... currently we provide MQ to say y/n for high-contrast. and for the two default themes, light or dark, what it is

florian: when you say "y", in your MQ, you have something to let the author know high contrast has been forced with some colors
... fantasai is asking about a way with MQ to know if the page is forced constrast with its existing page colors

Rossen: of course not

chris_: [demos what Android does]
... has a Negative Colors option

dino: we have a MQ for that
... similar to the color-invert stuff

chris_: and there's a color lens thing
... lastly, color adjustment for different color blindness

myles: I have a question about Edge's MQs
... I turn on high constrast on Windows
... web page has a MQ that matches that
... in the MQ that says make text blue, whatever
... 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?

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
... for that particular element and its subtree, you can define whatever colors you want
... if you want to guarantee high constrast go ahead and do it

myles: got it

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

myles: is it possible to use that property to turn off high constrast handling outside the MQ?

Rossen: yes

florian: we have the thing Apple brought, is different from this
... because the Windows mode is about forcing the page into one of several high constrast modes
... and letting the author detect this has happend, and through the property let the author opt out
... the thing Apple brought is not detecting it has forced high constrast, but the user requested the page does it to itself

frremy: sure

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

dino: for Apple, yes, we don't force high constrast on any content

florian: there are multiple types of high constrast. some are preferences, some are enforced
... which you may be able to opt out or not

astearns: one of the distinctions in my mind about these things is that I don't think it's our place to specify browser forcing behavior as a CSSWG
... we're not going to specify anything that says "here's what happens when a browser forces changes on content"

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

<fantasai> y-axis has whatever | forced light | forced dark | prefers light | prefers dark

astearns: 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

dino: I agree
... and our request is only for the former
... we just want the user to indicate to the dev of the page they've made a preference decision
... the color-filter property discussed this morning is a hammer the dev can use to make it easier to satisfy one of those preferences, but it's not required

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

myles: I understand there are these two ideas how to implement these features
... is MS making a proposal to standarized their way?

Rossen: we made this a long time ago

astearns: but it's not the currenty issue

frremy: we'd be find having a pref to high constrast
... if we force high constrats the user prefers constrast
... if the user forces high constrast they prefer high constrast

<skk> Current description on the board: http://www.tsukune.org/skk/tmp/mq.jpg

TabAtkins: what do you think people will do when the MQ is true? prefer high constrast true?

frremy: make it high consrast

TabAtkins: but it's already happened by the UA

myles: he is imagining the content would turn on the property to say "don't do high constrast" and do it themselves

frremy: and it's more complex, if you don't set the property, and you have the prop in the MQ, it's applied anyway
... it will work
... if the define everything for prefer, it'll work

florian: in that direction it works
... if the page has been devised with Apple semantics in mind, and the browser does what you says, it'll work.
... 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

myles: if the page will do nothing why would it have this MQ

florian: it would turn off some subtle things?

frremy: this is not worse

fantasai: [whiteboard, chart of different combinations of preferences and forcing]
... you can get all the info you want on what kind of constrast you like or are forced into
... there really seems to be two sets of prefs
... one is about constrast, one is about light on dark and vv
... the MS MQ mixes them into the same thing
... you can have no pref, but also pref for high constrast
... or prefer high constrast, or I've been forced into high constrast
... you can treat them the same or distinct, as an author
... 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
... these are MQ values I've written

frremy: I would be find without these force values
... you can use the property to opt out of them
... if people want to know about them they can use the MQs

florian: MSDN says the high constrast MQ has been removed

Rossen: that's wrong

<skk> fantasai's description: http://www.tsukune.org/skk/tmp/mq2.jpg

fantasai: frremy your suggestion someone doing the same as MS must create their own vendor specific features to interop with you?

frremy: there is no browser who wants to match with us right now

astearns: if they want to we can bring something to the group

fantasai: we have to standardize their extensions with their syntax

dbaron: interoperate with what aspect of what MS does?
... Gecko has certainly to reacted to windows high constrast theme settings in various ways, probably differently from Edge
... it doesn't override a lot of colors

emilio: we disable author :) colors

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

<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)

dino: one point, I don't know if we need a prefers-contrast:low

Rossen: actually there is a dyslexia adaptation ...

florian: we described the way you react to high 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, [...]

Rossen: if you're responsibel you will query the colors

fantasai: you can't do that

Rossen: you can

fantasai: not in a x platform way

dino: what do people think of the brightness name? I didn't like the term "dark mode" or "dark content". but "brightness" is a bit weird...

fantasai: I just put that up because I needed a word

florian: I would go with something like "color theme", but that might be confused with UI theme...
... preferred color scheme?

fantasai: it's about the content
... there's the theming scheme, which we might expose at some point in the future, and the prefers light vs dark

<br type="afternoon-tea">

<myles> The proposal is two media queries: prefers-contrast: none | high | high-forced | low | low-forced, and prefers-brightness: none | light | dark | forced-dark | forced-light | forced-something

<fantasai> alternately prefers-contrast: none | high | low | forced

<fantasai> or prefers-contrast: none | [ high | low ] || forced

<astearns> not sure preferring no contrast is a thing

end

<astearns> ah, no issue

<fantasai> lol

<fantasai> Florian says the actual keyword for these things is no-preferences to avoid such nonsense :)

prefers-reducued-data MQ

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

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

myles: how does chrome know when to send the header?

philipwalton: I think it's from the OS on Android

iank_: there's a setting Chrome, prefer lightweight data, then we send everything through potentially an HTTP proxy
... few other things as well

florian: is it user triggered

iank_: yes
... but I'm not sure, might be varied on country basis
... we run HTTP proxies where we'll send traffic through that, then do a bunch of compression for the user

myles: so the proxy might turn on the header?

iank_: no
... the proxy is one of the side effects from turning on this option
... and I think the bit of information that we give devs is on navigator.connection.saveData

philipwalton: it's a client hints header, in the clients hint spec

florian: somebody proposed to detect this via MQ

fantasai: seems reasonable to me

astearns: is that header, are there plans for other browsers to implement this?

fantasai: wht values does the header have?

philipwalton: I think it's just a boolean at this point
... but the spec is written in a way that it could apply additional values

fantasai: I can imagine wanting three levels, i don't care, I would prefer if you didn't give me heavy things, I'm on a metered / dialup connection

<astearns> http://httpwg.org/http-extensions/client-hints.html#save-data

iank_: quickly looking through the additional things we expose, we also give as headers (what we think is the effective) roundtrip time
... an estimate of the downlink speed

philipwalton: and effective connection type

heycam: mobile vs fixed?

iank_: 3g, 4g, slow 2g, ....

florian: don't think we'd expose all that
... via the MQ
... having something that can be used in a boolean context, where one case is no preference, and may have other "yes please" levels

iank_: one thing I'd like to see here is use cases for where it's used in CSS

florian: use image bg instead of video bg

iank_: do that with script

philipwalton: 1x vs 2x?

florian: browser should do that already

[side discussion about font-display:optional]

philipwalton: with save data, 1x vs 2x, could be your device supports 2x but you only want a smaller version of the image

florian: mostly you should not be using resolution MQ feature, but instead image-set
... then the load data preference could influence that

myles: maybe terribly idea, can we extend that mechanism to allow switching between videos and images as backgrounds, instead of a MQ?

fantasai: MQs are not only used in CSS

emilio: responsive images

iank_: I'm not saying no, but I want to see web developer demand for this

astearns: that's the general tone I'm hearing
... sounds like it could be useful, but we'd need to have it motivated by use cases and I'd prefer to see this client hint get a bit farther on the track

florian: sounds ok

koji: this is an Android OS setting

ericwilligers: it's both Android and a Chrome setting

porting media groups

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

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

dbaron: I think the reality is there's been not a lot of implementation of CSS for anything other than visual media
... and what implementation there has been hasn't provided feedback to the WG, so the specs don't account for it well

florian: the animations and transitions properties claim to work on interatctive media, not visual
... 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
... which is wrong
... so we could define it in a way that's correct
... but it's still not useful

frremy: makes sense to me

myles: is it valuable to say you can't animate on a piece of paper?

RESOLUTION: Remove Media line from all propdef tables

<mf-range>

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

florian: (width < 100px) is allowed in MQ L4
... it also lets you do (100px > width) which people don't care about strongly
... but they also let you do (50px < width < 100px)
... Firefox has implemented the first one
... and claimed that the second two are more difficult to implement

emilio: it's not that I'd like not to, it's that it's somewhat annoying
... 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
... and identifiers can also be media feature values
... 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...

florian: I think the third option is nice
... 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

emilio: I think if we're going to keep the last one, we may as well keep the previous one

astearns: doesn't make it much easier
... are you the only ones implementing this?

emilio: I think so, so far

frremy: that was two weeks ago

ericwilligers: I think this is clear:

width < 100

100 <= width < 200

200 < width

ericwilligers: with the last one the width on the RHS

florian: if removing the middle one was a signficiant simplification, we can do it, but sounds like not

RESOLUTION: Close this issue with no change

end

porting media groups

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

fantasai: I ran a grep through the tree
... almost everything is Visual, some exceptiosn
... interactive vs not is not interesting
... but we distinguish between CSS props that shuld affect the accessibility tree, and the ones that shouldn't
... or don't
... content prop affects what shows up to a screen reader
... display does

astearns: how is that expressed?

florian: by Media: all

astearns: are we consistent about that?

fantasai: yes
... props that should add or remove content from the a11y tool
... it's an indicator to the screen reader as to what content should be added or skipped

florian: I think it's not about screen readers
... it's about audio rendering

fantasai: yes, but if we remove this, we need to make sure we're very clear in the spec, explicit wording to say this prop needs to affect non visual things

dbaron: I think if that was the intent of the spec, I suspect most implementors missed it
... I think it would be good to have the wording in some other way

astearns: I think it would be an improvement to be explicit, rather than hide it here

frremy: most of these things, if they're defined, are in ARIA, they explicitly call out the properties and what you should do with them

florian: for a11y, probably, for visual and non-visual media .... for the ones that say "all", a normative statement that says "this works on all media" is fine

astearns: it should be more explicit
... "such as, screen readers"

florian: no
... they don't work like that
... they're a visual media

fantasai: but they're also not handling gencon properly

Rossen: they do

frremy: in Edge it works perfectly

fantasai: but it is a common bug

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

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

astearns: would that be enough?

dbaron: sure

fantasai: we should have these kinds of sentences anyway. in the propdef table it's easy to look up which ones you need to care about
... but it takes up a lot of space
... removing from the propdef table is a benefit overall
... we should add a statement explaining normatively that CSS requires these to work
... we're defining what the properties mean and how they're interpreted, ARIA then uses that

RESOLUTION: Add a normative statement for properties that say "Media: all" explaining what "Media: all" meant.

<florian> ScribeNick: Florian

Bikeshed the 0 specificity alternative to :matches()

<leaverou> Table: https://github.com/w3c/csswg-drafts/issues/2143#issuecomment-360586470

<dbaron> github: https://github.com/w3c/csswg-drafts/issues/2143#issuecomment-360586470

ericwilligers: [projets the issue]

fantasai: if we have :not and :is, they should have the same specificity

ericwilligers: matches has changed specificity recently

fantasai: that's out of scope here

ericwilligers: :when was time based, so I proposed :where, haven't heard back

astearns: does anyone have problem with :where ?

leaverou: has does that avoid the problems that :is has?

fantasai: because :is and :not need to be opposite

leaverou: how about having :is-not be the opposite of :is

all: Noooo

frremy: :where works for me

ericwilligers: has to combine well with :not()

leaverou: why can't we change :matches? it has shipped, but nobody uses it yet

astearns: we've discussed doing it several time, and failed to reach consensus

fantasai: lea propose to just change the specificity of :matches, and add a new one for the other specificity

frremy: why use the :match name at all, it's a bad name

leaverou: we're stuck with it anyway

fantasai: I want a short list so that we can think about it

leaverou: would you object to :is if it did what matches currently does, and :match() is the 0 specificity one?

fantasai: no, I would not

leaverou: what if we just have one, with an argument for specificity

fantasai: too confusing

shane: :where makes sense for people who have used SQL, but for others it is confusing, and seems to involve position

<dbaron> Whiteboard:

leaverou: I find SQL readable, but that's because it's a full sentence, which isn't the case in css

fantasai: I like 2 and 4

<Rossen> Here are the options

<dbaron> 1. :is()

<dbaron> 2. :matches() + replace existing :matches() with :is()

<Rossen> 1. :is()

<Rossen> 3. :if()

<Rossen> 4. :also()

<Rossen> 5. :where()

frremy: :and means nothing to me, all selectors already imply that

<Rossen> 6. :selects()

fantasai: yes, but :also doesn't have that implication

leaverou: in favor of :also

Rossen: [makes funny inaudible jokes]

dbaron: we have an html element called select

Rossen: let's start removing
... kill select

ericwilligers: I think we can also kill :if

Rossen: :if would need an :else

frremy: why?

<Rossen> 7. :also() + replace existing :matches() with :is()

leaverou: I'd like 7

frremy: this was called that way because the DOM API is called that

fantasai: actually, it's very old and it's the other way around

ericwilligers: it has been in webkit for a long time

astearns: how much web content uses :matches?

iank_: not a lot, looking at usecounter

ericwilligers: usecounter may be wrong

<dbaron> "the other way around" was in reference to original name being :any or :matches.

Rossen: is either 2 or 7 an option? they involve changing :matches. webkit people, can we do that?

myles: we could
... we would be moderately interested in updating, but it's low priority

dino: why ?

fantasai: because a best named proposal otherwise is :is, but it is bad if it's specificity doesn't match :not
... so we could change :matches to be the 0 specificity one, freeing the room for :is to do what :matches does now

leaverou: maybe we can resolve on that in parts

fantasai: removing option 1

<dbaron> I implemented :-moz-any() in Gecko in 2010 in https://bugzilla.mozilla.org/show_bug.cgi?id=544834

fantasai: the web compat impact of 2 and 7 are different

ericwilligers: does anyone want 2?

fantasai: removing 2

[lots of people]: I don't like also.

[lots of people]: [lots of jokes]

leaverou: what's wrong with :also ?

<Rossen> :soso()

dbaron: :also comes after something, but it doesn't come after anything particular

Rossen: agreed (with a pun)

ericwilligers: :where implies position OR situation

fantasai: does :where not have the same problem as :also?
... :matches does not have that problem

frremy: I prefer :where and :if, and :if makes a lot of sense when you read it

<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.

astearns: :if clashes with JS?

[lots of people]: it doesn't
...: :if calls for :else
... it doesn't

philipwalton: 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.

heycam: one option was to have a specificity parameter in :matches

astearns: we have agreed that renaming :matches is not necessary to solve this
... we rejected some of the options, we should make a smaller list of plausible

fantasai: we should make a strawpoll, and then call for objections on the most popular
... :if gets 7 votes
... :also gets 1.5votes
... :where gets 7 votes

astearns: objections to :if ?
... objections to :where ?

leaverou, fantasai, iank_: strong reservations

<tantek> let's strawpoll if vs where!

astearns: I am not declaring consensus
... we will ask outsiders about :if vs :where

getComputedStyles and shorthands

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

emilio: FF and Edge only support getComputedStyle on shorthands that used to be longhands, Blink supports more
... shorthands in the computed style object are exposed as properties
... I want to know what people want. Fine with changing, but it's work

ericwilligers: if it was a longhand, it would serialize

TabAtkins: it needs to

emilio: there are bugs on the grid shorthands
... People have argued various ways.

TabAtkins: this is an obvious forward compat mistake
... all properties from now on should support it
... 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
... which doesn't seem to be the case

dbaron: if it's not possible to represent, then we have to go for empty string

TabAtkins: that's fine

<TabAtkins> It's still forward-compatible; adding a new property to the shorthand will never make it, by *default*, stop serializing

emilio: there's also the question of computed values vs resolved values

heycam: it would be very weird if the longhands resolved but the shorthands didn't, so we should match
... Edge is the only other browser not doing it. So Edge?

emilio: Edge, are you OK with doing it? the only ones you have on top of used-to-be-longhands are grid properties.

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.

TabAtkins: going forward, we need to.
... 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.

emilio: It can be done quite easily for lots of properties

Florian: can we resolve to do on all, even if priorities means it might take a while

Rossen: we need consistency, so let's have it everywhere.

RESOLUTION: all shorthands must show up in getComputedStyles

xidorn: I wonder if you should see the shorthands in the iterator
... I think there's a usecase for copying computed values from one element to another, and they just iterate through

myles: This should be a separate issue.

[mumble mumble]

What should getComputedStyle return for an element which isn't in the flat tree?

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

emilio: frremy added that, but we already resolved

frremy: it's a bot bug, nothing to talk about

<emilio> Was resolved on https://github.com/w3c/csswg-drafts/issues/1548#issuecomment-380383455

none

Consider disallowing NULL code points in stylesheets

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

<emilio> myles: lol

TabAtkins: [trying to find the original bug]

Rossen: what's left to do?

Florian: for TabAtkins to argue his case against our previous almost-consensus

github: none

css nesting

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

TabAtkins: we tried to discuss that a while back, but didn't have time to conclude. Should we rediscuss, or re-resolve

<TabAtkins> https://tabatkins.github.io/specs/css-nesting/

myles: I want an overview

TabAtkins: nesting style rules is a common request, and a feature of every css preporsessor in existence
... and one of their most popular feature
... makes stylesheets much easier to maintain
... it is purely syntatic sugar, but is worth covering because of the huge demand
... the way they're done in preprocessors are ambiguous with properties
... My propose spec disambiguate with by using &
... you can use & at the front, and if you want it elsewhere, you can use @nest to keep things unambiguous

<TabAtkins> a:hover ....

TabAtkins: the above looks like a "a" property with a "hover" value
... CSS parsing only requires a finite amount of lookahead, and we'd like to keep it that way

leaverou: isn't it only a problem when the tag selector is the first part of the selector

TabAtkins: I don't like that because it's not obvious, and hard to teach

fantasai: you could pick a random character to start every rule with

TabAtkins: yes, that's what "@nest" do

frremy: replace @nest with &

<TabAtkins> & &.foo {...}{

TabAtkins: it's ambiguous

Florian: I don't like it, @nest is nicer

leaverou: that would be hard to read

<frremy> &:hover

<frremy> & > span > &

frremy: you only include it if needed

<TabAtkins> & span:not(&) {...}

TabAtkins: other bad example ^

<frremy> (I was convinced by the clarification that the & can be replaced more than one in the selector , which I didn't know)

<myles> -q

heycam: can we require starting with a combinator (and use an explicit descendant combinator)

TabAtkins: doesn't solve it for & in the middle

fantasai: if you use @nest, use it everywhere. If you think that's too verbose, choose a different disambiguator. Alternating between using @nest and not is not great

TabAtkins: too verbose

heycam: @nest introduces a block?

leaverou: ????

TabAtkins: very hard to express in grammars
... in the most common cases, stating with an ampersand is short, which is important

fantasai: use something shorter than @nest

Florian, fantasai: how about naked @

myles: we don't have to bikeshed the syntax if we're just talking about adopting the module

<leaverou> fantasai, or naked & to introduce a nested block? /* just throwing ideas! */

astearns: objections?

frremy: does it need to be a new module?

florian: no, but it's nice that way

astearns: objections?

fantasai: ED is fine, want to bikeshed the syntax before FPWD

<fantasai> fantasai: Seems like nobody is really happy with the spec as-is

xidorn: no objection, but my concern is that it expands in some cases into :matches() like things
... and that's hard to optimize

TabAtkins: you can expand them out fully

emilio: how about the OM?

TabAtkins: not expanded in the OM, rules get a .childRules object

xidorn: that makes it hard
... because of the combinatorial explosion

florian: we still have to deal with that in preprocessor generated sylesheets

<fantasai> ScribeNick: fantasai

astearns: Hearing no objections to starting work on the module. Hearing a lot of issues against it.
... Anyone else interested in heping Tab?

RESOLUTION: 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

serialization of <position>

<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.

<ericwilligers> github: https://github.com/w3c/csswg-drafts/issues/2274

<ericwilligers> "<position> is always serialized as 2 or 4 values." or "Neither component may be omitted when serializing."

ericwilligers: I thin we've completely resolved serialization of <position>

fantasai: We already resolved that <bg-position> should serialize same as <position>

<ericwilligers> How exactly does "left 10% center" serialize?

fantasai: Need to resolve that keywords are serialized out in specified value if originally specified as keywords (and not otherwise)

emilio: In which order?

ericwilligers: Horizontal first

emilio: And always both

ericwilligers: Yes

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
... But you preserve the keywords

ericwilligers: ...
... We're talking about specified values only atm
... Edge sometimes serializes as percentages rather than keywords
... For certian properties

https://github.com/w3c/csswg-drafts/issues/2274#issuecomment-402330108

<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."

scribe:

<ericwilligers> https://drafts.csswg.org/css-values/#position

<ericwilligers> https://drafts.csswg.org/css-backgrounds-3/#propdef-background-position

astearns: Any objections to specifying that specified values are serialized as keywords if specified as keyword sand percentages if specified as percentages?

RESOLUTION: above

RESOLUTION: Any objections to specifying that specified values are serialized

as keywords if specified as keyword sand percentages if specified as

percentages?

ericwilligers: If 3 values are specified, we'll need to turn into 4 values

<heycam> ScribeNick: heycam

ericwilligers: : "left 10% bottom" -> "left 10% bottom 0%"

<dbaron> There was a discussion about 'left 1% center" which is apparently no longer a valid <position> but is a <bg-position>.

ericwilligers: "left 10% 20%" -> "left 10% top 20%"

fantasai: if we need a keyword we use top or left, if we need an offset we add a percentage

ericwilligers: plus a weird case for center

<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%"

astearns: and there's text in Shapes that does everything you said, except that shapes will convert bottom to top 100%

ericwilligers: we've resolved to remove that text, but I can reuse it

astearns: I don't mind if it stays as bottom or converts to top

fantasai: so left 10% bottom 0% would stay as is, but left 10% bottom would become left 10% top 90%?

astearns: yes

fantasai: if we're preserving the keyword in the case we have the offset, may as well when we don't too

emilio: does everyone support 3 values on background-position?

fantasai: yes

astearns: we ripped it out everywhere we could, but had to leave it there

emilio: ok, I'm fine with that

RESOLUTION: 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.

ericwilligers: earlier talking about computed values, I was incorrect to say we never give keywords. we do sometimes!
... but I don't think we should
... I propose for computed values, it's always <length-percentage>

Rossen: or calc()

astearns: so for computed values of <bg-position> and <position>, they are always two <length-percentage> values
... no keywords, calc() if needed

RESOLUTION: For computed values of <bg-position> and <position>, they are always two <length-percentage> values.

<dbaron> github-bot, end topic

<dbaron> trackbot, end meeting

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/let/(sarcastically) let/
Succeeded: s/Accept the proposal/<color> in <shadow> should default to currentcolor/
Succeeded: s/outside/removed/
Succeeded: s/Rossen: yeeeeeup//
Succeeded: s/fantasai/ericwilligers/
Succeeded: s/int eh/in the/
FAILED: s/positions the way gradient stops do them, but rather widths that stack//
Succeeded: s/alreadya chive/already achieve/
Succeeded: s/The/Some/
FAILED: s/all a/allow a/
Succeeded: s/What about color variables?/What about custom properties that have been defined to accept <color>?/
Succeeded: s/form/built-in form/
Succeeded: s/canvas/body/
Succeeded: s/wher eyou d'want/where you'd want/
Succeeded: s/sTGB/sRGB/
Succeeded: s/see the use case/see the use case for the color-filter property/
Succeeded: s/Elika/fantasai/
Succeeded: s/computations/permutations/
Succeeded: s/tim/time/
Succeeded: s/disallowed/invalid/
Succeeded: s/thin kso/think so/
Succeeded: i/myles/fantasai: order for interpolations falls out of cross-fade(start, end) and flattening
Succeeded: s/.../emilio: So it would be a longhand/
Succeeded: s/.../Expanding at parse time is how shorthand is supposed to work/
Succeeded: s/.../so the space taken up by the browser UI is only known when the UI is showing/
Succeeded: s/.../also you don't know when exactly to start counting those seconds/
Succeeded: s/dbaron:/?:/
Succeeded: s/hardward/hardware/
Succeeded: s/?:/dino:/
Succeeded: s/four/force/
Succeeded: s/alpha/cauthor/
Succeeded: s/cauthor/author :)/
Succeeded: s/srcset/image-set/
Succeeded: 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./
Succeeded: s/we need/we need to./
Succeeded: s/any/every/
Succeeded: s/everywhere/everywhere. If you think that's too verbose, choose a different disambiguator. Alternating between using @nest and not is not great/
Succeeded: s/just//
Succeeded: s/fantasai:/fantasai,/
Succeeded: s/as-i/as-is/
Succeeded: s/in the OM/in the OM, rules get a .childRules object/
Succeeded: s/"left 10% right"/"left 10% bottom"/
Succeeded: s/"left 10% right 0%"/"left 10% bottom 0%"/
Default Present: tantek
Present: tantek myles skk fantasai TabAtkins Rossen heycam xidorn leaverou philipwalton astearns eae ericwilligers dino dbaron plinss chris
Found ScribeNick: fantasai
Found ScribeNick: heycam
Found ScribeNick: heycam
Found ScribeNick: Florian
Found ScribeNick: fantasai
Found ScribeNick: heycam
Inferring Scribes: fantasai, heycam, Florian
Scribes: fantasai, heycam, Florian
ScribeNicks: fantasai, heycam, Florian

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 03 Jul 2018
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)