– DRAFT –
Cascading Style Sheets (CSS) Working Group Teleconference

MediaQueries length units in video-*

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

<fantasai> florian: Issue has evolved since opened

<fantasai> florian: reminder, we specified video-width/height/resolution

<fantasai> florian: video prefix is about video playing that some devices like TVs have, where they superimpose a special canvas with different characteristics for playing video

<fantasai> florian: About a year ago we were talking about this and thinking that actually, maybe MQ isn't what's wanted

<fantasai> florian: The typical query of width is about whether bigger or smaller than some value

<fantasai> florian: but not used for that

<fantasai> florian: use cases were that ppl wanted to ask "what is the size of the screen, in physical pixels"

<fantasai> florian: The only way to do via MQ is via binary search in MQ, which is not great

<fantasai> florian: So conclusion of discussion is not to have an MQ, and instead have some extension to CSSOM where you can query for the pixel ratio of the video playing of the device

<fantasai> florian: since can already know size of viewport, can get the size of the whole screen

<fantasai> florian: or if interested in size of an element, can go from the size of that element

<fantasai> florian: So the suggested resolution for MQ is to remove video-width/height/resolution MQ

<fantasai> florian: and another resolution would be for CSSOM to add window.deviceVideoPixelRatio

<fantasai> Rossen_: Opinions on this?

<fantasai> smfr: I'm a little concerned about multi-screen systems

<fantasai> smfr: window is associated with a single screen

<fantasai> smfr: if showing video, is it on the same screen/window?

<fantasai> smfr: idk how to know that

<fantasai> smfr: imagine you have two screens, right hand is dedicated to video presentation

<fantasai> smfr: somehow magically when you present video, it shows up on the right

<fantasai> smfr: but window object is associated with the left hand screen

<fantasai> smfr: so would be weird if it reported characteristics of right hand screen

<fantasai> chcunningham: Is this possible today?

<fantasai> smfr: UA thing, UA could decide to send fullscreen video to a particular screen

<fantasai> florian: I think as far as TVs are concerned, and things with this multiplane rendering, it doesn't behave the way you described

<fantasai> florian: more general browsers/setups, could be other setups

<fantasai> florian: the window object is probably not designed for that, but this is a more generic problem than video specifically

<fantasai> florian: 2nd Screen effort is trying to deal with that

<fantasai> florian: but for the TV use case, I don't believe that's how they work

<fantasai> Rossen_: to go one step further, in conjunction with some of the newer foldables and dual-screen efforts

<fantasai> Rossen_: I know of at least one effort that is work happeneing on ??? that have to do with dividing up the window into multiple segments

<fantasai> Rossen_: multiple screen divided by segments or hinge

<fantasai> Rossen_: here we have one window spanning two surfaces

<fantasai> Rossen_: video having controls on one different screen is very typical

<fantasai> florian: Does this device have a multiplane rendering thing?

<fantasai> florian: typically TVs do this, typical screens don't have two planes that can be queried separately

<fantasai> Rossen_: we have one window object that will be present on both physical screens

<fantasai> Rossen_: is expectation that devicePixelRatio returns ...

<fantasai> florian: I think the question is legit, if you have this multiplane thing with two resolutions on one screen, we have this problem for the window object in general

<fantasai> florian: this is a good problem to address if such devices exist, but there's nothing specific to video about it

<fantasai> Rossen_: there are some laptops that have a pane over the keyboard, so you can present into those

<fantasai> Rossen_: but might be represented by two different screen objects

<florian> fantasai: don't smfr 's concern apply to the regular to the regular device pixel ratio as well?

<florian> fantasai: if so, we need to address it there as well

<fantasai> smfr: devicePixelRatio doesn't have this same issue

<fantasai> smfr: if I drag window over, devicePixelRatio will change

<Rossen_> fantasai: I understand the concern. We need to address the multi-resolutions for devicePR and other API. Adding a parallel API for these is what makes most sense.

<fantasai> smfr: issue with video one is that video presentation is special, and UA chooses that it will be displayed in magic extra plane with different properties

