Meeting minutes
<astearns> Rossen_: I just moved the Wed and Overflow columns so that my browser window does not have to be so wide
<khush> Are we using the zoom link for this?
<oriol> Do I have the wrong meeting link? I only see Khushal and myself
<khush> I've tried zoom and webex both....
github-bot, take up w3c/
[css-cascade-6] Strong vs weak scoping proximity
<github-bot> OK, I'll post this discussion to https://
miriam: With @scope, there are two features that help avoid large scoped things overriding smaller scoped things
… ONe of those is pretty strong, which is the ability to set lower boundaries
… The other is somewhat weaker, which is a heuristic priority for inner over outer
… We’re calling that cascade proximity; question is whether that’s more or less powerful that the specificity heuristic
… Proposal is to have it be weaker than, because we’re trying to reduce specificity reliance
… When these two heuristics conflict, specificity is easier to change
astearns: I suggested people provide arguments in favor of stronger, but all the comments in the issue argue for weaker
astearns: Comments?
<bramus> SGTM
RESOLUTION: cascade proximity is weaker than specificity
github-bot, take up w3c/
[css-cascade-6] Do we want to defer some or all of these scope extensions to level 7?
<github-bot> OK, I'll post this discussion to https://
miriam: Some tagalong features we can consider; all are useful, question is whther we shoudl be trying to cover them now or defer to next spec level
… If we don’t defer them, next on the agenda is a scope sibling feature
… This would be horizontal in the DOM
… A pretty straightforward thing to spec, we think, but it hasn’t been specced
… The other is the scoped proximity combinators
… We have a little less sense when people would use this rather than @scope
… For @scope you’re trying to target several elements in the DOM, and the at-rule does that neatly
… In a single selector, it gets more complex
<TabAtkins> +1 to deferring, they're all nice but none are necessary
miriam: The real question is: defer, or no?
astearns: One concern with deferring is there may be feedback with current-level features that could modify
… If we’re not considering these now, we may miss something
miriam: It’s hard to know if that’s too cautious
… So far neither has caused major changes and will continue to be in our heads, but I dunno
TabAtkins: My estimate is they shouldn’t cause any problems, and should be forward-compatible
astearns: Would it make sense to have a note about things we’ve explicitly deferred?
miriam: Since one is partially-specced, it could be opening another spec
bramus: I’m okay with deferring combinators due to complexity, but was wondering if we can have sibling scope in level 6
<emilio> Implementation-wise they seem a bit trickier than descendant scopes fwiw
astearns: What use case are you concerned about with sibling proximity?
<emilio> Because to change the descendant relationship you need to remove from the DOM but that's not true for siblings
bramus: So authors can style things like start and end dates on a calendar and also styles things between them
miriam: Another example is to style everything between one header and the next header
fantasai: Seems like those are use cases where you don’t need scope proximity effect, you just want the flooring effect, yes?
miriam: I think I’ve seen examples using both
… They achieve the same goal, but at different levels of explicitness and power
astearns: Can we resolve on deferring the combinator?
… Proposing deferring 8380 with a note that it was deffered to next level
RESOLUTION: The combinator is deferred
github-bot, take up w3c/
[css-cascade-6] Handle sibling-proximity in @scope
<github-bot> OK, I'll post this discussion to https://
bramus: In regular scope, we can walk down the DOM tree
… Suggestion here is to introduce sibling proximity where the lower boundary is a sibling of the upper boundary element
… Syntax would be the same as @scope rule; difference would be the at-rule would be @sibling-scope
fantasai: With normal scoping, relationships are obvious, but here we’re only doing following siblings, so should make that a little more obvious
… Because we’re only going forwards in the tree
<masonf> FYI, I'm here and I understand the group wanted to talk about 8189 but I wasn't here earlier. Here now!
bramus: It’s implied by the name, I think
… The end boundary element should be a following sibling of the start boundary element
… It could be you style all the siblings from a certain element down
<lea> +1 to @scope-sibling over @sibling-scope for the reason fantasai mentioned
fantasai: I would go with @scope-siblings rather than @sibling-scope so they sort together
<lea> also typing @scope would bring both up in autocomplete
<fantasai> bramus: Would it be @scope-sibling or @scope sibling?
lea: I agree with Elika on the naming; they sort together, they autocomplete together
astearns: Should we resolve on that?
bramus: I’m fine with that
astearns: We do tend to go with non-plural syntax for things, so @scope-sibling
fantasai: The non-plural form reads weirdly
astearns: Yeah, okay
miriam: You are creating a scope of siblings
florian: We do have precedent for a few plurals
RESOLUTION: The name will be @scope-siblings
astearns: Anything else?
miriam: I think we’re hoping things will carry over from the other one
bramus: There’s another CSS cascade issue at the bottom of the list
astearns: People have joined specifically for the animation issue, so I want to do that next
github-bot, take up w3c/
[css-animations-2, css-transitions-2] Entry and exit animations for top-layer elements
<github-bot> OK, I'll post this discussion to https://
plinss: There was TAG discussion about popover, which turned into discussion about the top layer in general
… TAG is concerned about the overall design of the top layer
… It’s done by monkey-patching CSS
… It should be defined by the CSS WG, but hasn’t been getting a lot of love
… There’s room for declaratively creating not just the top layer, but multiple layers
… I think it should be controleld entirely in the CSS layer
… Don’t have a specific design, but the TAG feels it needs to be done
TabAtkins: I’ve had this on my to-do list
… To pull out painting order and do a spec about that
… We have a resolution on file to put that into the position spec
… Proper specification in CSS is on my task like
… In terms of authors being able to create layers other than the top layer, completely agree
… This has come up with anchor positioning
… I definitely support authors being able to define additional layers you can move things into
… In terms of making the top layer accessible, that’s been discussed and there are significant concerns
… Anything the UA is using the top layer for shouldn’t be able to be covered up
… That’s a larger, separate conversation
… Doesn’t have to prevent letting authors insert layers between document and “top layer”
plinss: I understand the security concerns
… We have precedence for letting the UA override author styles and should use similar mechanisms for the top layer
… While we should allow authors to create layers, the top layer should just be another layer, not something special and magic
… The magic can come from the UA stylesheet
astearns: Please add a link to the proposal you referenced
chrishtr: We’re going to do the work to move the top layer stuff into the position spec
<dbaron> I think we might also have a somewhat older resolution for me to create a spec for the CSS painting model... :-/
chrishtr: Can we go back to the thing in 8189, which is adding transition control for developers entering and exiting top layer?
masonf: In general, I’m in support of moving into positioning spec
<lea> how can we discuss entry/exit animations separarately to whether there will be author control of top-layeredness? These are intrinsically related
masonf: I would be supportive of letting authors create a new top layer under the existing top layer
… Trying to do it with existing CSS in the existing top layer are difficult
… Like the top layer being an ordered set
… So I’d be against allowing direct control of the existing top layer
plinss: I’m not arguing the change how the top layer now works, I just think it should be explained using CSS
… Such as exposing the ordering via CSS
masonf: If that’s possible, I’m in favor of it
plinss: I think so
… it would also be great to fix all the z-index hackery that’s been done since day one
<TabAtkins> Found the resolution w3c/
<lea> +1 to everything plinss is saying of course
astearns: I’m hearing a lot of agreement and a stated plan to work on this in the position spec
chrishtr: That would be the first step, yeah
… My proposal on 8189 is you can say transition and then a CSS proeprty that refers to the top layer behavior, and then the usual transtion delay
… So you could push transitioning things into the top layer
… My reading of issue commentary is that people are generally positive about the mechanism
… So if we’re good and want to pick a name, I think overlay would be fine
<masonf> +1 to `overlay`. `overlay-behavior` feels odd.
fantasai: I like the idea of using the word overlay, but think overlay-behavior is a bit weird
<bramus> +1 on just `overlay`
fantasai: I’m open to thoughts
<masonf> `overlay-index` ? That feels bad too.
astearns: The analogy to z-index would make me wonder why there aren’t integers allowed in the syntax
fantasai: This should go into position-4, not -3
chrishtr: Agreed
astearns: I’m seeing more people in favor of `overlay` rather than `overlay-index`
… We could put it into position-4 and see what people say
… So we propose to include `overlay` property with values of `auto` and `none`
<dbaron> (maybe some other name thoughts might be overlay-layer or overlay-level)
plinss: I have concerns this could conflict with other things we might do very soon
astearns: Amended proposal to include `overlay` property with values of `auto` and `none` to position-4 with a note about concerns over extensibility
<masonf> +1
RESOLUTION: include `overlay` property with values of `auto` and `none` to position-4 with a note about concerns over extensibility
<TabAtkins> I'd actually totally missed this issue's discussion, but it sounds good to me.
github-bot, take up w3c/
[css-contain] Container queries within display:none are difficult to implement
<github-bot> OK, I'll post this discussion to https://
oriol: Problem is that browsers tend to avoid computing style of elements inside a display: none subtree
… You can still force the computation with JS
… What should happen if one of these elements may have a container which is applying some rules conditionally, which may affect the comptued style you get?
… Gets more complicated if ancestor is a container or not
… In Blink, I think this was easier to implement per spec since it has some caching and first computation is cached
… That way we know if ancestors are containers or not
… Firefox doesn’t have this caching, so when it computes, the information isn’t stored in the element
… emilio didn’t think my patch to pass information around was the best
… Discussion agreed it was reasonable that an element in a display: none subtree should be treated as having no container
… This might not be good for style queries
emilio: Some of this is complexity specific to Firefox, but in general, some of this is very messy and not very interoperable
… I’m not a fan of adding complexity here
… We do something similar where older browsers do transforms on display: none elements as none
… I’d rather do the easy-to-implement thing instead of having extra complexity
… I don’t think it’s particularly useful to check elements based on container queries when the container isn’t there
… Any answer will be weird
astearns: Is there a way of having elements escape a display: none ancestor using CSS?
emilio: No, which is why browsers optimize them away
astearns: Then I have no concerns
… Proposed resolution: elements within a display:none subtree have no parents that container queries can access
emilio: The wording could be they have no query containers, though I’d like Rune to confirm this is fine
… We can resolve and seek comment after
astearns: Anyone on the call want to wait for Rune’s response?
(silence)
RESOLUTION: elements within a display:none subtree have no parents that container queries can access
github-bot, take up w3c/
[css-contain-3] Reference named containers for cq units
<github-bot> OK, I'll post this discussion to https://
miriam: There are two function proposal on this
… There’s concern about using actual lengths in these functions
… Idea is to be able to query for a specific container
… Could query for container 10cqi and a container name
… Idea 1: a new function for each container unit
… Woulc take the argument of a container name
… Idea 2: Have a general container unit reference function
… Something like `container-unit(<unit>,<container-name>)`
… Could use this in calc() to do whatever math is needed
… This is a little bit bulky that would help authors clean this up a bit, but it’s a good start
… I like the second idea; probably needs some bikeshedding on the name
<TabAtkins> happy with either, honestly
astearns: Anyone with opinions or dislikes?
<TabAtkins> latter is verbose but the functionality makes sense
emilio: There are units that don’t make sense in a container function, right?
miriam: Yeah
fantasai: The only relevant units are font-relative and container-relative
emilio: I’m not particularly opposed, but some of these seem like they could be handled differently
… This feels a bit weird
… I have a slight preference for the first option, but not strong
fantasai: I like that the first idea is easier to type and is a straightforward extension of existing syntax
TabAtkins: I agree with emilio that the general function is a little funky
… We could make a cqem unit and corresponding function, so I think I’d be happier with dedicated functions
<emilio> +1
TabAtkins: Plus a non-binding intent to always have a function that goes with any new CQ unit
astearns: I’m a little excited about the more vague function — why just units, why not custom properties?
TabAtkins: That wouldn’t be the container unit function which needs to be a math function
fantasai: I think we should start where we can with this syntax which is easy to use and we'll want anyway, even if we have a more generic function. Also I think it would be nice if we could make it behave more like a unit...
miriam: The custom units proposal would let you wire that up
astearns: Sound like we’re converging on idea one, where every unit gets a corresponding function
RESOLUTION: add a function for every container query unit that allows to reference a named container
<fantasai> cqi(<container-name>)
break
<TabAtkins> right, it resolves to 1 of the corresponding unit
github-bot, take up w3c/
[css-contain] Allow container query style features to evaluate in a boolean?
<github-bot> OK, I'll post this discussion to https://
miriam: Container query style features can query custom properties, so the question is, can you query without the value to see if it has initial value
… Thus getting true or false back
… False if it’s the default value, true if it’s changed
<fantasai> sgtm
<fremy> +1
<lea> +1 obvs
dholbert: Would anything special be needed for Houdini registered properties?
miriam: Yes, you’d be checking to see if it’s the initial value, by default that would be the guaranteed-invalid value
Rossen: Any questions or objections?
(silence)
RESOLUTION: style queries can accept properties in boolean context; false if matches initial value, true otherwise
github-bot, take up w3c/
[css-overflow][css-contain][css-sizing] `overflow: auto` incompatible with size containment and container queries
<github-bot> OK, I'll post this discussion to https://
oriol: We had a resolution but I’m not sure if that was the right solution
… Problem is that with overflow:auto, if the browser is using classical scrollbars, those take up space
… This can happen in two ways
… Browser may behave a bit different, if the element is sized intrinsically, the scrollbar size is added on top of content size
… If the size is explicit, then outer size of the element is preserved and scrollbars go inside
… We resolved the address the problem we don’t want, having to check to see if ancestors have to change size
… We always want to stop at element with size containment
… So we resolved to have scrollbars shrink content size
… Question with this is, first, this addresses the auto case, but what about the overflow:scroll case?
… Second, even if we preserve outer size of the element, there are features that depend on content size, like container queries and contain-intrinsic-size:auto
… By letting auto scrollbars affect content size, we have instability with container queries and contain-intrinsic-size:auto
… Maybe it would be simpler to say that if an element has size containment or c-i-s:auto, then overflow:auto would need to computer to overflow:scroll
… By forcing the element to consistently get scrollbars, we’d avoid problems, might not look as good
… Open to ideas, but finding a solution that covers all problems simultaneously is tricky
florian: I think your suggestion of getting stable scrollbars does help
… I support that
… Maybe we could do indirectoin through scroillbar-gutter properties
oriol: Those properties have the stable keyword, but I think it only affects on axis
florian: Yeah, maybe that won’t work
… Containment is magic enough already; I think we could make it do strange things like this
iank_: I do worry about web compatbility
… People throw overflow:auto on random elements
… Also, the optimization mentioned in the spec is on a best-case scenario
… You aren’t required to use it for whatever reason
florian: Ian, did you mean we should let the outer size with overflow:auto change and that regains consistency at the expense of optimization?
iank_: Want to think about it a little more, but I would be fine with that
… It’s a little bit of a hairy area
miriam: Confused about the loop you mentioned of scrollbars getting added due to content
… That seems like the same loop we had to work through to get container queries at all, how is this new/different?
oriol: You can make contents change size with container queries
iank_: This falls into the you-always-move-forward pool
… We start assuming no scrollbars, then add if needed
oriol: It’s not like browsers are freezing, but if you start forcing things with JS or such, operations that should not affect things visually can change things
… I have some examples in the issue of things looking broken
iank_: To me, those examples are browser bugs
oriol: Then we need to define the expected behavior
miriam: I thought we did
Rossen: Is it the case that when we start with no scrollbars, you can only add scrollbars in the normal case, excluding container queries?
… Is the proposal to make changing the scrollbar state once per layout a defined behavior?
oriol: Yeah, I want to avoid circularities
… Mia was saying we can already avoid them, so maybe I missed something
… Reading the specification, it seems there’s a circularity
… Was proposing a way to keep the content from affecting the content size of the container
<miriam> note and example here discuss this exact example: https://
oriol: If there’s another solution that only take a look at size at one point and not others, that may be fine
iank_: We said you’re performing a layout and engines will try to optimize, but can skip them
… You start with no scrollbars, then add a scrollbar or two if needed, then finish
… So you only add scrollbars during layout
… It’s tricky to get the optimization correct
… This circularity can arise with regular content, so this isn’t particularly new
Rossen: Is there a clarification or solution we need to record here, or is there an added step that seems reasonable?
miriam: Not sure; I think this is covered and I see this exact case mentioned in the spec, so I need to know what’s unclear and in need of clarification
oriol: Even if we use this approach on whether query styles apply or not, there’s a problem with contain-intrinsic-size:auto which remembers the content size
… We have some inconsistency here, and I think the other cases are addressed in other ways, but I don’t see this c-i-s problem addressed
miriam: It’s likely we do need to clarify here
Rossen: Let’s take the conversation back to the issue and work out a solution there
github-bot, take up w3c/
[css-color-4] Allow out-of-gamut HSL/HWB colors (previously "Move gamut mapping to a future spec")
<github-bot> OK, I'll post this discussion to https://
chris: In the course of discussion about whether we shoudl do gamut mapping, it turns out to be observable through script in one case
… That’s when you convert to HSL or HWB
… That’s not very helpful; worry is out-of-gamut colors could return unusual results when converting
… Proposal is that colors should be round-tripped
… You’ll get weird HSL values but it’s okay because that’s what you asked for
… HSL and HWB are lossy
… I’m in favor of the proposal, but been waiting for implementor input
Rossen: Any implementors here who want to provide input?
emilio: I need to look more carefully
Rossen: Are you opposed?
emilio: Not particularly
Rossen: This doesn’t sound like it’s raising an initial strong reaction
emilio: I’d be fine resolving and I can come back if there’s a problem
chris: proposal is to allow out-of-gamut HSL and HWB colors
Rossen: objections?
(silence)
RESOLUTION: allow out-of-gamut HSL and HWB colors
github-bot, take up w3c/
[css-color-4] What if legacy colors *also* interpolated in Oklab by default?
<github-bot> OK, I'll post this discussion to https://
chris: For non-legacy colors, implementation should interpolate in oklab
… The spec says implementations MAY interpolate in sRGB if all the colors are legacy colors
… Lea raised, why not make them all do it in oklab?
… We did some tests, and for some colors there’s a big difference
lea: I think it’s an obvious improvement in every color pair we tried
… There is precedent for doing this in places like text-decoration-skip
… It makes for an easier rule to learn and remeber
… oklab produces better gradients
… The only problem I could think of is color pickers
… I can’t remember the proposed solution to this
… The Chrome team has said they’re kind of apprehensive because they tried to do linear RGB and there were problems
… This isn’t the same because linear RGB isn’t perceptually uniform
chris: In Chrome, the colors are stored in premultiplied linear RGB
… I wanted to know whether they said they can’t change because of that trial, or because of the proposal
lea: I heard from someone on Chrome team they trioed linear RGB and had poor results
chris: As expected
bramus: I don’t think anyone here can address this directly, but I’ll poke the correct people for a response
<fremy> I would note that there might be images associated to the gradients
Rossen: In absence of that, is there a resolution you want to take here that will ideally be something that would work?
lea: Are there any objections to this, involving actual cases where this would be worse?
emilio: Does this only affect gradients, or does it also affect animation?
lea: That’s up to us; I believe it’s currently about gradients only
emilio: Applying to animations would be trickier because it affects computed styles
<TabAtkins> yeah i'd be relatively bothered by interpolation and gradients not working the same
chris: The spec is about interoplation, so it would apply to everything
emilio: That’s a bit trickier, but it might work
… I’d be surprised if there are no pages that rely on this, but it might be a better default
chris: Although it’s true a gradient defined as a gradient is better, I’m concerned we’ll get “why is my page lighter?”
emilio: It’s good to change the default consistently
… I agree it’s a better default, but compat is a concern
<ydaniv> what about filters?
emilio: Gradients would be better regardless, I think
<lea> ydaniv: filters are defined entirely differently, they don't use interpolation
emilio: Changing the default for everything is probably worth a try
lea: I want to clarify that making this the default doesn’t make it mandatory
… There’s a way to specify the interpolation space for gradients, and will be able to apply to other things
… So there’s an escape hatch
chris: This comes down to, is this an opt-in or an opt-out?
… For unmaintained pages, what happens?
Rossen: opt-in would be safer, yes?
chris: I agree
plinss: The issue of a page becoming lighter isn’t a big deal except in cases where CSS color needs to match image color
… Want to be sure we’re taking that into consideration
bramus: I vote for opt-in; authors will be surprised if colors change
Rossen: +1 from me
… colors can often be a branding issue
<fantasai> +1 from me to plinss's point, that it's important for the endpoints and not so much for the middle
<Zakim> lea, you wanted to point out the other huge precedent for changing color display
lea: This reminded me, we have a more relevant precedent where we changed to interpret legacy CSS colors in sRGB, so what what red meant changed (for example)
… That’s a much bigger change than what we’re discussing here
… only midpoints in a transition will change
<TabAtkins> color management only affected people with good screens, tho
fantasai: I support Lea’s proposal; I think midpoint changes will be an improvement
<florian> +1
<miriam> +1
fantasai: There’s a lot of shift in colors depending on monitor calibration etc.
Rossen: So do we make this opt-in, something we can drop later, or make it opt-out?
lea: Opt-in bascially means no change
fantasai: I think we should change the default for the web to be the better interpolation
lea: Current language is that browsers MAY do this; proposal is to change this to MUST ...or at least SHOULD?
Rossen: Or maybe SHOULD
lea: Also resolutions are not binding, we can always reverse if investigations reveal it’s a bad idea
florian: I’m not sure what we gain with a SHOULD
… If we have a good reason not to do something, we should roll this back
… I think MUST is appropriate
lea: Maybe SHOULD is better for low-powered devices where oklab computation is harder than calculating the RGB values on hand
plinss: I would argue devices like that probably won’t support this sort of thing
<astearns> +1 to MUST
<fantasai> +1 to requiring OKLab interpolation
Rossen: Objections to using MUST on using oklab?
(silence)
RESOLUTION: change specification say browsers MUST use OKLab color interpolation for all colors, including legacy colors
end of meeting
<lea> thanks for scribing emeyer!!
🫡