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