<fantasai> florian: We're not talking about picture in picture or displaying window in other places

<fantasai> florian: but for TVs, they have two framebuffers layered over each other in the same spot

<fantasai> florian: They have the normal layer transparent, punch video through to underlying layer

<fantasai> florian: which has different resolution

<fantasai> florian: in current devices, this would be on the same scree

<fantasai> florian: a browser could have two different videos on different screens, but that's a very different setup than here

<fantasai> smfr: I understand, I just don't want us to design a problem for foldables

<fantasai> florian: Let's just resolve to remove the MQ for now

<fantasai> florian: and maybe we can open an issue for the deviceVideoPixelRatio

<fantasai> florian: I don't quite see the problem, because whatever problem you're describing seems to apply equally to devicePixelRatio

<fantasai> Rossen_: Anyone from the video group want both resolutions?

<fantasai> fantasai: smfr, why does your concern apply to deviceVideoPixelRatio and not devicePixelRatio?

<fantasai> smfr: Because it applies to fullscreen, which is more likely to be on a different screen

<fantasai> florian: This isn't necessarily about fullscreen video.

<fantasai> florian: if you have youtube playing in the middle of your web page, you would apply this ratio within the video

<fantasai> smfr: No, I don't think so, I think it only applies to fullscreen

<fantasai> Rossen_: If presentation spans multiple screens, e.g. projector, very different characteristics than PC, wouldn't problem apply to that as well?

<fantasai> florian: And doesn't necessarily apply to fullscreen only, that's up to the author

<fantasai> florian: Yes, youtube or hulu or whatever video service can be played fullscreen sometimes

<fantasai> florian: but might also want to query in normal rendering mode

<fantasai> florian: and since hardware accelerated, would still go into special plane

<fantasai> smfr: wouldn't be the case in Apple devices

<fantasai> smfr: I think we should ask experts for feedback

<fantasai> smfr: I think it would be very confusing for author

<fantasai> Rossen_: Let's go with resolving to drop the MQ

<fantasai> Rossen_: it's clear we need to work more on the rest of the API

<fantasai> Rossen_: Any objections to dropping MQ?

<fantasai> smfr: I support that

RESOLUTION: Drop video-width/height/resolution media queries

<fantasai> Rossen_: send rest of conversation back to the issue

<fantasai> florian: Should I retitle the issue, or file a new one?

<fantasai> Rossen_: new issue might be helpful to have clear slate, but history etc. might be useful

Mediaquery dynamic-range

<fantasai> florian: had a discussion awhile ago, explored idea that dynamic-range was a complicated concept

<fantasai> florian: because maybe some devices have modes where high dynamic range is active or not

<fantasai> florian: and maybe UA supports for videos, but not CSS, or for images but not canvas

<fantasai> florian: Could say the same thing in theory about other things like color depth, but we didn't expose this per element or anything

<fantasai> florian: idea is to clarify and fix the spec to match what Safari is currently shipping

<fantasai> florian: One difference is that we have standard and high as values, and want to align this media feature to the same sort of behavior we have with color-gamut

<fantasai> florian: where the smaller one matches when larger one is matched

<fantasai> florian: so that modes nest

<fantasai> florian: so that if more extended values exist in the future, compatible with content now

<fantasai> florian: Wrt querying device or UA

<fantasai> florian: text puts more emphasis that needs to be the combination of UA and device

<fantasai> florian: but no particular need to draw attention to that here, since true of all MQ

<fantasai> florian: tldr is spec what Safari does, because that's what we want

<fantasai> Rossen_: proposal is?

<fantasai> florian: Currently spec doesn't say that standard and high can match simultaneously, it's either-or

<fantasai> florian: change it that if match high also match standard

<fantasai> florian: everything else is editorial

<fantasai> Rossen_: We have other MQ like that

<smfr> i agree

RESOLUTION: dynamic-range: standard also matches when dynamic-range: high matches

<fantasai> +1

Allow empty functions in <general-enclosed>

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

