16:01:19 <RRSAgent> RRSAgent has joined #css
16:01:23 <RRSAgent> logging to https://www.w3.org/2026/03/05-css-irc
16:01:23 <Zakim> RRSAgent, make logs Public
16:01:24 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:01:44 <dbaron> Present+
16:01:59 <astearns> astearns has changed the topic to: form controls agenda: github.com/whatwg/html/issues/12179
16:02:23 <masonf> masonf has joined #css
16:02:45 <masonf> present+
16:02:52 <flackr> flackr has joined #css
16:04:18 <jarhar> jarhar has joined #css
16:05:21 <annevk> annevk has joined #css
16:05:37 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11869
16:05:38 <github-bot> Topic: [css-forms-1] Checkbox stylesheet missing indeterminate handling
16:05:38 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11869
16:05:57 <cwilso> present+
16:06:53 <jarhar> astearns: is this only about changing the character thats displayed for indeterminate?
16:07:11 <jarhar> lwarlow: yes, update the content property when its an indeterminate checkmark, and make sure visibility:hidden isnt set when its indeterminate
16:07:26 <masonf> q+
16:07:30 <jarhar> astearns: sounds good to me, we can also put it in the spec and then people can tell us were wrong
16:07:42 <jarhar> masonf: i think it looks great, just wanted to ask: is it grayed out when its indeterminate?
16:08:03 <jarhar> lwarlow: currently a mixed bag for what browsers do. they alll change the symbol. in chrome its the same color but changes the symbol
16:08:13 <jarhar> lwarlow: other browsers in certain states may do certain things
16:08:24 <jarhar> lwarlow: given the relative lack of color in base ui, change the symbol first and come up with other stuff
16:08:28 <jarhar> lwarlow: disabled state is shown based on that
16:08:32 <jarhar> masonf: +1 from me
16:09:19 <jarhar> proposed resolution: define styling for the indeterminate state that the content is visible and it turns into unicode 2500
16:09:24 <jarhar> RESOLVED: define styling for the indeterminate state that the content is visible and it turns into unicode 2500
16:09:33 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12490
16:09:33 <github-bot> Topic: [css-forms-1] Specify readonly input styles
16:09:33 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12490
16:10:01 <jarhar> lwarlow: currently theres no handling of the readonly state in the css forms spec
16:11:06 <chrishtr> chrishtr has joined #css
16:11:29 <jarhar> lwarlow: if people could think about what readonly should look like
16:11:37 <jarhar> lwarlow: perhaps they should just look like standard controls, perhaps like disabled
16:11:56 <jarhar> lwarlow: we just need to come to a consensus. if it applies in both cases, then we will add a note to the spec that this is deliberate
16:12:18 <jarhar> astearns: for this case, do you have an impression of whether its important that the user styling controls would allow you to achieve the various kinds of styling that we get in the different browsers?
16:12:33 <jarhar> lwarlow: basic css can achieve both of those, theres nothing special we need to introduce
16:12:46 <jarhar> lwarlow: we just need to decide on styles and think about the behavior of things
16:13:00 <jarhar> smaug: does this depend on the operating system? does something happen on macos vs windows?
16:13:09 <jarhar> lwarlow: readonly is a weird one since it doesnt apply to various inputs
16:13:16 <masonf> the HTML readonly attribute is ignored if the type is hidden, range, color, checkbox, radio, file, submit, reset, button, and image
16:13:26 <jarhar> lwarlow: i know it doesnt apply to select and a few other things, so theres weirdness around that side of things as well
16:13:52 <jarhar> lwarlow: i dont know that we want to change which ones it applies to. leaving it as-is is probably ok
16:14:17 <jarhar> annevk: whether it can be readonly seems like an html question. we should just decide how its going to be styles. whether its focusable or not, thats more of an os parity question
16:14:40 <jarhar> masonf: it probably shouldnt change that list - readonly doesnt change whether its focusable. its an a11y question, right? you want to focus it and see that its readonly??
16:15:06 <zcorpan> zcorpan has joined #css
16:15:06 <jarhar> annevk: also the focus outline is up to the ua so that we dont have to consider either for any other things
16:15:15 <jarhar> annevk: and the text caret, i dont know
16:15:28 <jarhar> annevk: is styling of text carets a thing? i think thats also up to the browser
16:15:41 <jarhar> lwarlow: you can change the color and animation
16:15:52 <jarhar> lwarlow: chrome also has caret shape
16:15:56 <astearns> https://drafts.csswg.org/css-ui-4/#the-insertion-caret
16:16:10 <jarhar> annevk: that should work but whether it shows in a readonly control or not, that doesnt seem like ... its an interesting question but out of scope
16:16:24 <jarhar> masonf: you said in the issue that chromium renders a text caret on windows, i just tried on mac and it doesnt
16:16:35 <jarhar> lwarlow: no i tried on mac
16:17:09 <jarhar> zcorpan: the mouse cursor turns into an i beam if you hover, but when you click theres no caret
16:17:19 <jarhar> masonf: the i beam is because you can still select/highlight
16:17:36 <jarhar> masonf: im in favor of leaving it as is because the behavior becomes clear when you try to type in it, you dont get a caret
16:17:41 <jarhar> lwarlow: im happy to resolve on that
16:17:50 <jarhar> lwarlow: we can revisit and come back to this if theres cases where browsers disagree
16:18:00 <jarhar> astearns: resolving then to close this issue no change?
16:18:01 <jarhar> lwarlow: yes
16:18:09 <jarhar> lwarlow: i might add a note to the spec, but normatively no change
16:18:22 <jarhar> masonf: css forms has no styling for the readonly state? then yeah i agree
16:18:34 <jarhar> proposed resolution: close this issue no change, can revisit if needed
16:18:39 <jarhar> RESOLVED: close this issue no change, can revisit if needed
16:18:45 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/13383
16:18:45 <github-bot> Topic: [css-forms-1] option hover/active styles inside of disabled select listbox
16:18:45 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13383
16:19:08 <jarhar> lwarlow: you can have a disabled select and still get hover/active styles on the options
16:19:27 <jarhar> lwarlow: it turns out that option elements get their enabled state from themselves and from parent optgroups, but not from the select element itself
16:19:46 <jarhar> lwarlow: one possible fix here is to add the enabled pseudo-class to the select inside of the styles and then it has to be an enabled select and an enabled option
16:20:01 <astearns> ack masonf
16:20:02 <jarhar> lwarlow: anne pointed out that this is wrong behavior to start with, and options should be disabled when sleect is disabled
16:20:07 <jarhar> lwarlow: does seem to apply to auto appearance
16:20:24 <jarhar> lwarlow: if you hold down on an option in a disabled listbox you get an active style as well
16:20:57 <jarhar> dbaron: i looked into this a few days ago because joey wrote a patch to do this styling, and my impression is that if we can make it so options inherit disabled state from select that would be nice and it seems to make sense
16:21:13 <jarhar> dbaron: the selectors you need to get this all correct combine with all of the weird specificity things you have
16:21:26 <jarhar> dbaron: getting styles for disabled options correct if you have to look at the select disabledness too is a huge mess
16:21:48 <jarhar> dbaron: maybe its not a huge mess if you rewrite all the styles for selects and options to have enabled/disabled, but if you dont do that then its bad, maybe theres a nicer way to write it
16:22:02 <jarhar> dbaron: looking at what the stylesheet looks like today, its not a small change
16:22:03 <jarhar> q+
16:22:07 <masonf> q+
16:22:17 <astearns> ack dbaron
16:22:17 <keithamus> q+
16:22:21 <astearns> ack jarhar
16:22:34 <masonf> jarhar: I posted a few issues about this. About making options disabled when their select is disabled.
16:22:45 <masonf> ...there are problems with the initial selection algorithm.
16:23:10 <masonf> ...in order to not break that, Anne suggested changing the selectors for the options to incorporate the ancestor select being disabled.
16:23:18 <masonf> ...but the other algorithms could still use the "old" disabled.
16:23:37 <jarhar> annevk: yeah we have locally disabled and globally disabled or something
16:23:47 <jarhar> masonf: and locally disabled is only used for this stylesheet?
16:24:11 <jarhar> annevk: other way around. locally just looks at optgropu and option as it does today. then we create a new one that look at the ancestor select in addition, and that one we use for enabled
16:24:15 <astearns> ack masonf
16:24:26 <jarhar> masonf: that was going to be my question for doing that for auto, i assume we dont want to do something different for auto vs base
16:24:33 <jarhar> annevk: what option you show is something we have to preserve
16:24:44 <jarhar> masonf: id be concerned about changing any selector on select matches because theres so many
16:24:46 <jarhar> q+
16:24:56 <dbaron> +1 to trying the global/local thing and changing what :enabled/:disabled do on options
16:24:58 <jarhar> lwarlow: this only applies to listboxes
16:25:36 <jarhar> dbaron: isnt it true that you cant see the options if the select is disabled and its a dropdown?
16:25:40 <jarhar> masonf: that makes me feel better
16:25:54 <astearns> ack keithamus
16:26:14 <jarhar> keithamus: you mentioned that options get their disbaled state from optgroups. im surprised. should we fix this for optgroups too?
16:26:37 <jarhar> keithamus: we could resolve two at once. options should look at their optgroup or select, and optgroups should look at select
16:26:38 <lwarlow> +1
16:26:42 <masonf> +1
16:26:50 <astearns> ack jarhar
16:27:06 <masonf> jarhar: to Mason's point about compat, I imagine it could affect existing appearance:auto UA styles, but we can probably fix it
16:27:19 <masonf> ...or we could add an internal pseudo class or something.
16:27:23 <dbaron> (it also might be that the changes are an improvement!)
16:27:41 <masonf> ...I don't remember how optgroup disabled works, but it probably doesn't do what we just discussed. But we could change it. SGTM
16:27:53 <jarhar> astearns: i did notice the PRs at the end of the issue
16:27:59 <jarhar> astearns: where is the spec with regards to this issue at the moment?
16:28:11 <masonf> annevk: nothing landed yet
16:29:09 <jarhar> proposed resolution: make the enabled and disabled pseudo-classes for options and optgroups look at their ancestor select, and keep other algorithms which look at option disabled-ness keep using the current "local" definition which doesn't look at the ancestor select for compat reasons
16:29:47 <lwarlow> +1
16:30:22 <dbaron> +1
16:30:37 <masonf> +1
16:30:38 <keithamus> +1
16:31:14 <jarhar> astearns: so these algoriths are not exposed to css?
16:31:18 <jarhar> jarhar: correct
16:31:47 <jarhar> astearns: im concerned that we would have two different answers to the question is this option disabled depending on how you approach getting your answer
16:31:53 <jarhar> astearns: if you get it from the pseudo, sure its disabled
16:32:04 <jarhar> astearns: but if you use this js mechanism to determine which option to be checked, then its not disabled
16:32:07 <zcorpan> https://html.spec.whatwg.org/#selector-disabled
16:32:11 <jarhar> astearns: having two answers seems like a code smell to me
16:32:17 <jarhar> keithamus: the presence of the attribute is another thing
16:32:24 <jarhar> keithamus: from developer perspective theres nuance here
16:32:37 <jarhar> keithamus: in css if you use an attribute selector instead of a pseudo selector you get different answers
16:32:46 <jarhar> annevk: is there a js api?
16:33:06 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/05-css-minutes.html fantasai
16:33:13 <jarhar> lwarlow: it changes the algorithm of which option is selected by default, thats a js way you could detect the difference
16:33:14 <jarhar> annevk: there is a lot of callers for disabled
16:33:31 <jarhar> masonf: the point of alans question is whether theres an easy js way to check this
16:33:37 <jarhar> lwarlow: options have a disabled property
16:33:40 <jarhar> annevk: that reflects the attribute
16:33:50 <jarhar> masonf: that could be a source of confusion
16:33:59 <jarhar> annevk: it already is because of optgroup
16:34:23 <jarhar> zcorpan: im not sure we should change optgroup. the html spec doesnt have the disabled state for optgroup. theres the disabled attribute, but the disabled state doesnt apply to optgroup itself
16:34:34 <jarhar> annevk: presumably the enabled pseudo class does apply right?
16:34:40 <jarhar> zcorpan: yes, but it looks at the attribute instead of the state
16:34:50 <jarhar> annevk: it doesnt have the disabled state because nothing else uses it
16:35:10 <jarhar> keithamus: it seems confusing to me that you could query for enabled and youd get optgroup in a disabled select
16:35:21 <jarhar> keithamus: and you wouldnt get any of the options
16:35:29 <jarhar> zcorpan: i dont disagree, its strange. im not sure its worth fixing
16:35:38 <jarhar> zcorpan: and risking web compat
16:35:44 <jarhar> annevk: for optgroup theres less risk than option
16:36:10 <jarhar> keithamus: its also whether the spec has a concept for disabled. certainly in firefox it has disabled. it has something that is disparate from select
16:36:30 <jarhar> lwarlow: go with the proposed resolution and come back if theres compat issues?
16:36:35 <jarhar> +1
16:36:53 <masonf> q+
16:36:59 <astearns> ack masonf
16:37:04 <jarhar> lwarlow: if i get the compat concerns id balance them against wanting base appearance to have a sane set of behaviors. like keith mentioned, if you look for enabled descendants and you get optgroups thats pretty weird
16:37:24 <jarhar> masonf: would it reduce the chance of breakage if you change disabled to reflect this as well? option.disabled would return true if its parent
16:37:26 <jarhar> q+
16:37:36 <jarhar> lwarlow: from my perspective thats riskier
16:37:45 <jarhar> lwarlow: disabled is already a reflection than actually reflecting the internal state
16:37:46 <dbaron> I agree with Luke that it sounds riskier.
16:37:58 <jarhar> lwarlow: i would be fine, it makes sense
16:38:01 <jarhar> astearns: we could make it separately
16:38:12 <astearns> ack jarhar
16:38:18 <dbaron> (I think it makes sense for .disabled to continue to be attribute reflection, so I don't think it makes sense...)
16:38:31 <masonf> jarhar: I also don't like changing the disabled IDL, because it's writable. What happens if you set it to true on an inherited disabled option.
16:38:32 <zcorpan> q+
16:38:34 <masonf> ...it should stay.
16:38:37 <stevenspriggs> stevenspriggs has joined #css
16:38:38 <masonf> masonf: that's a good point
16:38:39 <astearns> ack Zakim
16:38:43 <astearns> ack zcorpan
16:38:47 <jarhar> zcorpan: if theres use case for reading the actual state like actually disabled
16:38:48 <jarhar> q+
16:38:53 <jarhar> zcorpan: disabled for real
16:38:54 <masonf> .actuallyDisabledV2
16:38:55 <lwarlow> Fwiw that would be fine you'd just do [ReflectSetter] and then a custom getter if we did want to do that
16:39:17 <masonf> jarhar: {missed, sorry}
16:39:23 <jarhar> keithamus: its also not the first thing we have to use matches to query something. for popover you have to use matches
16:39:40 <jarhar> astearns: anne, are you convined that we can change optgroup?
16:39:43 <jarhar> annevk: i think we should do both
16:39:52 <jarhar> proposed resolution: make the enabled and disabled pseudo-classes for options and optgroups look at their ancestor select, and keep other algorithms which look at option disabled-ness keep using the current "local" definition which doesn't look at the ancestor select for compat reasons
16:39:58 <masonf> +1
16:40:00 <lwarlow> +1
16:40:01 <dbaron> +1
16:40:05 <zcorpan> +1
16:40:08 <jarhar> RESOLVED: make the enabled and disabled pseudo-classes for options and optgroups look at their ancestor select, and keep other algorithms which look at option disabled-ness keep using the current "local" definition which doesn't look at the ancestor select for compat reasons
16:40:25 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/13527
16:40:25 <github-bot> Topic: [css-forms-1] Find a way to avoid double border between ::picker() and button
16:40:25 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13527
16:40:40 <lwarlow> 1+
16:40:43 <lwarlow> q+
16:40:50 <jarhar> q-
16:42:40 <jarhar> fantasai: we were thinking that the thing that probably makes the most sense is an anchor positioning feature that has been resolved on but hasnt made it into the spec yet which tells which box you want to anchor to. default is border box, for a select it might make sense to anchor it to the padding edge in the block axis so that looks like the
16:42:41 <jarhar> picker menu is actually coming from the ?? that was the idea
16:42:57 <jarhar> fantasai: the downside of that is that there are some designs that want it to look outside to outside
16:43:05 <jarhar> masonf: that is a new property?
16:43:09 <jarhar> fantasai: yes, position-anchor-box i think
16:43:14 <jarhar> fantasai: alternative is to put -1 margin on it
16:43:15 <masonf> q+
16:43:20 <jarhar> fantasai: which would overlap the 1px border
16:43:33 <astearns> ack lwarlow
16:43:48 <jarhar> lwarlow: margin -1 i think would be a massive code smell for base appearance. you shouldnt need to do that kind of margin hack in the base styles
16:43:57 <jarhar> lwarlow: ideally we should be setting properties that we need to set, but we shouldnt set more than that
16:44:02 <jarhar> lwarlow: margin -1 feels slightly weird
16:44:10 <jarhar> lwarlow: the other thing with changing to the padding box would be better
16:44:14 <jarhar> lwarlow: it looks less weird
16:44:20 <jarhar> lwarlow: i will say that would break my existing select
16:44:42 <jarhar> lwarlow: the picker has its top border set to 0 width, and if you change it to anchor against the padding box that will overlap with the buttons border such that there will be no border
16:44:49 <jarhar> astearns: the padding box could be overriden in your case
16:45:01 <jarhar> lwarlow: yes but it doesnt at the moment and it works in production, thats the point - it could break designs
16:45:11 <jarhar> lwarlow: i suspect that design does exist in the wild already, but probalby not too much
16:45:14 <jarhar> lwarlow: thats worth being aware
16:45:16 <astearns> q+
16:45:43 <jarhar> lwarlow: with the proposed change from openui, where potentially select wont have a border radius, i guess this issue still occurs, but is it less bad?
16:45:52 <jarhar> lwarlow: you still end up with the double border
16:45:54 <astearns> ack masonf
16:46:12 <jarhar> masonf: we did resolve to remove border radius last week. we also resolved to add an issue to a non weird looking criteria to the design principles
16:46:22 <jarhar> masonf: its fully functional, it just looks weird to most people
16:46:32 <jarhar> masonf: we should just prefer fewer rules to more rules. each rule is a thing for a developer to go undo
16:46:43 <jarhar> masonf: personally i think that if somebody puts out a reset stylesheet for base appearnace then its a failure on us
16:46:50 <jarhar> masonf: it should be minimal enough that its a reset
16:47:07 <keithamus> q+
16:47:13 <jarhar> masonf: here, if the fix for this is to use a new property that doesnt even exist yet, that feels even worse, the reset sheet is growing
16:47:28 <jarhar> masonf: if theres a change that can be made in the existing set of properties, maybe thats better, but then i worry about compat as luke mentioned
16:47:41 <jarhar> masonf: primarily my objection is the growth of the ua stylesheet
16:47:55 <jarhar> astearns: i agree with luke, having a -1 hack to solve this doesnt sound right
16:48:09 <jarhar> astearns: contra masons concerns about keeping things simple, the proper way to do that would be have a variable
16:48:23 <jarhar> astearns: do we have css variables in the ua stylesheet? should we never put them in there?
16:48:24 <jarhar> fantasai: yes
16:48:50 <jarhar> zcorpan: variable doesnt solve the problem - if the author sets the border to zero, you still have a mismatch even if the ua stylesheet has a variable
16:48:56 <jarhar> masonf: unless the devleoper could change the variable
16:49:07 <astearns> ack astearns
16:49:09 <astearns> ack keithamus
16:49:30 <jarhar> keithamus: i wonder if theres a more generalized way to solve this, and i think designers often come to these issues with segmented buttons where they want buttons in between buttons to not have borders
16:49:42 <lwarlow> They're custom properties as well not variables ;) so the UA property is just a property.
16:49:42 <jarhar> keithamus: could css have a border collapse? these two elements, if there adjacent, one of their borders should collapse
16:49:50 <jarhar> keithamus: probably a wild idea, but it would have utility beyond select
16:49:57 <jarhar> fantasai: i think what you want is position-anchor-box
16:50:09 <jarhar> fantasai: not true in the general case where you ahve a sibling relationship, tables do border collapsing
16:50:29 <jarhar> fantasai: in this case theres not a parallel relationship, its dependent. you want to overlap the anchors border then you should anchor to its box
16:50:47 <jarhar> astearns: i agree that seems to be the ideal mechanism, but it isnt implemnented and not even specced yet, so i worry about relying on that
16:51:04 <jarhar> astearns: even though we are going to have a principle about not being weird, thats just one principle to balance against the rest
16:51:06 <masonf> q+
16:51:29 <jarhar> astearns: it might be minimal enough that we decide to elave the double border as weird until we get this anchor positioning mechanism widely supported, and then look at changing the ua stylesheet
16:51:35 <keithamus> q+
16:51:38 <astearns> ack masonf
16:51:49 <jarhar> masonf: we havent decided to add a non weird thing, we opened an issue to discuss which i will be against
16:52:00 <jarhar> masonf: keep the web weird, i dont think that should be a criteria
16:52:06 <lwarlow> The longer we leave it the larger the compat issue is worth being aware of.
16:52:13 <jarhar> masonf: what you said is right, this property doesnt exist yet
16:52:23 <jarhar> masonf: developers who think this looks weird can use the property
16:52:41 <jarhar> masonf: as we add new stuff to the web, devleopers can use it
16:52:50 <jarhar> masonf: you can use it on customizable select but you dont have to break the web
16:52:51 <lwarlow> +1
16:52:52 <zcorpan> q+
16:52:53 <astearns> ack keithamus
16:53:31 <jarhar> keithamus: regarding adding the feature later, luke you said that something would break? if were saying we can do this eventually that becomes more of a problem as implementations start to ship
16:53:36 <astearns> ack Zakim
16:53:39 <astearns> ack zcorpan
16:53:52 <jarhar> zcorpan: the double border probably only looks weird when the borders have the same color. if they are different, then maybe the opposite looks weirder
16:53:58 <masonf> I think the black border looks weird. It should be hotpink.
16:53:58 <jarhar> q+
16:54:16 <astearns> ack jarhar
16:54:35 <masonf> jarhar: those two borders technically have different colors. The select element inherits its color, and the picker sets CanvasText. They happen to be the same.
16:54:47 <lwarlow> Maybe we can resolve no change?
16:54:51 <masonf> +1
16:54:56 <zcorpan> +1
16:55:04 <jarhar> fantasai: we can come back to this when anchor box stuff is specced
16:55:14 <lwarlow> A can kick is a no change for now at least I guess
16:55:20 <jarhar> astearns: as keith mentioned, we may not be able to use the new thing depending on how long this sticks around
16:55:36 <jarhar> masonf: we should open an issue for changing the ua stylesheet over time when new stuff is added
16:55:45 <jarhar> astearns: we already have a basic principle of not breaking the web and consider bakcwards compat
16:56:00 <jarhar> astearns: in a case by case basis, there may be a way to update base styles that doesnt have compat concerns
16:56:17 <jarhar> proposed resolution: close this no change for now
16:56:19 <masonf> +1
16:56:30 <jarhar> fantasai: ill take that back to the team and look at speccing stuff we had decided a couple years ago
16:56:37 <jarhar> astearns: this anchor thing has been waiting for that long?
16:56:45 <lwarlow> +1
16:56:49 <jarhar> RESOLVED: close this no change for now
16:57:15 <jarhar> annevk: maybe lets not resolve on that for now, we want to check back with the team
16:57:39 <jarhar> proposed resolution: strike that and just leave the issue as-is for now
16:57:42 <lwarlow> +1
16:58:06 <keithamus> +1
16:58:08 <jarhar> RESOLVED: strike that and just leave the issue as-is for now
16:58:56 <masonf> proposed resolution: cancel daylight savings globally
16:59:29 <dgrogan> dgrogan has joined #css
17:01:26 <jamesn> jamesn has joined #css
17:03:12 <morgan> morgan has joined #css
17:05:32 <astearns> topic: end
17:05:32 <astearns> zakim, end meeting
17:05:32 <Zakim> As of this point the attendees have been dbaron, masonf, cwilso
17:05:33 <Zakim> RRSAgent, please draft minutes v2
17:05:34 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/05-css-minutes.html Zakim
17:05:40 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
17:05:41 <Zakim> Zakim has left #css
17:33:21 <jcraig> jcraig has joined #css
18:03:15 <Adam_Page> Adam_Page has joined #css