16:57:52 <RRSAgent> RRSAgent has joined #css
16:57:56 <RRSAgent> logging to https://www.w3.org/2025/01/15-css-irc
16:57:56 <Zakim> RRSAgent, make logs Public
16:57:57 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:58:20 <TabAtkins> I'll be a few minutes late to the call
16:59:03 <kbabbitt> kbabbitt has joined #css
16:59:52 <jensimmons> jensimmons has joined #css
17:00:00 <rachelandrew> present+
17:00:05 <jensimmons> present+
17:00:08 <kbabbitt> present+
17:00:22 <stepheckles> stepheckles has joined #css
17:00:34 <stepheckles> present+
17:00:47 <kizu> kizu has joined #css
17:01:03 <kizu> present+
17:01:18 <sgill> sgill has joined #css
17:01:21 <alisonmaher> alisonmaher has joined #css
17:01:26 <alisonmaher> present+
17:01:33 <fantasai> present+
17:01:45 <ChrisL> present+
17:01:46 <bramus> present+
17:01:46 <dbaron> Present+
17:01:53 <PaulG> PaulG has joined #css
17:01:55 <keithamus> keithamus has joined #css
17:01:55 <sgill> present+
17:01:57 <PaulG> present+
17:02:02 <keithamus> present+
17:02:03 <SebastianZ> SebastianZ has joined #css
17:02:06 <schenney> schenney has joined #css
17:02:08 <SebastianZ> present+
17:02:11 <jfkthame> jfkthame has joined #css
17:02:13 <schenney> present+
17:02:27 <emeyer> emeyer has joined #css
17:02:31 <joshtumath> present+
17:02:56 <emilio> present+
17:03:08 <emeyer> Unfortuantely I cannot volunteer today.
17:03:12 <emeyer> present+
17:03:21 <andreubotella> andreubotella has joined #css
17:03:30 <castastrophe> castastrophe has joined #css
17:03:38 <castastrophe> present+
17:04:01 <dholbert> dholbert has joined #css
17:04:20 <bramus> ScribeNick: bramus
17:04:23 <oriol> present+
17:04:40 <jfkthame> present+
17:05:05 <bramus> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10671
17:05:05 <github-bot> Topic: [meta] Rechartering 2025-2027
17:05:05 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10671.
17:05:48 <bramus> ChrisL: few responses
17:06:04 <bramus> ChrisL: 1st response saying nothing special
17:06:15 <bramus> ChrisL: 2nd asking extra language
17:06:36 <bramus> ChrisL: response is that it sounds great and doesnt sound specific to CSS. suggestion to suggest to other group or some wording. no response yet.
17:06:38 <dbaron> s/nothing special/editorial addition saying CSS is good for a11y/
17:06:47 <bramus> ChrisL: suggestions welcome here
17:07:04 <ChrisL> https://www.w3.org/2024/09/font-i18n-privacy.html
17:07:09 <bramus> ChrisL: here is a link to a doc I wrote for tpac
17:07:28 <bramus> … long running issue is sometimes called a privacy issue or an i18n issue that pulls in opposite directions
17:07:33 <bramus> … had good discussion at TPAC
17:07:44 <bramus> … now, third comment … from center for democracy and technology
17:07:48 <fantasai> Regarding the previous point, how much of what's requested actually belongs in the charter?
17:08:03 <bramus> … looking forward to collaborating with css and privacy and i10n
17:08:14 <bramus> … not sure we can change charter to say we have more progress on this
17:08:20 <bramus> … i think they are saying that we should keep going
17:08:29 <bramus> … would love to reply that we will do that
17:08:39 <bramus> … does that seem reasonable?
17:08:43 <bramus> astearns: sounds reasonable
17:08:50 <bramus> ChrisL: can you send that?
17:09:16 <bramus> astearns: where to send it to?
17:09:23 <bramus> ChrisL: somewhere public would be good
17:09:46 <bramus> … should be addressed to the privacy wg and i18n wg
17:09:57 <bramus> … all of those were comments of the form whether we are doing things about something
17:10:05 <bramus> … last one is from brave and is a formal objection
17:10:11 <ChrisL> https://lists.w3.org/Archives/Member/w3c-css-wg/2025JanMar/0017.html
17:10:25 <bramus> ChrisL: unfortunately they were not able to attend the meeting at tpac back in the day
17:10:43 <bramus> … its not clear whether they realize work had been done, although they sort of quote a bit from that
17:10:55 <bramus> … i think they are aware but htey are saying we are doing nothing and are not addressing things
17:11:10 <ChrisL> Brave will happily remove our FO to the rechartering if the group proposes
17:11:10 <ChrisL> a plan to address the fingerprinting surface, and to commit to
17:11:10 <ChrisL> incorporating mitigations for this fingerprinting vulnerability into the
17:11:10 <ChrisL> group's specs.
17:11:11 <bramus> … they will remove FO if the WG plans to remove the fingerprinting surface
17:11:18 <bramus> … (see copy-paste)
17:11:34 <bramus> … also saying that our _refusal_ to address is concerning
17:11:41 <bramus> … what should we do as a group?
17:11:57 <bramus> astearns: my recollection is that we sort of had a plan, but not one that we can push through the specs directly
17:12:12 <bramus> … we thought that there would be a way of threading th eneedle between i18n and privacy
17:12:26 <bramus> … in saying that “yes browsers can limit access to user installed fonts if they provide a UI that popped in“
17:12:33 <bramus> ChrisL: my recollection as well, but have no resolution on that
17:12:41 <astearns> s/popped/opt
17:12:50 <bramus> … i think that nick dotty was of the opionion that UAs should do that
17:13:01 <bramus> … cost is that its an opt-in, either web wide or site-specifici
17:13:08 <bramus> … seems clear enough to propose as spec text
17:13:17 <jensimmons> q+
17:13:21 <bramus> … also true that ther eare other fingerprinting issues and should commit to solving those
17:13:55 <bramus> jensimmons: if there is gonna be text that mandates a UA to turn off privacy preservering features then I need to discuss internally
17:14:04 <bramus> astearns: but that has been a way forward for a while
17:14:13 <bramus> … maybe apple have arleady been thingkin gabout this
17:14:17 <bramus> jensimmons: I will try to find out
17:14:35 <bramus> ChrisL: Of course I will put proposed text into an issue, not directly in the spec.
17:14:41 <bramus> … dont want to break the web
17:15:21 <ChrisL> qq+
17:15:23 <bramus> fantasai: one of the things we can do to reduce the surface is to only allow access to user installed fonts if they give you access to code points that is outside the range of those served by the system
17:15:29 <bramus> … could limit it to letters
17:15:35 <bramus> … outside of the normal range
17:15:40 <astearns> ack jensimmons
17:15:49 <astearns> ack fantasai
17:15:51 <bramus> … but would allow a browser to uncoditoianlly allow access to user installed fonts, but only when necesaary
17:15:52 <astearns> ack ChrisL
17:15:52 <Zakim> ChrisL, you wanted to react to a previous speaker
17:16:18 <bramus> ChrisL: sometimes people install a newer version of a font because some glyphs were wrong, so doing a codepoint by codepoint thing means they would still get the broken behavior
17:16:50 <bramus> astearns: for the purpose of this discussion: chris you will open an issue with a proposed text and we will discuss that on a call very very soon and show that as the proposed plan that brave is requiring
17:16:54 <bramus> ChrisL: yes
17:17:03 <bramus> fantasai: when does our charter expire?
17:17:07 <bramus> ChrisL: have until march
17:17:14 <bramus> fantasai: so can discuss at f2f
17:17:30 <bramus> jensimmons: would love to see this fonts issue written out separately, in 1 place
17:17:42 <bramus> ChrisL: the whitepaper I linked to is basically that writeup
17:17:54 <TabAtkins> present+
17:19:12 <bramus> github-bot, take up https://github.com/w3c/csswg-drafts/issues/6867
17:19:12 <github-bot> Topic: [selectors] Pseudo-class to indicate when a slot has content
17:19:12 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6867.
17:19:42 <bramus> keithamus: last week we resolved to match when the fallback content is not being displayed
17:19:47 <bramus> … whoich means using non flat tree
17:19:50 <lea> present+
17:19:53 <bramus> … think this is a mistake
17:20:00 <bramus> … some people form the WC community reached out
17:20:04 <lea> q?
17:20:06 <lea> q+
17:20:11 <bkardell_> present+
17:20:17 <bramus> … was maybe overindexing on maybe wehter the fallback tree is displayed or <missed>
17:20:30 <bramus> … would like to change the resolution to use the flattened tree
17:20:50 <astearns> ack lea
17:21:15 <bramus> lea: do we stay consistent with JS API or do we do a better thing? Both are valid. Proably should follow JS appraoch for consistency
17:21:23 <bramus> … am wondering if we can have two pseudo classes
17:21:33 <miriam> present+
17:21:39 <bramus> keithamus: JS api offer the optionality  through a flattened flag
17:21:47 <bramus> … has more to do with compat with ::slotted
17:21:52 <bramus> … cannot do slotted-slot
17:21:55 <bramus> … also composition
17:22:08 <bramus> … authors of components are more likely to want to know if th ething has been slotted.
17:22:19 <keithamus> s/fallback tree is displayed or <missed>/fallback content is displayed vs the flattened slots/
17:22:21 <bramus> … if that is many layers deep seems irrelevant to them
17:22:24 <bramus> lea: agree
17:22:43 <bramus> keithamus: proposed resolution is to use the flattened tree
17:22:55 <bramus> … to create  new selector that uses non-flat tree I have no opinion
17:23:04 <lea> q?
17:23:16 <bramus> … polyfills: wont affect us because JS has optionality for both
17:23:38 <bramus> lea: I understand the sentiment that we need to ship this ASAP. really needed
17:23:52 <bramus> keithamus: I have i2s for chrome and I believe we are working towards one for firefox as well
17:23:54 <lea> s/I understand the sentiment /I completely agree with the sentiment /
17:23:55 <bramus> … need to resolve on this
17:24:09 <keithamus> PROPOSED RESOLUTION: :has-slotted should use the flattened tree to resolve if content is slotted or not.
17:24:29 <lea> +1
17:24:41 <bramus> astearns: with a future issue on adding a param or new pseudo to not use the flat tree
17:25:03 <bramus> … that’s a different, later, discussion
17:25:06 <bramus> keithamus: sgtm
17:25:26 <bramus> chrishtr: do we need resived resolution?
17:25:35 <bramus> astearns: no, wanted to point out other issue is out of scope
17:25:37 <lea> PROPOSED RESOLUTION: :has-slotted should use the flattened tree to resolve if content is slotted or not. We could later discuss a different pseudo-class for the other behavior.
17:25:43 <bramus> chrishtr: so someone should raise a new issue
17:26:03 <bramus> keithamus: i'll try and do that tomorrow
17:26:17 <keithamus> RESOLVED: :has-slotted should use the flattened tree to resolve if content is slotted or not. We could later discuss a different pseudo-class for the other behavior.
17:26:26 <bramus> keithamus: thanks everyone for your time
17:26:46 <bramus> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11325
17:26:46 <github-bot> Topic: [css-rhythm-1] `block-step-size` should not establish an independent formatting context
17:26:46 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11325.
17:27:20 <bramus> jensimmons: block-step-size establishes a new BFC on the box tha tthe prop is applied to
17:27:43 <bramus> … authors are gonna apply block-step to article element and apply to every p inside, or every img in figure.
17:27:53 <bramus> … if we make all those have a BFC that is a lot
17:27:59 <bramus> … means blokc-step wont work on floated content
17:28:06 <bramus> … should not have establish an independent FC
17:28:21 <bramus> … there’s a few comments in the issue that shows photos tha
17:28:35 <bramus> … proposed resolution to no longer require an independent formatting context
17:28:46 <bramus> astearns: questions?
17:28:54 <bramus> … seems reasonable
17:29:13 <bramus> fantasai: complication here is about floats, not about sizing of floats but content that is impacted by a float
17:29:34 <bramus> … if you have a box that is impacted by floats and tries to avoid them. if it gets taller it might need to get narrower
17:29:38 <bramus> … gets complicated with shapes
17:29:49 <iank_> q
17:29:55 <iank_> q+
17:30:01 <bramus> … if we want to do this – which i think we do – we can try to determine how much of an impact there and limit the number of cycles
17:30:23 <bramus> … issue is that it moves the box down, e.g when using margin
17:30:28 <bramus> … creates a position vs size relationship
17:30:43 <bramus> … in case where it moves down and causes more complications, then we could say space goes to the ened
17:30:53 <bramus> … and in the future figure out cycle-breaking
17:30:57 <bramus> … would cover basic cases
17:31:07 <astearns> ack iank_
17:31:08 <dbaron> I think we have some similar sort of cycles already with BFC placement around floats, but I'm not sure if these are equivalent or worse.
17:31:16 <bramus> iank_: dont you already have this problem?
17:31:33 <bramus> … everything that avoids floats that is block level establishes new BFC of some varieyt
17:31:59 <bramus> … if you set block-step-size on some parent you already have the case where a new FW that avoids floats is adding to margins then it goes to next layout area
17:32:12 <bramus> fantasai: oh, i misremembered the issue, this is about wrapping
17:32:28 <bramus> … so you have a float and a box that has text in it that wraps to avoid the float
17:32:48 <bramus> … if that float has a complicated shape or ends before the end of the paragraph
17:32:59 <bramus> … when you say to have the p have a block-step-size of 1lh
17:33:09 <bramus> … and you want to add 1em to either side of the p
17:33:13 <bramus> … can cause all content to move down
17:33:23 <bramus> … which can cause calc of line boxes to ???
17:33:27 <bramus> … dont think we want to do that
17:33:29 <bramus> … or not all the time
17:33:46 <astearns> s/???/change and re-wrap
17:33:50 <bramus> … then that is what can cause the size to … if it rewraps end up with extra line which changes amount of space, which needs recalc of step size
17:33:53 <bramus> iank_: I see
17:33:58 <bramus> … seems problematic
17:34:05 <schenney> schenney has joined #css
17:34:24 <bramus> fantasai: proposal is to track to see if the impacted lines by how much
17:34:29 <bramus> … or if additiona lines become impact
17:34:45 <bramus> … if no change, then adjust space above and below
17:34:57 <bramus> … but if it does impact the space the only insert at the bottom
17:35:05 <bramus> … that way you get the rhtyhm that you requested
17:35:18 <bramus> … it goes all at th ebottom where it wont change the position of the lines
17:35:25 <bramus> iank_: doesnt that break the rhtyhgm?
17:35:39 <bramus> fantasai: not really. the function does not impact internal contents that might or not be on the rhtythm
17:35:54 <joshtumath> s/rhtyhgm/rhythm/
17:35:57 <bramus> … goal is that make sure that thing that is after the x, you resume the rhytm
17:36:12 <bramus> … to make sure the margin box is an ?? number of steps
17:36:32 <bramus> … we can say that “floats are impacting stuff and we dont want to end up with a cycle so we insert at the bottom“
17:36:44 <bramus> … in the future we can choose to try more layout options
17:37:07 <bramus> … so in cases where its safe to ?? then you get exactly what you wanted and if its not the case then we do bottom only
17:37:42 <bramus> iank_: i think thats fine as long … would prefer it to be if any of the content is affected by floats you always place at the end because we already have root layout scenarios that trigger things like clearance
17:37:53 <bramus> … or how does tha twork? might be problematic as well
17:38:01 <bramus> … how does this work with collapsing margins?
17:38:31 <bramus> fantasai: current spec says that you measure the box’s own specified margin to find its margin box and make that a ?? of the step size
17:38:47 <bramus> … means tha tin some cases that margin inside tha tis larger than outside margin will do the step sizing thing correctly
17:38:55 <bramus> … i specced it like that to keep it simple
17:39:02 <ydaniv> ydaniv has joined #css
17:39:11 <bramus> iank_: … might be problematic
17:39:48 <bramus> … doing content on border box moditifaction is fine, margin box inside of a block layout context gets problematic bc of interaction iwth collapsing margins and floats and float clearance which would break the feature
17:39:56 <bramus> astearns: so we need separate issue for that
17:40:01 <bramus> iank_: i'll file that
17:40:19 <bramus> … at the end of the day you wnat to shift the box’s posiition, not alter the margin
17:40:33 <bramus> fantasai: in terms of changing the margin we are not changing the computed value, only from a layout perspecttive
17:40:40 <bramus> iank_: so wouldnt be reflected in gCS
17:40:47 <bramus> … things like margin-trim do, though
17:41:00 <bramus> fantasai: does it?
17:41:06 <bramus> iank_: yep.
17:41:20 <bramus> … it’s complicated / nuanced
17:41:26 <bramus> astearns: lets set margin collapsing aside
17:41:45 <bramus> … talk about the desire to have a single behavior for block step size in the presence of floats
17:41:53 <bramus> … suggestion is to always place at the bottom
17:41:58 <bramus> … does that make sense?
17:42:04 <bramus> fantasai: as a first step yes
17:42:10 <bramus> … but later might want to do a layout check
17:42:13 <fantasai> ACTION: fantasai to clarify that block-step doesn't impact computed sizes
17:42:30 <bramus> iank_: could do that, its a little bit complex because …
17:42:39 <bramus> … can potentially do that if there’s no intruding floats
17:42:50 <bramus> … already have comlicated logic in block layout
17:42:55 <oriol> q+
17:42:59 <bramus> … interactions is really complex
17:43:20 <bramus> … if there are intruding floats and their geometry changes then we always add to bottom
17:43:31 <bramus> fantasai: changes or if it doesnt extend far enough
17:43:36 <bramus> iank_: dont want that logic
17:43:41 <bramus> … gets complicated with clearance
17:44:05 <bramus> jensimmons: issue 1901 is relevant here
17:44:58 <bramus> fantasai: two things we want to resolve here is that it does not establish new BFC and two if inserting space above would cause complications with floats then we insert the space below only
17:45:10 <bramus> … and then i would like for us to dig into the complications that might be too complicated
17:45:16 <bramus> … and ideally reduce the amount
17:45:41 <bramus> … can have the spec a little bit undefined there to allow implementers to give feedback
17:45:48 <astearns> ack oriol
17:45:57 <fantasai> sthe amount/the types of situations that hit this limitation/
17:46:07 <bramus> oriol: reminds me of align-content that non-normal establishes new BFC
17:46:13 <bramus> … do we want to be consistent with this?
17:46:35 <bramus> … about proposal: am concerned about leaving it open because complicatedness depends on the engine
17:46:58 <bramus> … would prefer to keep establishing BFC or something very straightforward as proposed.
17:47:13 <bramus> jensimmons: suggestion was not to keep it permanently vague, but to have progress on the spec
17:47:14 <astearns> ack fantasai
17:47:30 <bramus> fantasai: for the use cases where this prop is likely to be used overlaps a lot with floated content use cases
17:47:44 <bramus> … having the property have no effect on things that happen to be impacted by floated content
17:47:50 <bramus> … want to reduce the cases where that happens
17:48:03 <bramus> … important for this to work, so makes nsens to not establish BFC
17:48:16 <bramus> … issue with align-content is that author is explicit about what they want
17:48:20 <bramus> … (missed)
17:48:41 <bramus> … and dont want to change for align-content to flip BFC on or off depending on placement of content
17:48:48 <bramus> … cant make it conditional
17:48:54 <bramus> … for align-content needs BFC
17:48:57 <bramus> … for consistency
17:49:11 <bramus> … for this case here, seems fine to insert space the bottom when there is a complication
17:49:27 <bramus> oriol: concerned about leaving "a complication" vague
17:49:31 <bramus> … depends ont he engine
17:49:47 <bramus> fantasai: yes, will align on that later … lets figure it out in the in-between
17:50:10 <bramus> astearns: would you, oriol, be ok with resolving on that?
17:50:16 <bramus> oriol: not a fan of open ended things
17:50:17 <dbaron> The other factor is that this particular feature (step sizing) is designed in a way that it has to work reliably in order to be useful (having consistent rhythm).
17:50:39 <bramus> … i guess I can input/verify that ??? guess its fine to leave for later. not a fan though/
17:50:42 <fantasai> it's going to "work" consistency, it's just a question of do we insert the space above or below the item
17:51:13 <bramus> PROPOSED RESOLUTION not establish BFC with details on when the extra space gets added to the bottom only to be determined in future conversations
17:51:21 <bramus> astearns: are you ok with that ian?
17:51:30 <bramus> iank_: seems fine. hard constraint for me is no relayout.
17:51:40 <bramus> astearns: other comments/questions/objections?
17:51:56 <bramus> RESOLVED Do establish BFC for block-step-size with details on when the extra space gets added to the bottom only to be determined in future conversations
17:52:18 <bramus> RESOLVED: Do NOT establish BFC for block-step-size with details on when the extra space gets added to the bottom only to be determined in future conversations
17:52:47 <bramus> github-bot, take up https://github.com/w3c/csswg-drafts/issues/1902
17:52:47 <github-bot> Topic: [css-rhythm-1] Inherit block-step-size
17:52:47 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/1902.
17:53:07 <bramus> jensimmons: block-step is a shorthand for 4 longhands
17:53:16 <bramus> … see comment for details
17:53:39 <bramus> … there is an idea to have 5 longhands
17:53:49 <bramus> … to have block-step-size not set the increment
17:53:58 <bramus> … so they can turn it on/off for specific situations
17:54:04 <chrishtr> present+
17:54:10 <bramus> … discussed with elika that it reminds me of margin
17:54:12 <kizu> kizu has joined #css
17:54:16 <bramus> … you dont set it in one location and then turn it on
17:54:23 <bramus> … suggestion to close no change
17:54:31 <bramus> … do not need a separate property to turn it on or off
17:54:42 <flackr> present+
17:55:05 <flackr> I feel like usually you'd use a variable to pass it down if you wanted to do this
17:55:18 <bramus> astearns: trying to think of th euse case where you want to keep an inherited block-step length and turn that on or off dependin gon the context
17:55:25 <bramus> … are you, elika, ok with closing no change?
17:55:34 <bramus> fantasai: no strong opinion
17:55:46 <bramus> iank_: might want to split it off if ??? child
17:55:58 <bramus> … to see if the thing as a whole
17:56:12 <bramus> fantasai: to set it on the figure an dnot the figcaption
17:56:14 <bramus> iank_: or an article
17:56:22 <bramus> astearns: there you turn it off for the children
17:56:45 <bramus> … usecase needs to be that you set it on a parent but dont want a descendant to use it but do want its children to use
17:57:17 <bramus> … extra footgun of setting block-step-size and having it not happen seems more like a general case that we should be solving for
17:57:57 <bramus> fantasai: for comparison, now that we dropped the new BFC requirement, we could drop the none value in block-step-size with an initial value of 0
17:58:05 <bramus> … when you increase you get stepping
17:58:22 <bramus> … alt model is to be like text-box-trim where one prop sets the setting and another that turns it on and off
17:58:42 <bramus> … alt model where block-step-size inherits and you enable it on the boxes that need it
17:58:50 <bramus> … not convinced that that extra indireciotn is nessary
17:58:54 <bramus> … but have done it before
17:59:00 <bramus> s/nessary/necessary
17:59:25 <flackr> q+
17:59:25 <bramus> … cases where we did this are cases where you set a thing on a parent and cascade it individually
17:59:35 <astearns> ack flackr
17:59:46 <bramus> flackr: officially this seems like a use case for variables … to pass down values that are not applied
18:00:04 <bramus> … authors can use a variable if they want access to the value
18:00:32 <bramus> PROPOSED RESOLUTION: Close no change
18:00:35 <bramus> RESOLVED: Close no change
18:00:50 <bramus> topic: none
18:01:05 <bramus> astearns: next week breakout session on overflow
18:01:08 <bramus> … and then regular meeting
18:01:10 <bramus> … and then more
18:01:12 <bramus> … and then f2f
18:01:16 <emeyer> emeyer has left #css
18:01:20 <bramus> … see you all then
18:01:52 <fantasai> Please registere for the F2F! https://wiki.csswg.org/planning/cupertino-2025
18:01:54 <bramus> fantasai: and register for the F2F on the wiki!
18:03:09 <astearns> zakim, end meeting
18:03:09 <Zakim> As of this point the attendees have been rachelandrew, jensimmons, kbabbitt, stepheckles, kizu, alisonmaher, fantasai, ChrisL, bramus, dbaron, sgill, PaulG, keithamus, SebastianZ,
18:03:12 <Zakim> ... schenney, joshtumath, emilio, emeyer, castastrophe, oriol, jfkthame, TabAtkins, lea, bkardell_, miriam, chrishtr, flackr
18:03:12 <Zakim> RRSAgent, please draft minutes v2
18:03:13 <RRSAgent> I have made the request to generate https://www.w3.org/2025/01/15-css-minutes.html Zakim
18:03:20 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
18:03:20 <Zakim> Zakim has left #css
19:50:43 <dgrogan> dgrogan has joined #css
23:57:19 <tantek> tantek has joined #css