<fantasai> TabAtkins: We had some leftover grammar from a previous change that accidentally implied that if you had a <general-enclosed> in functional form it had to ahve something inside the parens

<fantasai> TabAtkins: previously could be empty

<fantasai> TabAtkins: small change to make the value optional, so that foo() would be valid

@media fn() {...}

@media fn(foo) {...}

<fantasai> TabAtkins: wanted to make sure this counts as <general-enclosed> with unknown value rather than syntax error

<fantasai> florian: asking for approval because spec is in CR

RESOLUTION: Accept change to allow empty functional notations in <general-enclosed>

Highlights and currentcolor

<fantasai> delan: Started discussing this issue last week, but only got partway through

<fantasai> delan: about special case of setting 'color: currentColor'

<fantasai> delan: outside of highlights, it means 'color: inherit'

<fantasai> delan: for highlights, actually means something else

<fantasai> delan: there were 2 questions originally, now 3

<fantasai> delan: 1st question, double-checking, spec says when setting to currentColor, do we want to grab color from next highlight layer below regardless, or only active highlight layers

<fantasai> delan: fantasai said it only makes sense to use active highlight layer, and I think everyone agrees on that

<fantasai> florian: I'm a little unsure, agree with that assessment, but discussion last time suggested maybe there was a whole different way to think about this

<fantasai> delan: that's the 3rd question, whether this is the right way to solve the problem that it solves

<fantasai> delan: 2nd question is, if it is the next active highlight specifically, then what happens when you getComputedStyle?

<fantasai> delan: getComputedStyle needs to return resolved colors, so has to return an actual color

<fantasai> delan: if you have an element with multiple underlying colors, what do you do

<fantasai> delan: currntly a few ideas on how to address that

<fantasai> delan: 3rd question, which emilio brought up, this exceptional behavior of currentColor for highlights is odd and complicated

<fantasai> delan: wondering if this was the right way to solve the problem, or if better way to solve the problem

<fantasai> delan: To clarify, best example of a use case for this, is the spelling and grammar error pseudo-elements

<fantasai> delan: a typical styling for that would be to add a red or green squiggly line to the text

<fantasai> delan: but you're just adding the decoration, you don't want to change the color of the text

<fantasai> delan: if you spell a word, still want to have the same text color

<fantasai> delan: but given way highlight painting works, if we didn't have this rule for currentColor, then there would be no way to highlight something without changing the color to 'initial' (black)

<fantasai> delan: it's complicated and an odd exception, but we need some solution to this problem

<fantasai> florian: one extra bit, suggestion last time is that this might be similar to ::first-line

<fantasai> florian: we don't redefine how currentColor works, we redefine what inherits from what

<fantasai> florian: if you set currentColor on first line, it'll get its color from ::first line

<fantasai> TabAtkins: I'm not certain about best way to handle property itself, but for purpose of getComputedStyle I think it's reasonable to say "pretend it's not selected at all", so just get underlying style

<fantasai> TabAtkins: that seems the most straightforward, and doesn't leak info about spelling/grammar errors

fantasai: WE also have to consider that when you set the - we have paired cascading, and it sets to "the color it would have already been" it sets the background, so this behavior needs to represent that as well

<fantasai> emilio: does this really only apply to currentCOlor? seems applies to inherited properties applied to highlights

<fantasai> emilio: maybe color is the only one atm

<fantasai> emilio: seems you'd have the same problem with text-fill and other things

<fantasai> emilio: so, in general, I think the right fix would be inheritance, but that might be annoying to implement

<fantasai> delan: Tab, is it true that you mean same thing as emilio, wrt Q2, my understanding is that if you ask for getComputedStyle for ::selection, we pretend everything is selected and no other highlights apply

<fantasai> TabAtkins: no opinion on pretending selected or pretending not selected, defer to impl on that question

<fantasai> TabAtkins: but ignoring any other highlights is the important bit

<fantasai> delan: sounds like a straightforward solution to that, I agree

<fantasai> delan: wrt Q3, inheritance and possible parallels with ::first-line

