15:00:14 <RRSAgent> RRSAgent has joined #css
15:00:18 <RRSAgent> logging to https://www.w3.org/2025/09/17-css-irc
15:00:18 <Zakim> RRSAgent, make logs Public
15:00:19 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:02:12 <miriam> present+
15:02:17 <dholbert> present+
15:02:41 <romain> romain has joined #css
15:02:47 <flackr> flackr has joined #css
15:02:50 <flackr> present+
15:04:03 <romain> present+
15:04:17 <ydaniv> ydaniv has joined #css
15:04:20 <dbaron> Present+
15:04:22 <florian> present+
15:07:43 <ydaniv> present+
15:07:44 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12811
15:07:45 <github-bot> Topic: [css-overflow-4] nowrap and block-ellipsis
15:07:45 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12811.
15:08:20 <ydaniv> florian: there seems to be some ambiguity about text spec
15:08:41 <ydaniv> ... when you remove content next to elipsiss it should disappear
15:09:06 <ydaniv> ... up to the next soft wrap oppertunity
15:09:28 <ydaniv> ... but the way the white space is currently specified, nowrap and pre do not supress it
15:09:42 <kizu> kizu has joined #css
15:09:45 <kizu> present+
15:09:56 <andreubotella> present+
15:10:02 <ydaniv> ... so reading it says that even if it says nowrap they do not suppress the wrapping oppertunity, just not to take them for line break processing
15:10:14 <ydaniv> ... so literal reading would have it do something else
15:10:58 <ydaniv> ... proposal is to not do that, and leave to the editor to find exact spec wording, and confirm that when you can't wrap you remove the whole thing to insert the elipsiss
15:11:43 <ydaniv> andreubotella: if you have a forced line break inside pre or nowrap then it forces to <missed>
15:12:14 <florian> andreubotella: and there is enough room at the end of the line to fit the ellipsis, that is allowed
15:12:45 <ydaniv> ... only when it doesn't fit and you try to find next oppertunity it tries to find it
15:12:49 <florian> andreubotella: it's only when the ellipsis doesn't fit and you're looking for a previous placement point that nowrap would require removing the whole content
15:13:15 <ydaniv> astearns: so editorially if not specified, could spec editor specify that?
15:13:42 <ydaniv> ... is there some reason why nowrap is specified that way?
15:13:50 <ydaniv> florian: my suspision is editorial accident
15:14:30 <ydaniv> astearns: proposed resolution is to clarify the interaction between nowrap and block elipssis
15:14:41 <astearns> ack fantasai
15:14:45 <ydaniv> fantasai: I would prefer to define this on the line clamp side
15:15:04 <ydaniv> ...  that opportunities don't exist unless we need to know where they are for other reason
15:15:17 <ydaniv> ... say it ignores them with in nowrap
15:15:31 <ydaniv> astearns: that's the safeset, wondering if it's enough
15:15:46 <ydaniv> fantasai: question whether the information is there and can be accessed
15:16:06 <ydaniv> florian: I think editors can take that, since me and fantasai are editors we could
15:16:11 <ydaniv> astearns: objections?
15:16:17 <ydaniv> ... none
15:16:35 <ydaniv> RESOLVED: clarify the interaction between nowrap and block elipssis
15:17:47 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12008
15:17:47 <github-bot> Topic: [css-overflow] [css-text] Interaction between whitespace collapsing and line-clamp
15:17:47 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12008.
15:18:16 <fantasai> i/florian: there seems to be/scribenick: ydaniv
15:18:18 <fantasai> scribe+
15:18:29 <fantasai> andreubotella: Block finds the last soft wrap opportunity and removes content from that point to end of line
15:18:35 <fantasai> andreubotella: What does that mean in terms of whitespace?
15:18:52 <fantasai> andreubotella: wrt unicode line breaking algo, line breaking opportunity is after the space, not before
15:18:55 <fantasai> andreubotella: This is probably not what we want
15:19:28 <fantasai> andreubotella: Way I conceptualize this is, rather than finding last opportunity that fits, remove the width of ellipsis from the available width of the line, do regular line breaking based on that, and then add the ellipsis
15:19:52 <fantasai> andreubotella: in that model, if the ellipsis is placed after white space processing part II, which removes collapsible spaces, it will be placed at the end of the word
15:20:11 <florian> q+
15:20:13 <fantasai> andreubotella: I don't necessarily want to require that the line-breaking algo has to take into account the ellispsis, that's an implementation strategy
15:20:44 <fantasai> andreubotella: proposed resolution, if you have clamp point at white space, make it work as if line break happened there, and ellipsis was placed after WS Processing Part 2
15:20:50 <astearns> ack florian
15:20:50 <fantasai> andreubotella: which removes the space
15:20:55 <fantasai> florian: I agree with the proposal
15:21:13 <fantasai> florian: Don't want to require a particular implementation strategy, but describing this way is helpful and easy because we invoke existing spec text
15:21:28 <fantasai> florian: that's a very complicated logic depending on which spaces and white space properties are at the end of the line
15:21:36 <fantasai> florian: so saying we do "as if" at the end of the line is a good idea
15:21:45 <fantasai> andreubotella: Another complication related to hanging white space
15:22:08 <fantasai> andreubotella: You can have space at the end of the line that isn't collapsible, but can hang off the end of the line (width isn't accounted for in line breaking or alignment)
15:22:23 <fantasai> andreubotella: Only space at the end of the line can hang. If you put ellipsis there, can't hang anymore.
15:22:35 <fantasai> andreubotella: We could make the ellipsis hang... so not impossible
15:22:42 <fantasai> andreubotella: but idk if we want to require that or what
15:23:00 <fantasai> astearns: Let's say that's a separate issue for now, and take a resolution on what we do with collapsible white space
15:23:43 <fantasai> andreubotella: "Rendering should be equivalent to line breaking at that soft wrap opportunity, and applying white space processing part 2 before inserting ellipsis at the end"
15:23:47 <fantasai> astearns: Makes sense
15:24:23 <fantasai> PROPOSED: Rendering should be equivalent to line breaking at that soft wrap opportunity, and applying white space processing part 2 before inserting ellipsis at the end
15:24:34 <fantasai> RESOLVED: Rendering should be equivalent to line breaking at that soft wrap opportunity, and applying white space processing part 2 before inserting ellipsis at the end
15:25:11 <fantasai> fantasai: fwiw, if we put ellipsis after the spaces, then nothing should hang anymore
15:25:21 <fantasai> florian: yeah, question is whether that's where the ellipsis should go
15:25:54 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/9235
15:25:54 <github-bot> Topic: [css-overflow-4] [css-break] How does `widows` and similar properties affecting fragmentation interact with `continue: discard`?
15:25:54 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9235.
15:25:56 <fantasai> s/Topic/Subtopic/
15:25:57 <fantasai> s/Topic/Subtopic/
15:25:58 <fantasai> s/Topic/Subtopic/
15:26:44 <fantasai> andreubotella: Here's an implementation of continue:collapse. You can see when the height is reduced to zero, the lines get hidden one by one.
15:26:53 <fantasai> andreubotella: continue:discard is the previous version of this, which was handled with fragmentation
15:27:01 <fantasai> andreubotella: You don't see the same thing, you see that first two lines are hidden together
15:27:12 <fantasai> andreubotella: If you only leave space for first line, both discarded.
15:27:20 <fantasai> andreubotella: Reason for this is 2 properties called widows/orphans
15:27:43 <fantasai> andreubotella: Names are typographical terms, somewhat confusing, maybe we need to rename? But that's off-topic
15:27:57 <fantasai> andreubotella: They control how many lines can be by themselves at the start or end of a fragment
15:28:10 <fantasai> andreubotella: The default value is 2, meaning a single fragment isn't allowed
15:29:11 <astearns> fantasai: do you have an incorrect assumption?
15:29:23 <astearns> fantasai: widows shouldn’t affect the first fragment
15:30:05 <fantasai> fantasai: There's no breaking opportunity between the start of the container and its first line box
15:30:17 <fantasai> fantasai: You will always place at least some content
15:30:22 <astearns> ack fantasai
15:30:39 <fantasai> florian: If you have a 2-line paragraph, and a many line paragraph ... in fragmentation it is what you want, but in this case maybe not
15:30:57 <fantasai> florian: My suggestion is that line-clamp also sets widows/orphans to 1.
15:31:14 <fantasai> florian: Otherwise if there's room for 3 lines, and you only get 2, it will be surprising
15:31:35 <astearns> ack dbaron
15:31:44 <fantasai> andreubotella: My suggestion was to make line-clamp ignore widows/orphans
15:31:50 <fantasai> dbaron: Principle is that you always place something.
15:32:13 <fantasai> dbaron: One reason it exists is not getting into an infinite loop when all fragmentainers are identical.
15:32:17 <fantasai> dbaron: In this case, you have to place something.
15:32:29 <fantasai> dbaron: In context where fragmentainers are not all identical, you may or may not want that principle.
15:32:35 <fantasai> dbaron: But I think we're coming to another solution here...
15:33:09 <fantasai> florian: Andreu's and mine would do the same thing by default, but mine allows authors to set things so that they do take effect, whereas in Andreu's there's no option
15:33:28 <fantasai> astearns: Chair hat off, I'm a little more comfortable with just defining interaction between the properties, rather than having one property set another...
15:33:37 <fantasai> florian: I'm split here. Andreu's version is less magic
15:33:56 <fantasai> florian: If you're doing a very small height in which you're line-clamping, but if people are doing it on a bigger chunk of content, room for 10 lines
15:34:06 <fantasai> florian: maybe in that case would want to have widows and orphans take effect
15:34:18 <fantasai> florian: Completely suppressing most of the time might not be the right call
15:34:40 <astearns> fantasai: suppose you have clamp that’s large and you are fragmenting?
15:34:51 <astearns> fantasai: there you’d want widows to take effect
15:35:11 <fantasai> andreubotella: Question of whether line-clamp container should fragment. It's very buggy and non-interop in browsers.
15:35:40 <fantasai> andreubotella: If we allow these containers to fragment, then probably continue:discard, rather than block effects of this property, it should say that they don't apply for setting the region break
15:36:18 <fantasai> florian: Ok, my earlier pref for setting to 1 rather than ignoring, is not an objection. I'm now on the fence, see arguments both ways.
15:36:51 <fantasai> florian: Long-term, if we really need an opt-in, we can create one.
15:37:13 <fantasai> astearns: Let's go with andreubotella's suggestion for now. It's the least we can do to fix this particular issue.
15:37:28 <fantasai> astearns: We can make that interaction more complicated in the future if we need to
15:37:39 <fantasai> PROPOSED: The region break set by line-clamp ignores widows/orphans
15:37:59 <fantasai> RESOLVED: The region break set by line-clamp ignores widows/orphans
15:38:33 <github-bot> Subtopic: [css-overflow] How do empty blocks affect line-clamping by height?
15:38:56 <fantasai> andreubotella: Split off from a previous discussion on abspos and stuff.
15:39:20 <fantasai> andreubotella: When clamping by height, the last possible clamp point that doesn't overflow is chosen.
15:39:33 <fantasai> andreubotella: If you have a block element that has no content, it would clamp after it.
15:39:46 <fantasai> andreubotella: That's probably fine, except it means that if there's a line before that empty block, it will not be ellipsized.
15:40:17 <fantasai> andreubotella: The presence or absence of that block before/after clamp point, if that block is empty it doesn't matter. But if the block has position:relative, and contains an abspos, it does matter because it affects whether abspos is hidden or shown
15:40:30 <fantasai> andreubotella: this can also affect boxes that have non-zero content, but height set to zero
15:40:41 <fantasai> andreubotella: In those cases, the content of the box would also be shown or not shown depending.
15:41:09 <fantasai> andreubotella: I think it makes sense to clamp after zero-height boxes. Find the last possible clamp point before the height overflows
15:41:21 <fantasai> florian: Main downside is because last thing before clamp point isn't the line, we don't see the ellipsis
15:41:43 <astearns> ack fantasai
15:41:44 <fantasai> florian: Although in case of zero height *and* content, ellipsis would be seen on that content.
15:41:52 <fantasai> florian: but I guess it's ok, don't put empty <div>s where you don't need them.
15:42:11 <astearns> q+
15:42:23 <fantasai> andreubotella: If you have a box which is zero-height, but does have content (whether overflowing or abspos), you probably don't want the ellipsis to be placed on the previous line
15:42:23 <astearns> q-
15:42:28 <fantasai> andreubotella: should we depend on that?
15:42:52 <astearns> fantasai: if you have a para and then a block that’s a horiz rule
15:43:06 <astearns> fantasai: do you want that para to be ellipsised?
15:43:12 <fantasai> andreubotella: Currently it's not
15:43:34 <fantasai> andreubotella: block-ellipsis applies to the last line before clamp point if only thing in between are abspos or end of element
15:43:50 <astearns> fantasai: is that the behavior you want?
15:44:05 <fantasai> florian: We discussed earlier, and resolved on this behavior given no perfect solution.
15:44:22 <fantasai> andreubotella: For some use cases you might want it, and for others you might not.
15:44:35 <fantasai> andreubotella: [missed example]
15:44:56 <fantasai> astearns: So proposed resolution is no special handling for zero-height or empty blocks?
15:45:06 <andreubotella> s/[missed example]/if you have a line, and then an independent formatting context, you don't want the line before it to have the ellipsis/
15:45:39 <astearns> fantasai: could we just say the kinds of blocks that inhibit margin collapsing…
15:45:59 <fantasai> florian: Are you saying we should lean more on margin-collapsing-through??
15:46:23 <fantasai> astearns: Could close no change and then explore later
15:46:38 <fantasai> florian: It's not interaction with margin-collapsing, it's trying to identify which blocks we consider and those we don't
15:47:11 <fantasai> fantasai: No special handling, if people complain we'll reconsider
15:47:20 <fantasai> PROPOSED: Close no change until/unless users complain.
15:47:26 <fantasai> RESOLVED: Close no change until/unless users complain.
15:47:37 <github-bot> Subtopic: [css-overflow] Floats and line-clamp
15:48:16 <fantasai> andreubotella: For continue:collapse, defiinition says if block container contains a clamp point, automatic size will not take into account the content after the clamp point
15:48:38 <fantasai> andreubotella: What does that mean for the line clamp container? It is an independent formatting context, so it is subject to float clearance
15:48:55 <fantasai> andreubotella: If you have a float that is not hidden, it will add clearance to the line clamp container
15:49:03 <fantasai> andreubotella: This is not always what authors expect
15:49:50 <fantasai> andreubotella: In this case, changing webkit-line-clamp to lines 3 or 4, it means float would make the box taller than you would expect by the lines
15:50:20 <fantasai> andreubotella: but if you're clamping by height, the moment you reach the end of the float and you try to push the height upwards, then you would be clamping up to the line before the float
15:50:29 <fantasai> andreubotella: the float is anchored to line 3
15:50:37 <fantasai> andreubotella: I like the consistency with regular sizing, but this is not intuitive
15:50:37 <florian> q+
15:50:49 <fantasai> andreubotella: It is also different from behavior you would get with continue:discard, because the float would fragment
15:50:52 <astearns> ack florian
15:51:07 <fantasai> florian: Behavior is surprising, but consistend and explainable
15:51:27 <fantasai> florian: If we try to do better, might be able to say that a float that grows the box by adding clearance is treated as invisible, and you remove the float
15:51:57 <fantasai> florian: Don't remove floats in general, because they can cause content to wrap differently
15:52:10 <fantasai> florian: but if it's increasing height of container, then remove it
15:52:17 <fantasai> florian: but then that would change the wrapping of earlier lines..
15:52:22 <fantasai> florian: so maybe put a dummy float?
15:52:31 <fantasai> florian: Anyway, current behavior is not terrible.
15:52:44 <fantasai> andreubotella: I'm worried about implementability even if it doesn't cause lines to wrap differently
15:52:52 <florian> q+
15:53:03 <astearns> ack dbaron
15:53:19 <fantasai> dbaron: I'm not sure how much the underlying mechanism here is related to fragmentation
15:53:22 <fantasai> florian: meant not to
15:53:31 <fantasai> dbaron: but even if it doesn't, thinking about it analogously might help
15:53:49 <fantasai> dbaron: The way floats fragment is not well-specified, and probably not interoperable across engines
15:54:07 <fantasai> dbaron: but my memory of how it works in Gecko, you can push the float to the next fragment without pushing the lines adjacent to it
15:54:13 <fantasai> dbaron: In some cases you can also fragment the float
15:54:16 <fantasai> dbaron: that might not make sense here
15:54:23 <fantasai> dbaron: so idk how well analogy to fragmentation works
15:54:28 <astearns> I think fragmenting floats is not terribly interoperable
15:54:50 <fantasai> dbaron: but the other behavior I could imagine is the float goes away at a shorter height in the first case, but lines do what you expect simultaneously
15:54:56 <fantasai> dbaron: that said, idk how hard it is to implement
15:55:01 <fantasai> andreubotella: I worry it's not easy, but I will have to check
15:55:13 <astearns> ack fantasai
15:55:24 <astearns> fantasai: I think that second case seems surprising
15:55:45 <astearns> fantasai: if we did fragment it would be more in line with author expectations
15:56:06 <astearns> fantasai: where we introduce the line clamp could be treated as a frag break
15:56:35 <fantasai> andreubotella: for continue:collapse, it doesn't work based on fragmentation
15:56:49 <fantasai> andreubotella: it just sizes the container based on the size it would have if you ignored the hidden content
15:56:53 <fantasai> andreubotella: and floats can be either shown or hidden
15:56:57 <astearns> ack florian
15:57:02 <fantasai> florian: So based on this, my suggestion is to close no change
15:57:31 <fantasai> florian: "we're doing collapse, but these advanced cases want fragmentation", in that case use fragmentation
15:57:44 <Rossen4> Rossen4 has joined #css
15:57:47 <fantasai> florian: But that assumes we'd actually define and implement continue:discard.
15:58:04 <fantasai> florian: But I worry we'll end up with something as complicated as fragmentation.
15:58:07 <kbabbitt> kbabbitt has joined #css
15:58:23 <Rossen4> Zakim, start meeting
15:58:23 <Zakim> RRSAgent, make logs Public
15:58:25 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:58:25 <fantasai> florian: [first picture is clamping by line number, second is clamping by height]
15:58:28 <SebastianZ> SebastianZ has joined #css
15:58:40 <fantasai> andreubotella: Another possibility is to not include float clearance in the sizing
15:59:00 <fantasai> andreubotella: the float would overflow the box essentially
15:59:17 <fantasai> andreubotella: That is a possibility that is easier than current behavior. I think that's what Firefox and WebKit do currently
15:59:27 <fantasai> andreubotella: This behavior is not what chromium does yet
15:59:54 <astearns> fantasai: so you’re saying we would size basedon the in-flow content only
16:00:00 <SebastianZ> present+
16:00:01 <astearns> fantasai: the float would clip?
16:00:16 <djmarland> djmarland has joined #css
16:00:20 <astearns> fantasai: you’d want to clip it to the content edge of the box
16:00:26 <astearns> fantasai: would be reasonable
16:00:45 <fantasai> florian: So clip at that point, without needing to specify it
16:00:51 <fantasai> fantasai: Yes. In particular to content edge, not padding edge
16:01:04 <fantasai> astearns: You're saying this is what other engines do?
16:01:20 <fantasai> andreubotella: FF and WebKit have the float overflow.
16:01:44 <fantasai> florian: That's oversimplifications. Not just overflow but *everything* overflows and is visible, unless you make it hidden.
16:01:51 <fantasai> astearns: Do we have a quick resolution?
16:02:00 <masonf> masonf has joined #css
16:02:02 <alisonmaher> alisonmaher has joined #css
16:02:07 <alisonmaher> present+
16:02:10 <fantasai> PROPOSED: Floats do not increase the height of a line clamp container. They are clipped to its content edge.
16:02:24 <lwarlow> lwarlow has joined #css
16:02:28 <davidleininger> davidleininger has joined #css
16:02:52 <fantasai> andreubotella: Comfortable with resolving this for now. Unsure how to implement the clipping.
16:03:02 <fantasai> andreubotella: I suspect it won't be a blocker. Not opposed.
16:03:09 <JakeA> present+
16:03:14 <fantasai> astearns: As you look into clipping to content edge, you can open up a new issue if you come up with something that makes more sense.
16:03:16 <davidleininger> present+
16:03:19 <fantasai> astearns: Any objections to proposed resolution?
16:03:34 <fantasai> RESOLVED: Floats do not increase the height of a line clamp container. They are clipped to its content edge.
16:03:44 <jfkthame> jfkthame has joined #css
16:03:46 <fantasai> Topic: Regular Telecon - Break - Administrative
16:03:58 <bkardell> present+
16:04:07 <jfkthame> present+
16:04:08 <kbabbitt> present+
16:04:15 <astearns> astearns has changed the topic to: Sep 17 agenda: https://lists.w3.org/Archives/Public/www-style/2025Sep/0008.html
16:04:25 <lwarlow> present+
16:04:53 <weinig> present+
16:05:12 <flackr> present+
16:05:22 <smfr> smfr has joined #css
16:05:22 <kbabbitt> scribenick: kbabbitt
16:05:27 <bramus> present+
16:05:29 <smfr> present+
16:05:32 <ydaniv> present+
16:05:39 <kbabbitt> Topic: Regular Telecon
16:06:16 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11899
16:06:17 <github-bot> Topic: [css-env] Add environment variables defined in WebKit
16:06:17 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11899.
16:06:55 <kbabbitt> SebastianZ: we wanted to publish fpwd of css-env-1
16:07:13 <kbabbitt> ... we had 1 issue that is blocking publication which is deciding whether to add the variables defined in webkkit to the spec or not
16:07:22 <bramus> q+
16:07:23 <Rossen4> q?
16:07:35 <Rossen4> ack bramus
16:07:47 <kbabbitt> bramus: on the thread we looked into these env vars
16:08:04 <kbabbitt> ... smfr mentioned that they were introduced back in the day but they are not aware of any sites that have adopted
16:08:09 <kbabbitt> ... I ran a query on httparchive to be sure
16:08:19 <kbabbitt> ... checking for env(fullscreen-*) in width height etc.
16:08:31 <kbabbitt> ... result came back with 0 sites out of 16 million+ had it in CSS
16:08:36 <kbabbitt> ... which is quite reassuring
16:08:46 <kbabbitt> ... smfr also mentioned they are open to renaming or unshipping these properties
16:08:53 <kbabbitt> ... given 0 sites matched, I think unshipping is the answer
16:09:02 <ntim> ntim has joined #css
16:09:02 <kbabbitt> ... so not add to css-env spec
16:09:09 <ntim> q+
16:09:12 <ntim> present+
16:09:15 <kbabbitt> Rossen4: seems like a reasonable proposal
16:09:20 <kbabbitt> ntim: I think it's reasonable
16:09:32 <kbabbitt> ... even if there are some use cases for this env var we probably want to rename anyway
16:09:40 <kbabbitt> ... for now removing it is the right call
16:09:42 <kbabbitt> +1
16:09:51 <kbabbitt> Rossen4: let's try to resolve
16:09:51 <emeyer> emeyer has joined #css
16:10:01 <emeyer> present+
16:10:06 <kbabbitt> ... any objections to dropping this list of env vars that are webkit specific from the spec?
16:10:11 <emeyer> +1
16:10:12 <kbabbitt> PROPOSED: drop the fullscreen-* vars
16:10:19 <kbabbitt> RESOLVED: drop the fullscreen-* vars
16:10:30 <kbabbitt> Rossen4: SebastianZ do you have a resolution to republish?
16:10:40 <kbabbitt> SebastianZ: It would be republish or publish, don't remember if we have one
16:10:51 <kbabbitt> Rossen4: any objection to publishing?
16:10:58 <kbabbitt> SebastianZ: this would be level 1
16:11:03 <kbabbitt> Rossen4: FPWD of css-env-1
16:11:16 <kbabbitt> Rossen4: since this is first public I'd like to have attention and make sure we're ready to publish
16:11:29 <kbabbitt> fantasai: as long as TabAtkins has reviewed and think it's complete, it's fine
16:11:34 <kbabbitt> TabAtkins: yes I think we should go for it
16:11:38 <kbabbitt> Rossen4: objections?
16:11:48 <kbabbitt> RESOLVED: publish FPWD css-env-1
16:11:55 <PaulG> PaulG has joined #css
16:11:56 <bramus> Yay!
16:11:59 <PaulG> present+
16:12:27 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12049
16:12:27 <github-bot> Topic: [css-ui] The interactivity property should not be included in the all shorthand
16:12:27 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12049.
16:13:01 <kbabbitt> masonf: just read it over and added a comment, question is about whether `interactivity` should be included in `all`
16:13:13 <kbabbitt> ... there was breakage in chrome related to inert attribute being reset by `all:initial`
16:13:20 <kbabbitt> ... best fix seems to be making that UA stylesheet rule !important
16:13:24 <kbabbitt> ... and putting interactivity back into all
16:13:26 <flackr> q+
16:13:30 <kbabbitt> ... should fix bug and keep important behaviors
16:13:32 <futhark> futhark has joined #css
16:13:35 <Rossen4> ack ntim
16:13:35 <ntim> ack ntim
16:13:37 <Rossen4> ack flackr
16:13:48 <kbabbitt> flackr: we used to allow un-inerting subtrees that were interactivity inert
16:13:53 <kbabbitt> ... which is I think why this was problematic
16:14:03 <kbabbitt> ... but now that we don't is the problem that it's on same element?
16:14:07 <kbabbitt> masonf: yes that's the problem
16:14:24 <kbabbitt> ... afaict the only problematic case is when inert attribute is on an element and on same element you do all:initial
16:14:29 <kbabbitt> ... you probably want inert attribute to win
16:14:35 <kbabbitt> ... I think adding !important does exactly that
16:14:39 <lwarlow> q+
16:14:44 <chrishtr> present+
16:14:45 <flackr> sounds reasonable
16:15:08 <kbabbitt> lwarlow: just to double check does this have any impact on modal dialogs?
16:15:13 <kbabbitt> ... that was the other case where interactivity came up
16:15:18 <Kurt> Kurt has joined #css
16:15:19 <kbabbitt> ... wasn't clear to me what solution was
16:15:24 <kbabbitt> masonf: 2 ways it can impact modal dialogs
16:15:38 <kbabbitt> ... direct way should not be affected, modals should stay uninerted with rest of page inerted regardless of all property
16:15:49 <kbabbitt> ... reason UA stylesheet has a modal rule that sets interactivity auto, corner case
16:16:11 <kbabbitt> ... it will automatically have that behavior but if author wants to make entire page inert, they have to contend with CSS rules about setting [missed]
16:16:21 <kbabbitt> ... other than that corner case, modal dialog inertness should just work
16:16:23 <kbabbitt> lwarlow: makes sense
16:16:33 <kbabbitt> masonf: and there's a way around it if they want to do that weird thing
16:17:05 <kbabbitt> masonf: everything I've said is my speculation about behaviors, if we go this route we will probably want to test it out
16:17:08 <kbabbitt> Rossen4: have you?
16:17:09 <kbabbitt> masonf: no
16:17:22 <kbabbitt> Rossen4: any other feedback or suggestions?
16:17:29 <lwarlow> +1
16:17:35 <flackr> +1
16:17:49 <kbabbitt> masonf: Proposal is to add !important to UA stylesheet rule for the inert attribute
16:17:55 <kbabbitt> Rossen4: objections?
16:18:04 <kbabbitt> RESOLVED: add !important to UA stylesheet rule for the inert attribute
16:18:05 <dbaron> +1
16:18:22 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12162
16:18:23 <github-bot> Topic: Add a property to retrieve plural instances of pseudo elements with the same selector
16:18:23 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12162.
16:19:13 <kbabbitt> flackr: proposal is to extend what we have in CSS pseudo to allow retrieving the pseudo elements that have multiple instances
16:19:45 <kbabbitt> ... if a browser does implement CSS pseudos, this is probably a good thing to do because we have many pseudos that can be matched with generic selectors
16:19:45 <sgill> sgill has joined #css
16:19:55 <kbabbitt> ... I agree with the proposal that it should behave a lot like querySelectorAll
16:20:01 <Rossen4> q?
16:20:04 <Rossen4> ack lwarlow
16:20:12 <kbabbitt> TabAtkins: also agree with use case and proposed ordering behavior flackr suggested in the issue
16:20:20 <kbabbitt> seems reasonable to me as well
16:20:28 <futhark> futhark has left #css
16:20:32 <kbabbitt> fantasai: 3 different proposals, which one?
16:20:41 <kbabbitt> flackr: element.pseudo is already in the css-pseudo-4 spec
16:20:50 <kbabbitt> ... proposal would be to add a method that gets all pseudos
16:20:55 <kbabbitt> ... first one I believe, something qSA-like
16:21:01 <kbabbitt> ... that returns all matching pseudos
16:21:08 <kbabbitt> TabAtkins: yes, the one listed under the Recommendation heading
16:21:14 <kbabbitt> flackr: open to bikeshedding
16:21:17 <kbabbitt> fantasai: okay with this
16:21:22 <kbabbitt> ... for element.pseudo would that return first?
16:21:24 <kbabbitt> flackr: yes
16:21:30 <kbabbitt> TabAtkins: yes, same as qS vs qSA
16:21:48 <kbabbitt> ... for bikeshedding purposes we should make it pseudoAll? not most grammatical but parallel naming is important
16:21:52 <kbabbitt> Rossen4: actualy it's not bad
16:21:54 <ydaniv> +1
16:21:56 <kbabbitt> flackr: seems reasonable
16:21:58 <JakeA> Also things like `matchAll` exist
16:22:03 <TabAtkins> true!
16:22:12 <kbabbitt> Rossen4: any other suggestions?
16:22:32 <kbabbitt> Rossen4: Proposal is to add element.pseudoAll that returns a list of nodes
16:22:36 <kbabbitt> Rossen4: objections?
16:22:40 <JakeA> List of `CSSPseudoElement`
16:23:03 <kbabbitt> flackr: yes, not list of nodes, list of CSSPseudoElement
16:23:15 <kbabbitt> RESOLVED: add element.pseudoAll that returns a list of CSSPseudoElement
16:23:35 <Rossen4> ack ntim
16:24:04 <kbabbitt> ntim: I think element.pseudo was resolved on different issue
16:24:15 <kbabbitt> Rossen4: if you feel we need to discuss more, bring up that other issue or open a new one
16:24:25 <flackr> +1 we'll keep the names in sync
16:24:29 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11845
16:24:30 <github-bot> Topic: [css-forms-1] Password visibility toggle
16:24:30 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11845.
16:24:30 <ntim> (It should be element.pseudoElement)
16:24:32 <TabAtkins> scribe+
16:24:51 <TabAtkins> kbabbitt: in April we resolved to add a pseudo-element for password vis toggle on input type=password
16:24:56 <TabAtkins> kbabbitt: left name to be bikeshedded
16:25:06 <TabAtkins> kbabbitt: have been some discussion in the issue, especially about naming form control pseudos in general
16:25:20 <TabAtkins> kbabbitt: as a general principle, use the word "icon" to indicate graphical indicators, "button" to indicate clickable
16:25:27 <TabAtkins> kbabbitt: from that, suggests we call it ::reveal-button
16:25:40 <TabAtkins> kbabbitt: and as an additional proposal, should rename the other Forms 1 pseudos to be consistent with this pattern
16:25:42 <lwarlow> +1
16:25:44 <TabAtkins> +1
16:26:15 <lwarlow> q+
16:26:24 <TabAtkins> fantasai: things get a little ambiguous with, sya, ::picker-icon, which is both clickable and an icon
16:26:35 <TabAtkins> fantasai: do we really want to be so clear about which is a button and which is an icon in our naming?
16:26:56 <TabAtkins> kbabbitt: I think there is some inconsistency in the naming, yes in some cases the picker would be a button in others it's an icon...
16:27:04 <masonf> q+
16:27:05 <TabAtkins> fantasai: I think that would be confusing for authors, yeah. should be consistent
16:27:25 <TabAtkins> fantasai: but that brings up whether we want to be so explicit in the names, or if we do want to lean into being unambiguous about whether it's an indicator or button
16:27:28 <ntim> q+
16:27:34 <fantasai> s/unambiguous/ambiguous/
16:27:39 <TabAtkins> kbabbitt: personally id' lean toward consistency when possible
16:27:39 <ydaniv> q+
16:27:44 <Rossen4> ack lwarlow
16:27:56 <TabAtkins> lwarlow: I've been thinkinga bout this for a bit, think I mentioned the step-up/down buttons
16:28:04 <TabAtkins> lwarlow: ideally something that's a button we'd call a button, I think
16:28:08 <TabAtkins> lwarlow: there are some weird cases tho
16:28:30 <TabAtkins> lwarlow: in a select element the picker icon is an icon, it's not actually a button. it's not really clickable, the select itself is what's clickable. so picker-icon makes sense there
16:28:51 <TabAtkins> lwarlow: but in a date input, the picker would be an actual button; you can click on the element but only the button actually summons the picker
16:29:16 <TabAtkins> lwarlow: file-selector is the other case - it looks like a button, acts like one. but really the whole element is clickable. so arguably that's not a "button" either....
16:29:31 <TabAtkins> lwarlow: agree that making authors write ::picker-icon sometimes and ::picker-button sometimes isn't ideal
16:29:41 <TabAtkins> lwarlow: but for new names, I do recommend having button in the name if it's a button
16:29:54 <TabAtkins> fantasai: for date picker, it depends on the platform, some pop it when you click anywhere
16:30:06 <TabAtkins> fantasai: so there's some ambiguity on whether it's an icon or button
16:30:14 <lwarlow> We'd probably want to specify that though ideally?
16:30:19 <Rossen4> q
16:30:25 <TabAtkins> fantasai: we have things that act differently between controls, and things that act differently on a single control depending on time or paltform
16:30:45 <TabAtkins> fantasai: so that raises the question - if these aren't really two distinct categories, should we even lean into categorizing everything, or lean away and not categorize them?
16:30:50 <TabAtkins> masonf: was gonna say a lot of that too
16:30:54 <TabAtkins> masonf: agree it's very ambiguous
16:31:02 <Rossen4> ack masonf
16:31:10 <TabAtkins> masonf: picker-icon was chosen because it was indeed not a button (the whole control is)
16:31:18 <lwarlow> q+
16:31:29 <TabAtkins> masonf: so i'd lean towards using -icon for everything because whether it's a button or not is ambiguous, but it's always an icon in some way
16:31:43 <Rossen4> ack ntim
16:31:59 <TabAtkins> ntim: I lean toward simplicity, like ::step-up (no suffix)
16:32:12 <TabAtkins> ntim: but in this case I think simplicity would be using the -icon suffix everywhere
16:32:18 <TabAtkins> ntim: making the distinction is really hard, yeah
16:32:33 <Rossen4> ack ydaniv
16:33:03 <TabAtkins> ydaniv: from what I know in UIs, button is something you activate with a click/keypress, and icon is activated by hover/focus, so I lean towards button
16:33:11 <Rossen4> ack lwarlow
16:33:23 <TabAtkins> lwarlow: wanted to push back on "it's always an icon", not sure that's always true
16:33:39 <kbabbitt> q+
16:33:42 <masonf> It's an icon with the words "choose a file" ... :-)
16:33:52 <TabAtkins> lwarlow: file-selector-button is actually a button, not an icon. step-up/down can be arguable, but they're rendered as a button. does depend on stylesheet to some extent
16:34:10 <TabAtkins> lwarlow: I do agree ::reveal should have a suffix, ::reveal on its own isn't clear enough
16:34:24 <TabAtkins> lwarlow: it even reads more as a pseudo-class on its own, not right as a pseudo-element
16:34:44 <TabAtkins> lwarlow: so id' be okay with ::reveal-icon if the group likes it. but i'd be a bit more against ::step-up-icon
16:34:51 <JakeA> `revealer`?
16:34:52 <Rossen4> ack kbabbitt
16:35:07 <ntim> I like ::reveal-icon because it also opens the possibility for other things than just an interactive button
16:35:21 <TabAtkins> kbabbitt: I just need a name so I can write down a spec, can explore the more general case in another issue. fine with either icon or button
16:35:22 <Rossen4> ack fantasai
16:35:25 <lwarlow> It's not an icon with words though... it's just some text in all 3 engines.
16:35:40 <TabAtkins> fantasai: we should focus on the author experience and what they'll have to memorize, and how we can reduce the memory load. so staying away from categorizing too much is best
16:35:58 <ntim> +1 to fantasai
16:36:00 <lwarlow> +1 I'd be okay with that
16:36:02 <TabAtkins> fantasai: for this issue, seems like we might just say ::clear-icon and ::reveal-icon (and leave the other pseudos undecided for now)
16:36:07 <TabAtkins> +1 for me too
16:36:07 <kbabbitt> +1 I'd be happy with that
16:36:14 <fantasai> s/undecided/alon/e
16:36:17 <fantasai> s/undecided/alone/
16:36:26 <masonf> +1
16:36:42 <TabAtkins> RESOLVED: Go with ::clear-icon and ::reveal-icon
16:36:52 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12218
16:36:54 <github-bot> Topic: [css2][css-flow][css-sizing] How do min/max block sizes affect bottom margin collapse with last child?
16:36:54 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12218.
16:37:04 <djmarland> Is there a distinction between things that edit the contents of the field, and things that do other things
16:37:33 <fantasai> github: none
16:37:59 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12132
16:37:59 <github-bot> Topic: [css-backgrounds-4] Using logical keywords in background-position shorthand with multiple backgrounds
16:37:59 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12132.
16:38:53 <kbabbitt> weinig: basically this boils down to a discussion about how we should expose these things
16:39:11 <kbabbitt> ... and whether we need a special wording or special value to represent the fact that this is a logical property
16:39:15 <kbabbitt> ... in a way that's not usually done
16:39:24 <kbabbitt> ... not sure there's a resolution to be had yet, probably needs specific spec text proposal
16:39:30 <kbabbitt> ... before there's motion forward
16:39:36 <kbabbitt> fantasai: I think we need to hash out some specifics
16:39:42 <kbabbitt> ... would it be useful to introduce people?
16:39:48 <kbabbitt> TabAtkins: I would find it useful to have a quick summary
16:39:56 <kbabbitt> Rossen4: yes especially if we want to resolve
16:40:19 <kbabbitt> weinig: problem statement is that we want to add the logical versions of background-position
16:40:30 <kbabbitt> ... b-p-block, -inline
16:41:01 <kbabbitt> ... because these are list properties, you can wind up in a position where it's not clear ...
16:41:40 <kbabbitt> fantasai: the issue is that, in background-position, we have some logical, some physical, some both ways of specifying position
16:41:46 <kbabbitt> .... we also have longhands for background-position
16:41:57 <kbabbitt> ... x and y, and probably want block and inline longhands as well
16:42:11 <kbabbitt> ... mapping these two together ends up requiring some kind of way of tracking which was specified later in the cascade
16:42:19 <kbabbitt> ... also requires a way to represent computed value of each of these things
16:42:28 <kbabbitt> ... for the first problem, proposal was to add a `defer` keyword
16:42:46 <kbabbitt> ... the author would usually not use, but implementation would use to track each individual longhand whether it's setting something
16:42:51 <kbabbitt> ... or the other property is setting something
16:42:58 <kbabbitt> ... if both say defer, resolve to initial value
16:43:20 <kbabbitt> ... in terms of representing computed value, there's been some discussion, if you set background-position-inline to start-edge, what is value of background-position-x and y
16:43:33 <kbabbitt> ... latter half of discussion is about tracking that information about which side you're setting from
16:43:36 <kbabbitt> ... into computed value
16:43:46 <kbabbitt> ... and then serializing out the appropriate depending on which longhand it came from
16:44:25 <kbabbitt> weinig: that sounds right. it has to do with the fact that the logical properties usually have e.g. margin: left maps very clearly to inline start or end always
16:44:48 <kbabbitt> ... but because background takes a 2-value thing there's no clear mapping from e.g. background block to regular background
16:44:52 <kbabbitt> ... and so we need additional state
16:45:12 <kbabbitt> fantasai: for example background-position-x 0% has same meaning as background-position-inline 100% in rtl
16:45:24 <kbabbitt> ... with other shorthands we have all 4 sides and each one maps exactly and computed value space is the same
16:45:26 <kbabbitt> ... so you can have a single value
16:45:33 <dbaron> The main problems seems to be that there are *both* logical keywords *and* logical sub-properties, and it's a list valued property that allows mixing logical and physical within the list.
16:45:38 <SebastianZ> q+
16:45:43 <kbabbitt> ... whereas for these properties, in that example you can't return 0% because that would give you the opposite
16:45:53 <kbabbitt> SebastianZ: what fantasai said is what I posted in one of my later commments
16:46:04 <kbabbitt> ... there are some examples regarding physical and logical properties and how to handle them
16:46:10 <kbabbitt> ... idea would be to add a new defer keyword for that
16:46:12 <kbabbitt> ... like fantasai said
16:46:19 <kbabbitt> ... if you set background-position left bottom
16:46:26 <kbabbitt> ... and later read background-position-inline
16:46:29 <kbabbitt> ... question is what you get back
16:46:35 <kbabbitt> ... idea was to add a defer keyword
16:46:49 <kbabbitt> ... was wondering if we need that keyword or if we can resolve that you use start or end in those cases
16:47:11 <kbabbitt> fantasai: I think weinig is right, we need to do a thorough writeup of details
16:47:22 <kbabbitt> weinig: issue contains a lot of examples, work through a lot of edge cases
16:47:37 <kbabbitt> ... sticking point was that the way logical properties are currently defined has certain assumptions about being able to map directly
16:47:50 <kbabbitt> ... either we need to change those base assumptions or add some additional state here that works with that structure
16:48:01 <kbabbitt> ... ultimately we can work through all of the examples to see they do make sense, and you can map them
16:48:14 <kbabbitt> ... we just need the foundational logic to be updated to allow this more complicated mapping
16:48:20 <kbabbitt> ... we need to write something up, I can try to do that
16:48:30 <kbabbitt> Rossen4: wondering if we should continue that discussion in the issue
16:48:32 <kbabbitt> fantasai: yes
16:48:43 <kbabbitt> ... that's the next step
16:48:51 <dbaron> I think another question is whether the logical subproperties are actually desirable, or whether we should just add new logical keywords.
16:49:27 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/3070
16:49:28 <github-bot> Topic: [css-flexbox-2] Add flex-wrap: balance;
16:49:28 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/3070.
16:49:49 <kbabbitt> TabAtkins: we've been wanting some way fo balanancing flex lines forever
16:49:59 <kbabbitt> ... ian spent some time putting together an experimental impl
16:50:06 <kbabbitt> ... available in chrome 138 with experimental web platform features
16:50:16 <kbabbitt> ... quick description of what we've proposed, details are malleable:
16:50:23 <kbabbitt> ... syntactically this is just an addition to flex-wrap property
16:50:31 <kbabbitt> ... balance keyword with optional integer with # of lines to balance
16:50:43 <kbabbitt> ... behavior is: figure out how many lines flexbox will have, or estimate with basic layout
16:50:50 <kbabbitt> ... and distribute in balanced fashion instead of greedy fashion
16:51:01 <kbabbitt> ... current behavior is to use same size as for line breaking
16:51:12 <kbabbitt> ... potentially other ways to balance things nicely across multiple rows
16:51:29 <kbabbitt> ... minimum lines feature, integer, is required for cases where it's a column flexbox where available space is infinite and you would never wrap
16:51:43 <kbabbitt> ... in wikipedia bibliography, cuyrrently done using expensive manual code
16:51:50 <kbabbitt> ... could insteadf be done with a flexbox with 2 columns
16:51:56 <kbabbitt> ... ends up being a simple feature overall
16:52:02 <kbabbitt> ... precise details we can continue to work out
16:52:07 <kbabbitt> ... we're asking to be able to add this to flexbox 2
16:52:16 <kbabbitt> fantasai: we have several things that should go into flex 2
16:52:22 <kbabbitt> TabAtkins: this is mature, we can open spec with it
16:52:23 <iank_> Received very positive developer feedback - https://bsky.app/profile/una.im/post/3lpcjcjn4w22r
16:52:30 <kbabbitt> fantasai: how gaps interact with flex algorithm
16:52:39 <Rossen4> ack SebastianZ
16:52:54 <kbabbitt> TabAtkins: request is open a new draft, flexbox 2, editor's draft, include at least this flex-wrap balance feature
16:53:02 <kbabbitt> ... and at editor's discretion whatever else we want to put in
16:53:18 <Rossen4> ack fantasai
16:53:21 <kbabbitt> fantasai: I think having a flex-wrap balance feature is a good idea and we should do it
16:53:29 <kbabbitt> ... some discussion about having balance stuff on item-pack instead of flex-wrap
16:53:41 <kbabbitt> ... in any case you probably want to split out whether you're wrapping and what direction from the style
16:53:45 <kbabbitt> ... just like we do for text balancing
16:53:54 <kbabbitt> ... the kind of, how you prefer to place items is a separate control
16:53:59 <kbabbitt> ... so I think it should be a separate property
16:54:08 <kbabbitt> ... last time we talkd about it, we tralked about item-pack: balance
16:54:14 <kbabbitt> ... happy with that or we can consider other things
16:54:30 <kbabbitt> TabAtkins: we need to resolve those remaining items questions sooner rather than later but I don't want to take one right now
16:54:36 <kbabbitt> fantasai; in any case it should be a separate property
16:54:41 <kbabbitt> TabAtkins: happy to figure that out in the draft
16:54:49 <kbabbitt> ... not looking to ship tomorrow, but ready to explore
16:54:56 <kbabbitt> Rossen4: proposal is to open new ED for flex level 2
16:55:07 <kbabbitt> ... and flex-wrap balance, and continue to work on it there
16:55:16 <kbabbitt> Rossen4: objections?
16:55:29 <kbabbitt> fantasai: happy to take a resolution to add a flex balance feature as long as it's a separate property
16:55:37 <kbabbitt> TabAtkins: happy to have flex balance feature, syntax TBD
16:55:38 <dholbert> I'm a little uneasy about the "leave how to balance up to implementations" part; want to be sure the behavior is reasonably specified
16:55:45 <dholbert> but not objecting to the feature in general
16:55:49 <kbabbitt> Rossen4: any objections?
16:55:54 <fantasai> PROPOSED: Add a flex wrap balance feature, as a property separate from flex-wrap
16:56:25 <kbabbitt> TabAtkins: syntax TBD as part of wrap up of item discussion
16:56:30 <kbabbitt> fantasai: but put something in spec right?
16:56:40 <kbabbitt> TabAtkins: yes, doesn't matter what yet, don't need to resolve on syntax yet
16:56:48 <kbabbitt> ... don't want to resolve on syntax until we have the wider discussion
16:56:59 <kbabbitt> fantasai: draft something into ED but draft as separate property
16:57:06 <kbabbitt> TabAtkins: we don't need that as part of the resolution
16:57:13 <kbabbitt> Rossen4: syntax TBD is good enough, we'll figure out what that syntax is
16:57:31 <kbabbitt> fantasai: happy to leave syntax TBD, would like it to not be flex [missed]
16:57:36 <kbabbitt> TabAtkins: will mark it off as flex bikeshed
16:58:27 <kbabbitt> RESOLVED: Add a flexbox level 2 with flex balance feature, syntax TBD
16:59:11 <kbabbitt> github-bot, end topic
16:59:39 <Rossen4> Zakim, end meeting
16:59:39 <Zakim> As of this point the attendees have been miriam, dholbert, flackr, romain, dbaron, florian, ydaniv, kizu, andreubotella, SebastianZ, alisonmaher, JakeA, davidleininger, bkardell,
16:59:42 <Zakim> ... jfkthame, kbabbitt, lwarlow, weinig, bramus, smfr, ntim, emeyer, PaulG, chrishtr
16:59:42 <Zakim> RRSAgent, please draft minutes v2
16:59:44 <RRSAgent> I have made the request to generate https://www.w3.org/2025/09/17-css-minutes.html Zakim
16:59:51 <Zakim> I am happy to have been of service, Rossen4; please remember to excuse RRSAgent.  Goodbye
16:59:51 <Zakim> Zakim has left #css
17:19:58 <antonp> antonp has joined #css