<fantasai> delan: I'm not that fresh on ::first-line and ::first-letter

<fantasai> delan: can someone explain how it would work for us to sometimes inherit from another highlight (grab color from ancestor highlight) while still inheriting within this inheritance tree for ???

<fantasai> emilio: I think that's the hard part

<astearns> github: https://github.com/w3c/csswg-drafts/issues/6818

<fantasai> emilio: My selection styles inherit from my parent selection styles

<fantasai> emilio: E.g. selection style inherits from other highlight which inherits from regular text which inherits from parent selection style

<fantasai> delan: ...

<fantasai> delan: ::target-text inherits from ::selection style??

<fantasai> emilio: whichever order we decide on...

<fantasai> emilio: for simplicity, say we have ::selection and ::spelling-error

<fantasai> emilio: say ::selection inherits from ::spelling-error, and ::spelling-error inherits from parent ::spelling-error

<fantasai> emilio: I think that would get you the right behavior

fantasai: It would not, because if ::selection inherits from ::spelling-error, and that inherits from parent ::spelling-error, it'll never inherit from the parent selection

<fantasai> emilio: ::spelling-error inherits from ::selection

fantasai: Why would spelling-error inerit from selection?

<fantasai> emilio: ::spelling-error inherits from ::selection

<fantasai> fantasai: that doesn't work

fantasai: can you give me an example of the zigzag?

fantasai: there's two pseudos - selection paints over spelling-error - what's the inheritance chain?

<fantasai> delan: So you go in a zigzag, our ::selection inherits from our ::spelling error, and our ::spelling-error inherits from our parent's ::selection, which inherits from parent's ::spelling-error, etc.

child selection -> child spelling error -> parent selection -> parent spelling-error

<fantasai> fantasai: Why would it make sense for ::spelling-error to inherit from parent's ::selection?

fantasai: Why would it make sense for spelling error to inherit from the parent's selection?

<fantasai> emilio: I guess it doesn't quite...

<fantasai> delan: when you jump back in the zigzag, you have a lower layer inheriting from a higher layer

<fantasai> delan: it's hard for me to imagine this

fantasai: imagine spelling was red, seleciton was blue

fantasai: you highlight some things

fantasai: the zigzag means you'll get red text when you highlight, if the parent has an spelling error

<tantek> This (special inheritance across pseudo-elements) seems confusing enough to the WG that I can't imagine authors actually coming up with a predictive mental model for what is going on.

fantasai: seems weird

<fantasai> Rossen_: Seems work to do here, need to decide if we are going to rethink through inheritance or to tweak existing model

<fantasai> delan: This is a valid conversation, about solving via other mechanism

<fantasai> delan: but wondering if we can resolve Q1 and Q2, based on assumption that things work the way specified now using currentColor

<fantasai> delan: and later if we want to solve a different way, we can do that?

<fantasai> Rossen_: Makes sense to me

<dbaron> I *think* one of he goals here is that which of grammar-error/spelling-error/target-text/selection's styles wins does *not* depend on which elements are associated with the selectors (and how they nest), but rather on a spec-defined order of the pseudos.

<fantasai> florian: I support doing this. Earlier Tab suggested that you put either everything selected or nothing is, suggest assuming everything because otherwise no point in querying ::selection

<fantasai> delan: I thought question was between nothing or pretending that just the pseudo you asked for

<fantasai> florian: that's the one

<fantasai> florian: answering that just the pseudo you asked for is everywhere and nothing else

<fantasai> florian: It's not useful to assume no highlights at all

<fantasai> emilio: I think that's the current behavior

<fantasai> emilio: I'm moderately sure that querying ::selection will get you the ::selection styles

<fantasai> delan: pretendign everything else not selected also solves, what happens if ::selection leaks a color from ::spelling-error or ::grammar-error, which we made it forbidden for privacy reasons so this solves that problem

<fantasai> emilio: it's also simpler, fixes privacy leak

<fantasai> florian: alternative we mentioned last time was to fragment things, and answer question about first one, but overkill for no good reason

<fantasai> delan: don't think anyone needs that answer

<fantasai> florian: if we really needed that answer, we'd need an API to reply on each individual fragment

<fantasai_> delan: For Q1, proposing that we say that when you say 'color: currentColor' on a highlight pseudo, you grab the next active highlight's color

<fantasai_> delan: so that color is as if this highlight wasn't applying

<fantasai_> emilio: ...

<fantasai_> fantasai_: currentColor computes to itself

<fantasai_> emilio: except in 'color' property

<fantasai_> emilio: I'll double-check

<fantasai_> emilio: anyway, seems fine

RESOLUTION: 'color: currentColor' on a highlight takes the next *active* highlight color, so that text is drawn as if highlight weren't taking effect

delan: For Q2, when you call getComputedStyle() with a highlight pseudo, the color of the result should behave as if the pseudo you passed in is highlighted, but all other highlight pseudos are not highlighting

delan: we pretend

<florian> +1

RESOLUTION: getComptuedStyle() with a highlight pseudo takes color as if that highlight applied and no other highlight applied

Rossen: we'll take Q3 back to the issue

Break

<br until="??:12">

<dbaron> Are there any real timezones where the hour in UTC is *:15 in that timezone? There are definitely some for :45 (Nepal; Eucla, WA, Australia).

Paired Cascading of Highlight color/bgcolor

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

delan: for compat reasons, highlights have a "paired cascade", at least for ::selection (but we decided to apply to all)

delan: for background-color and color

delan: if you have some browser default colors for ::selection, e.g. white on blue

delan: if you then go and set one of those two properties, then both of the defaults get suppressed

<delan> ::selection { background: yellow; }

delan: defaulting to their initial value

delan: e.g. if you set selection's background to yellow, then the default foreground color at used value time is no longer going to be white

delan: This issue was pretty big, I asked 7 questions about it in the issue

delan: pretty much none of the questions have disagreement in the issue

delan: the main open question is, which origins should this apply to?

delan: Original spec text says that when author sets one of these two properties, then we suppress highlight color

delan: but there's also animation and transition origins, and also user orgin

delan: will talk about aimation and transition first

delan: I think it doesn't matter whether animation or transition is included in this rule or not

delan: we used to think it mattered for consistency with 'appearance', but I realized it doesn't matter because the animation and transition properties are not applicable for highlights

delan: so as far as I'm aware, can't use them in highlights

emilio: I think ?? you should be able to

emilio: don't know if propertly supported, though

dholbert: can a property that is inherited be animated or transitioned?

delan: Wondering if it is allowed by the spec right now

delan: if not allowed, then doesn't matter whether those origins included in this rule

delan: at least until they become allowed

florian: I believe delan is right, not part of the list of allowed properties

delan: no way for some way for them to sneak in, despite not being applicable properties?

florian: I don't think we designed one

emilio: if animate color of parent, and it inherits through?

fantasai_: That wouldn't be in the animation or transition origin on the highlight itself

delan: if not possible to come into highlight overlay, and it doesn't matter

florian: I think we should talk some other day whether they should, but until they do...

delan: For the user origin, I did some playing around with user style sheets

delan: afaict, the question here about user origin and paired cascade comes down to

delan: if the user sets one of the two properties (bg color or color) in their user style sheet

delan: do we want that to suppress the UA default for the other property or do we want it to not suppress it and leave the other property as UA-default

florian: Can implementations guide us? This rule was just for compat

emilio: I don't think there's any compat requirements on user origin

emilio: User origins don't disable appearance, so let's follow that precedent

fantasai_: My reading is that we really don't care, so we should do whatever is easiest

delan: works out

delan: even if you go with compat angle, it doesn't suppress default UA colors in Firefox

Rossen: other opinions?

RESOLUTION: Author origin rules, and not user-origin rules, trigger paired cascade fallback

delan: In the issue, we all agree on the other 7 questions

delan: do we need resolutions?

fantasai_: IIRC they're minor enough that I'd close them under Editor Discretion

Compat risk for ::selection defaulting one color from originating element

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

<delan> https://github.com/w3c/csswg-drafts/issues/2474

delan: The highlight inheritance and cascade in the spec is a pretty big change compared to processing model in implementations right now

delan: previously our position was that we consider the compat risk of this big change to be acceptable

delan: because the old model that exists in old browsers is kindof useless and broken

delan: the styles don't inherit so you have the set them everywhere, unless writing a really awkward selector

delan: while implementing in Blink, we found a WPT that broke as a result of turning on highlight inheritance

delan: unclear if aware of that breakage, are we still happy with the compat risk?

<delan> span { background-color: red; color: fuchsia; }

delan: what the test did is essentially it has the originating element with colors of fuchsia on red

<delan> span::selection { background-color: green; }

delan: there's a selection rule that just sets a gree background color

delan: paired cascade from earlier means that because one of the two highlight properties

delan: there is no UA default for 'color', so we use whatever color we get normally

delan: existing model in browsers has ::selection inherit styles from originating element

delan: so test expects color to be fuchsia

delan: but now the test fails

delan: because under new rules, we don't inherit color, it's black

fantasai: I think the test is correct, actually, and paired cascading is also correct

fantasai: inheriting all the way up, should get currentColor, not black

fantasai: though I'm not sure the spec is clear about that

emilio: Goes back to currentColor discussion

emilio: all implementations resolve 'color: currentColor' to an actual color

emilio: so I think we need to solve the problem of 'initial' and 'currentColor' being different

emilio: and we need a resolved color

emilio: I think the computed value is wrong, and it uses a computed color

emilio: nobody implements that, it has terrible perf implications

florian: Delan, can you point out to which bit of the spec made you think that you would go to black rather than originating element?

florian: wondering if it's ambiguous or wrong

delan: ... value found by inheritance ... do we say what happens when we get to the top?

delan: I don't think it says what to do if you get all the way to the root

delan: was it wrong to assume it would work the same way as in the the normal tree?

emilio: I think the spec is right

emilio: but if everything worked by spec, color is initial which is currentColor and it would work

emilio: but that's not how it works right now

delan: so we'd change spec so that for highlights, we get to root, and have a value we get essentially what currentColor does now

emilio: per spec should get currentColor as computed value

emilio: so I think the spec for the color property is wrong

delan: if we did that for all properties ...

emilio: I think the only issue is with the color property

emilio: all current impls store as computed color

emilio: otherwise need to go figure it out every time resolving a color for a given style

emilio: I think the spec doesn't reflect that

emilio: didn't make a difference until now, that we want currentColor to behave specially

Rossen: so do we need to move this discussion back to GH?

delan: I suppose these questions are useful and interesting, but I'm not sure they necessarily change the original question, which was do we still want to move to new cascading and inheritance model

emilio: I think we want the testcase to continue to pass

emilio: Depending on how we resolve the issue

delan: so can take to GH

emilio: this seems complex enough discussion

emilio: per spec everything works magically and it's great

emilio: but I don't think that's reasonable

emilio: so we should figure out the solution that works as we want

delan: ok sounds good

Publications

Fonts publication

Conditionals publication

https://lists.w3.org/Archives/Member/w3c-css-wg/2021OctDec/0116.html

fantasai: I wanna publish another level 3 CR. A couple of minor fixes we'd agreed to.

fantasai: Very close to REC, just a few bugs in impls, and one interop issue to review.

fantasai: So first ask for repub as CR

Rossen_: objections?

RESOLUTION: Publish Conditionals 3 as CR

fantasai: Next is Conditionals 4, published as fpwd in march 2020

fantasai: Only contains new selector() function, been shipping in browsers for a while.

fantasai: We resolved to add a bunch of features to conditional, but since this feature is CR-ready, I propose we defer the rest and take this to CR.

TabAtkins: If this is CR-ready, why not fold into 3?

fantasai: 3 is Rec-ready, it'll pull us back

chris: Agree, this sounds like a good plan

Rossen_: opinions or objections?

RESOLUTION: Publish a CR of Conditional 4, adding just the selector() function

fantasai: For level 5 we proposed font-format(), font-tech(), @when, @else

fantasai: Propose we publish as fpwd

chris: So this seems easy since it's basically copying the current 4 ED and changing it to 5

Rossen_: objections?

RESOLUTION: Publish fpwd of Conditional 5 with remaining features.

chris: Fonts 4 and 5 have new bits, like tech()

chris: I wanted to make sure Conditional 5 and Fonts get published together, since the font stuff links between each other

Rossen_: Opinions?

RESOLUTION: Publish new versions of Fonts 4 and 5.

Media Queries Publication

florian: Neither MQ 4 nor 5 are free of issues, but the EDs are ahead of the TR copies, and I don't think there's issues with what's in there right now. More to do, but nothing problematic.

florian: level 4 will be CRD, level 5 will be WD

Rossen_: objections?

RESOLUTION: Repub MQ4 and MQ5

+1 to republishing

Add lighter composite operation

github: https://github.com/w3c/fxtf-drafts/issues/445

vmpstr: We'd like to add a plus-lighter to mix-blend-mode, and smfr says WebKit already supports plus-lighter and plus-darker

vmpstr: They're comp operations, not blend, so they'd work in the same way that canvas works, where if you set a blend mode the comp op is src-over; if you set a comp op the blend mode is normal

smfr: Issue says lighter, bu tyou're asking for plus-lighter?

vmpstr: I think the diff is just whether the color is clamped to 1

vmpstr: Okay for our use-case either way

smfr: Preferable to me, because our graphics framework doesn't support lighter. plus-lighter is fine

vmpstr: That's fine for us, yes.

chris: Good to see the alignment between CSS and Canvas as well.

chris: This'll be in Compositing 2? Have we had FPWD?

Rossen_: Don't think so

chris: Okay to request that?

Rossen_: Resolve on this issue first.

Rossen_: Objectiosn to adding plus-lighter and plus-darker?

RESOLUTION: Add plus-lighter and plus-darker to mix-blend-mode in Compositing 2.

fantasai: Might want to give a chance to review, so fpwd next year.

Rossen_: Yeah, let's call for it next y ear.

logical-viewport units and wm propagation

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

fantasai: issue was raised to simplify some edges cases around writing modes and viewport units

fantasai: Also brought up the question - I think we got the issue wrong, as it says to resolve against the root element's writing mode, but I think generally you want the element's writing mode.

fantasai: So proposed resolution is to use the element's writing mode to resolve vi/vb, rather than the root element.

<fantasai_> s/edge cases around/edge cases around body propagation and/

TabAtkins: I agree

smfr: Does tha tmake inheritance complicated?

fantasai_: No, they compute to lengths before inheritance

florian: Yeah, I think I remember that being what I wanted. If you're doing a font-size in viewport units, you want the logical axis you're using.

miriam: Might be confusing with container queries which have to be set up to be inline or block

miriam: So you set up a container with "inline", this might not match the container you've established.

emilio: What do we resolve our units against, the container or the element?

fantasai_: So this is about the container-relative units.

emilio: We added a way to resolve against different containers. It would be very bad if we resolved relative units against different axises for each property.

emilio: So think we should resolve them against the element's wm.

miriam: So when you use the "cq inline unit" it looks for the nearest container with inline containment.

miriam: Could potentially be confusing if the inline unit doesn't resolve against a container declaring "inline"

TabAtkins: I agree that the potential of inline not matching inline is a general problem with mismatched writing modes, and agree that within an element you want inline to match what that element thinks its inline axis is

fantasai_: So proposed resolution is that viewport units (and analogues) use the writing mode of the element they're used on.

Rossen_: objections?

RESOLUTION: Writing-mode sensitive viewport units (and analogous units) use the writing mode of the element they're used on.

end

fantasai_: Just realized we should probably add Color Adjust to the rough interop section of the snapshot.

Rossen_: We'll take it over email.

<tantek> CSS break? is that break-before? ;)

I think it's break-after

'break-after: 2021'

Meeting closed.