17:00:17 <RRSAgent> RRSAgent has joined #css
17:00:17 <RRSAgent> logging to https://www.w3.org/2021/11/17-css-irc
17:00:19 <Zakim> RRSAgent, make logs Public
17:00:20 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
17:00:24 <chris> present+
17:00:35 <argyle> present+
17:00:36 <dholbert> (I'll be silent for 10-15min; driving home from daycare drop-off)
17:01:21 <smfr> smfr has joined #css
17:01:35 <dino> dino has joined #css
17:01:47 <dlibby> dlibby has joined #css
17:01:49 <TYLin> TYLin has joined #css
17:01:55 <r12a> r12a has joined #css
17:02:11 <jfkthame> present+
17:02:13 <dlibby> present+
17:02:23 <tantek> tantek has joined #css
17:02:24 <dandclark> present+
17:02:41 <fantasai> ScribeNick: fantasai
17:02:45 <smfr> present+
17:03:58 <fantasai> Topic: Meeting Scheduling
17:04:08 <fantasai> astearns: Cancelled meeting next week and last 2 weeks of December
17:04:10 <tantek> present+
17:04:12 <fantasai> astearns: due to holidays
17:04:15 <TYLin> present+
17:04:19 <fantasai> astearns: but we have a lot of Agenda+ items
17:04:26 <fantasai> astearns: so maybe want to add extra meeting time
17:04:34 <lea> lea has joined #css
17:04:37 <fantasai> astearns: could add extra time in December, or in January
17:04:45 <fantasai> astearns: Please let me know if any preferences on this
17:04:46 <jensimmons> jensimmons has joined #css
17:04:53 <fantasai> astearns: or if there's a set of topics for a breakout session
17:05:09 <jensimmons> present+
17:05:10 <fantasai> astearns: so far, topics seem mostly mixed, but open to suggestions
17:05:13 <GameMaker> GameMaker has joined #css
17:05:13 <lea> present+
17:05:17 <GameMaker> present+
17:05:53 <fantasai> fantasai: My suggestion would be to extend Dec 8th into a vF2F
17:06:06 <fantasai> fantasai: well after Thanksgiving and well before Christmas, and avoids topics dragging into January
17:06:25 <fantasai> Topic: Local Font Access Limitations
17:06:35 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/4497
17:07:17 <fantasai> astearns: Topic is about local fonts needed for i18n particularly
17:07:24 <fantasai> [side discussion about positioning of Agenda Item 9]
17:07:41 <fantasai> smfr: Myles isn't here
17:07:58 <fantasai> s/here/here, probably should be here/
17:08:17 <fantasai> astearns: Other browsers than Safari probably need to sign on for whatever local font access we decide on here
17:08:22 <fantasai> s/here/here also/
17:08:30 <fantasai> chris: It would be good to get some movement on this.
17:08:39 <fantasai> chris: Felipe made a good suggestion, and thumbs up in thread
17:08:47 <fantasai> chris: Richard confirmed he liked the suggestion
17:09:00 <fantasai> chris: Maybe we can resolve to accept the suggestion, and then work out the details in the spec
17:09:04 <fantasai> chris: The general principle seems sound
17:09:23 <fantasai> Felipe's suggestion at https://github.com/w3c/csswg-drafts/issues/4497#issuecomment-763459971
17:09:53 <fantasai> astearns: Summary is having some sort of permission interface, where if a web page tries to use a local font and browser notices local font is in system, UI would come up
17:09:59 <fantasai> astearns: timed to make fingerprinting more difficult
17:10:04 <jfkthame> q+
17:10:08 <fantasai> astearns: allows user to enable font access
17:10:11 <smfr> q+
17:10:21 <fantasai> r12a: Then can have a checkbox for "don't ask me about this font again"
17:10:26 <chris> q+
17:10:27 <fantasai> jfkthame: Interested in Gecko
17:10:31 <astearns> ack jfkthame
17:10:38 <fantasai> jfkthame: Doing some foundational work towards potentially restricting font access
17:10:54 <fantasai> jfkthame: One aspect not directly talked about, seems there are several senses in which a website could want to use a locally-installed font
17:10:59 <fantasai> jfkthame: worth highlighting the distinction
17:11:05 <fantasai> jfkthame: might be font name is given in font-family property
17:11:28 <fantasai> jfkthame: so that specific font family is specifically requested, and page would like to use, and might or might not be allowed
17:11:39 <fantasai> jfkthame: But what about font fallback? Character that is not in other fonts
17:11:49 <fantasai> jfkthame: Would that trigger requests like this?
17:12:06 <fantasai> jfkthame: Should there be a user request for fallback, when the character is not available in other fonts?
17:12:09 <chris> qq+ to answer
17:12:13 <fantasai> jfkthame: I think the fingerprinting implications are different
17:12:27 <fantasai> jfkthame: I think for fallback, I think it's particularly concerning for minority languages
17:12:35 <astearns> ack chris
17:12:35 <Zakim> chris, you wanted to react to jfkthame to answer
17:12:40 <fantasai> jfkthame: For such users, any font that supports the language would be helpful
17:12:55 <fantasai> chris: For fallback case, script can know that fallback was used, but doesn't know which one
17:13:09 <fantasai> chris: so imo shouldn't require a user permissions font
17:13:17 <astearns> ack smfr
17:13:22 <fantasai> jfkthame: well, you are exposing the fact that the user has *a* font that supports these characters
17:13:32 <fantasai> smfr: In general, we don't believe permission prompts are useful solution to this kind of problem
17:13:43 <fantasai> smfr: one reason is user fatigue; users don't read the dialog, just want it out of the way
17:13:56 <fantasai> smfr: Then it's really impossible to explain to users what fingerprinting means and implications
17:13:57 <r12a> q+
17:14:03 <fantasai> smfr: ....
17:14:15 <fantasai> smfr: Then users don't understand whether web page or browseris showing the dialog
17:14:26 <fantasai> smfr: long-term approach should be that system fonts have support for these minority languages
17:14:34 <fantasai> smfr: so that we don't need to run into this problem in the first place
17:14:38 <astearns> ack chris
17:14:41 <tantek> +1 smfr, permission prompts are not a reasonable answer to this (users can't be expected to make informed consent)
17:15:03 <dholbert_> dholbert_ has joined #css
17:15:04 <fantasai> chris: the page gets laid out without the font, the dialog box pops up asking permission to allow this, so that next time come to that site (per origin) not bothered by it
17:15:17 <fantasai> chris: so rapidly not going to run into this problem
17:15:47 <astearns> ack chris
17:15:55 <fantasai> chris: a font on system that covers the charset vs specific font that gives the right design is different
17:15:58 <fantasai> chris: ....
17:16:14 <fantasai> r12a: There is somewhere a long post on one of these issues where I addressed the question of system fonts being able to display the text
17:16:32 <fantasai> r12a: there are certain scripts and orthographies where not only does it not look good, but it actually causes problems in representing semantics
17:16:50 <fantasai> r12a: Might end up with wrong kind of glyphs, doesn't look the way you expect as a user of tye script
17:16:55 <fantasai> r12a: Don't see any way to rely on system fonts here
17:16:59 <chris> suspect r12a is referring to this: https://github.com/w3c/csswg-drafts/issues/4497#issuecomment-594521142
17:17:08 <fantasai> r12a: Also people like font designers have a problem, they can't check their fonts if they can't see them
17:17:15 <chris> with Western Syriac example
17:17:16 <fantasai> r12a: Noto fonts are not a panacea
17:17:23 <fantasai> r12a: They are often in need of significant repair to do the job
17:17:30 <fantasai> r12a: Sometimes missing for certain minority scripts
17:17:38 <fantasai> r12a: Not coverage of characters, sometimes not the right glyph shapes
17:17:45 <fantasai> r12a: A dialog box in front of the user is not great
17:17:53 <fantasai> r12a: But it's better than not being able to get the font that you want
17:17:58 <fantasai> r12a: I couldn't think of any better solution to it
17:18:09 <fantasai> r12a: It will probably help if we have the ability to say "don't remind me, about this particular font"
17:18:13 <fantasai> r12a: I don't think there's a good solution here
17:18:24 <fantasai> r12a: If you're creating web pages, you are checking your page using localhost
17:18:31 <fantasai> r12a: and in that situation, there's not going to be any phishing
17:18:39 <miriam> present+
17:18:43 <fantasai> r12a: major pain in the butt if you can't spin up the page with the font you'd like to see
17:18:46 <chris> localhost is just one example of an origin
17:18:57 <fantasai> r12a: So I'd like to argue that if you're working on localhost, then that should not prevent you from seeing fonts
17:19:18 <fantasai> astearns: My current take is that we're not ready to resolve on anything
17:19:27 <fantasai> astearns: but encouraged by the fact that Gecko is interested in figuring out
17:19:36 <fantasai> astearns: Sounds to me that there are some valid concerns about permission interfaces
17:19:43 <fantasai> astearns: but also valid concerns about not doing anything and just relying on system fonts
17:19:56 <fantasai> astearns: so I hope that people engage on the issue, because this is something that we need to solive
17:20:32 <fantasai> astearns: Thanks, r12a, for joining us
17:20:55 <fantasai> Topic: [css-cascade] When an import rule fails to load or has an unsatisfied condition, does the layer still count?
17:21:00 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6776
17:21:18 <fantasai> miriam: A few questions in here
17:21:28 <fantasai> miriam: All related to establishing layers inside of an @import statement.
17:21:38 <fantasai> miriam: One question is what to do if the import fails
17:21:48 <fantasai> miriam: other question is what to do if the conditions of the import don't match
17:21:59 <emilio> present+
17:22:13 <fantasai> miriam: consensus in the thread was that we should conceptualize this to "layer is wrapped around contents of the import, even if empty due to failure, and condition is wrapped around the whole thing"
17:22:19 <fantasai> miriam: We added language to spec to express it that way
17:22:25 <fantasai> miriam: layer is still added to layer order if import fails
17:22:29 <fantasai> miriam: but not added if the conditions don't match
17:22:39 <fantasai> miriam: that matches the behavior of if you had import inside of layer inside of condition
17:22:44 <fantasai> miriam: wanted to check with WG if this is acceptable
17:22:58 <fantasai> jensimmons: Makes a lot of sense from authoring point of view
17:23:09 <fantasai> +1 from me
17:23:57 <fantasai> RESOLVED: Accept proposal
17:24:18 <fantasai> miriam: This allows us to republish
17:24:27 <fantasai> RESOLVED: Republish css-cascade-5
17:24:32 <fantasai> Topic: [css-values] define parse-time value aliasing
17:24:37 <r12a> r12a has left #css
17:24:47 <chris> miriam: is the changes section up to date?
17:25:00 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6193
17:25:09 <emilio> scribenick: emilio
17:26:30 <fantasai> fantasai: Added value aliasing section to cascade-4/5
17:26:35 <fantasai> emilio: Weird that it is scoped to keywords
17:26:53 <fantasai> fantasai: We didn't see any examples of not keywords, but could certainly reword to be more general
17:26:58 <emilio> emilio `-webkit-image-set()`-> `image-set()`
17:27:06 <chris_> chris_ has joined #css
17:27:09 <emilio> Same with a bunch of gradient functions
17:27:14 <chris_> rrsagent, here
17:27:14 <RRSAgent> See https://www.w3.org/2021/11/17-css-irc#T17-27-14
17:27:20 <fantasai> fantasai: So functions and keywords, anything else?
17:27:28 <fantasai> s/scribenick: emilio//
17:27:33 <emilio> I don't _think_ so of the top of my head
17:27:48 <fantasai> astearns: So proposed to take edits, with additional change to add functions
17:27:54 <fantasai> fantasai: sgtm
17:27:59 <emilio> emilio: sgtm
17:28:16 <fantasai> RESOLVED: Accept edits, expand to allow aliased functions
17:28:17 <bradk> bradk has joined #css
17:28:35 <fantasai> Topic: [css-values-4] Clarify that function component values need to be followed by parentheses
17:28:40 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/5728
17:29:19 <bradk> present+
17:29:25 <oriol> oriol has joined #css
17:29:36 <emilio> fantasai: So tab added bikeshed functionality in which he can link to a function definition using `<ident()>`
17:29:55 <emilio> fantasai: but this is not actually valid according to our value definition grammar
17:29:57 <fantasai> <'property-name'>
17:30:01 <fantasai> <keyword>
17:30:08 <emilio> ... that has quoted property references and terminal kws (^)
17:30:22 <emilio> ... so should we add this to the value-definition grammar and update all specs to use this convention?
17:30:39 <emilio> ... a subtle thing is that only terminals that represent a function will use this
17:30:53 <emilio> ... historically we haven't done this, e.g., `<url>`
17:31:08 <emilio> ... so the question is do we want to extend our syntax in this way
17:31:49 <fantasai> chris_: I would find this useful, have needed <foo> vs <foo()>
17:32:37 <fantasai> astearns: So proposal is to add <name()> to our grammar
17:32:43 <fantasai> s/grammar/grammar for specs/
17:33:07 <fantasai> astearns: Will that require going back and fixing everything?
17:33:16 <fantasai> fantasai: I think it would be useful to make things consistent
17:33:23 <fantasai> fantasai: but I wouldn't do it for <url>
17:33:36 <fantasai> astearns: If not required, it's better; would prefer not to mess with old things
17:33:39 <fantasai> astearns: Any other opinions?
17:33:46 <fantasai> RESOLVED: Add this to the Value Definition Grammar
17:34:04 <fantasai> Topic: [css-position] Behaviour of semi-replaced elements.
17:34:12 <fantasai> github: css-position] Behaviour of semi-replaced elements.
17:34:18 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6789
17:34:32 <fantasai> iank_: After last week's meeting dholbert did an in-depth investigation, which was great to see
17:34:39 <dbaron> dbaron has joined #css
17:34:41 <fantasai> iank_: test page with a whole bunch of replaced elements, and looked at behavior
17:34:46 <dbaron> Present+
17:34:55 <fantasai> iank_: we both agreed that it's probably reasonable to stretch in both directions for all semi-replaced elements
17:35:05 <fantasai> iank_: There's no browser which does something consistently, so every browser would need to change
17:35:11 <fantasai> iank_: but this is a straighforward path forward
17:35:27 <fantasai> dholbert_: Every form control is stretched in at least one browser
17:35:36 <fantasai> dholbert_: but not every form control is shrunk in at least browser
17:35:42 <fantasai> iank_: e.g. we stretch in block direction but not inline
17:35:53 <fantasai> iank_: webkit and FF together have complete coverage of stretching in inline direction
17:36:02 <fantasai> astearns: change is to stretch in both directions in all browsers eventually?
17:36:03 <fantasai> iank_: correct
17:36:07 <fantasai> astearns: any other opinions?
17:36:17 <fantasai> fantasai: Tab and I are in favor of this
17:36:46 <fantasai> RESOLVED: Semi-replaced elements stretch in both directions in abspos
17:36:59 <fantasai> iank_: We'll likely make this change in the next few months, and will report back if any web-compat concerns
17:37:30 <fantasai> astearns: Thanks, dholbert_, for your investigation
17:37:43 <fantasai> Topic: Transforms and backgrounds on root element
17:37:48 <fantasai> github:
17:37:48 <fantasai> 6.
17:37:55 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6683
17:37:58 <fantasai> s/6.//
17:38:18 <fantasai> dbaron: obscure passage in the spec, wrote a test for it, and ended up wondering if we really want spec to say this in the first place
17:38:24 <fantasai> dbaron: [quote spec]
17:39:02 <fantasai> dbaron: basically, this is describing a special behavior for fixed backgrounds on root element, saying that transforms apply to that fixed background
17:39:13 <fantasai> dbaron: interesting because normal rules for background on root element say that backgrounds get propagated to canvas
17:39:26 <fantasai> dbaron: and backgrounds on canvas, nothing says anywhere that they are affected by transforms
17:39:39 <fantasai> dbaron: so if you read between lines in spec, I think what it says is that non-fixed background are not affected by transforms
17:39:47 <fantasai> dbaron: could probably make other arguments, though
17:39:58 <dholbert> dholbert has joined #css
17:40:06 <fantasai> dbaron: What I think the spec is saying is that fixed backgrounds are affected by transforms, and scrolled backgrounds are not affected by transforms
17:40:15 <fantasai> dbaron: what my tests found, is that in chromium do the exact opposite
17:40:23 <fantasai> dbaron: i.e. fixed background not affected, but scrolled backgrounds are
17:40:28 <fantasai> dbaron: in Gecko neither is affected by transform
17:40:36 <fantasai> dbaron: and in WebKit both kinds are affected by transform
17:40:41 <fantasai> dbaron: So 4 possible behaviors
17:40:49 <fantasai> dbaron: and every browser fits into a different possible behavior
17:40:52 <dholbert> as a see-also, we have https://bugzilla.mozilla.org/show_bug.cgi?id=1724471 filed on some WPT tests failing due to Gecko's behavior here
17:40:54 <fantasai> dbaron: It's not clear to me we want what the spec says
17:41:04 <fantasai> dbaron: I wanted to see if anyone has an opinion here
17:41:19 <fantasai> smfr: Don't have a clear memory about why spec is the way it is, might have been ease of implementation
17:41:25 <fantasai> smfr: we do special thinks for fixed backgrounds
17:41:44 <fantasai> smfr: but I would expect that it would have been easiest to *not* apply transforms for fiexd backgrounds
17:41:48 <fantasai> smfr: so I'm pretty confused
17:42:04 <astearns> ack RRSAgent
17:42:13 <astearns> ack r12a
17:42:25 <fantasai> dholbert: [...]
17:42:46 <fantasai> fantasai: So what do authors expect to happen here?
17:42:53 <fantasai> dbaron: part of what I was wondering
17:43:42 <fantasai> fantasai: so canvas is infinite...
17:43:53 <fantasai> smfr: Think about rotate(45deg); does the background rotate?
17:44:06 <fantasai> dbaron: Unsure anyone cares here, so maybe do the easy thing?
17:44:10 <fantasai> dbaron: so not apply transform
17:44:27 <fantasai> smfr: So if author wanted background to move around, they could put it on body and prevent propagation with different style on the root
17:44:31 <fantasai> smfr: and then transform the body
17:44:35 <fantasai> dbaron: might not cover the same area though
17:44:52 <fantasai> smfr: What happens to gaps revealed by e.g. rotating 45deg?
17:44:59 <fantasai> smfr: are they filled, or ...?
17:45:04 <fantasai> dbaron: WebKit has some bugs around that
17:45:26 <fantasai> astearns: Anyone looked to see if any bugs filed against engines on this?
17:45:30 <fantasai> smfr: don't recall any for WebKit
17:45:38 <fantasai> dbaron: I feel like this is a combination that nobody actually cares about
17:46:00 <fantasai> astearns: so suggestion of never honoring transform, is that ok smfr?
17:46:19 <fantasai> smfr: My concern there is, naively, if root gets transformed, whether background is transformed with it depends on details of impl
17:46:37 <fantasai> smfr: if we end up with behavior change, might force us to do additional work to handle
17:46:47 <fantasai> smfr: I'm OK resolving bg never gets transformed, and if hard, we can revisit
17:46:56 <fantasai> astearns: so chrome would need to change also
17:47:07 <fantasai> dbaron: haven't looked into what's needed for that, but I'm OK looking into it
17:47:30 <fantasai> astearns: proposed that we change spec to say that background on root element are not affected by transforms
17:47:39 <fantasai> dbaron: I think current spec is unclear about scrolled backgrounds
17:47:51 <fantasai> dbaron: you have to infer based on propagation rules
17:48:00 <fantasai> smfr: we've talked about effects of filters on root element in the past
17:48:13 <fantasai> smfr: Chris came up with a proposal for rendering model that allows filters to affect root background
17:48:20 <fantasai> smfr: so maybe review that and see if any of it applies to transforms
17:48:26 <fantasai> dbaron: ok, so let's come back to this later
17:48:41 <fantasai> astearns: so let's review filters and come back to this later
17:48:52 <fantasai> Topic: [css-fonts] @font-face src: url() format() keywords vs. strings ambiguous in spec
17:48:59 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6328
17:49:40 <fantasai> chris_: Grammar here is complicated due to allowing strings and keywords
17:49:45 <fantasai> chris_: but most compatible form is string
17:49:52 <fantasai> chris_: so we should support string and serialize as string
17:50:15 <fantasai> astearns: do we want to accept keywords as well?
17:50:58 <fantasai> fantasai: let's split into 2 questions, first is resolving on serializing as strings because they are the most backwards-compatible syntax
17:51:22 <fantasai> astearns: does drott have any concerns?
17:51:26 <fantasai> ...
17:51:33 <fantasai> astearns: most backwards-compat usually winning argument
17:51:55 <fantasai> RESOLVED: format() serializes with strings
17:52:20 <fantasai> jfkthame: What are we intending to do with font-technology(), will that take keywords or strings, and will that be confusing?
17:52:35 <fantasai> chris_: That will take keywords as currently specced. Though that can change.
17:52:57 <fantasai> chris_: There's no back-compat concern with technology()
17:53:18 <fantasai> astearns: Since we have back-compat issue with one, maybe all of them should serialize as strings
17:53:32 <fantasai> jfkthame: I'm not sure what I favor
17:53:38 <fantasai> jfkthame: I recognize the back-compat issue
17:53:44 <fantasai> astearns: let's take that as a separate issue
17:54:13 <fantasai> astearns: and resolve to use strings for format() and then find out whether drott agrees, or whether we can do something more complicated, and if string serialization format sticks can decide on consistency for rest
17:54:22 <fantasai> astearns: any other concerns about serializing format() with strings?
17:54:36 <fantasai> RESOLVED: format() serializes with strings
17:55:05 <fantasai> chris_: There weren't font MIME types at IANA, so we faked it by creating our own names
17:55:14 <fantasai> chris_: now there is a fonts/ registry for MIME types
17:55:22 <fantasai> chris_: fantasai suggested that we just use that registry
17:55:31 <fantasai> chris_: but the RFC says that it is informative, and css-fonts-3 is normative
17:55:48 <fantasai> chris_: I think we'd like to change that so that they are normative, and we are informative, and they can handle registration of new formats so we don't have to
17:55:57 <fantasai> astearns: So we would normatively refer to their spec?
17:56:07 <fantasai> chris_: And then errata the RFC so that it no longer says our spec is normative
17:57:06 <fantasai> astearns: ...
17:57:54 <fantasai> fantasai: Shouldn't have different keywords allowed between string or keyword in format()
17:58:23 <fantasai> RESOLVED: font/ MIME type registry manages valid values of format()
17:58:30 <fantasai> ??: What's involved in getting IETF updated?
17:58:40 <fantasai> chris_: I will contact the chair and ask if this is in scope of errata or not
17:58:47 <fantasai> chris_: Unsure if publish a new RFC or not
17:58:53 <fantasai> chris_: if errata, then errata submission form
17:58:54 <astearns> s/??/PeterConstable/
17:59:06 <fantasai> chris_: if not then will need to spin up a very small wg to make the change
17:59:09 <fantasai> chris_: but anyway I'll deal with it
17:59:25 <fantasai> astearns: Last thing is whether we accept unquoted keywords
17:59:43 <fantasai> chris_: Does any implementation currently accept keywords for format()?
17:59:49 <fantasai> jfkthame: IIRC webkit does, but haven't checked
18:00:13 <fantasai> chris_: And do we want to continue to allow that and allow other browsers to do so, or get them to fix that?
18:00:32 <fantasai> astearns: out of time, so let's leave issue open on this question and ask for feedback
18:00:38 <fantasai> Topic: End
18:01:03 <fantasai> astearns: Meet again in 2 weeks, please discuss whether to have a long meeting on Dec 8th to get through the agenda
18:03:17 <bradk> bradk has joined #css
18:17:07 <tantek> RRSAgent, prepare minutes
18:17:07 <RRSAgent> I'm logging. I don't understand 'prepare minutes', tantek.  Try /msg RRSAgent help
18:17:52 <tantek> RRSAgent, draft minutes
18:17:52 <RRSAgent> I have made the request to generate https://www.w3.org/2021/11/17-css-minutes.html tantek
18:18:17 <tantek> RRSAgent, make minutes public
18:18:17 <RRSAgent> I'm logging. I don't understand 'make minutes public', tantek.  Try /msg RRSAgent help
18:18:19 <astearns> zakim, end meeting
18:18:19 <Zakim> As of this point the attendees have been chris, plinss, rachelandrew, dholbert, Morgan, argyle, jfkthame, dlibby, dandclark, smfr, tantek, TYLin, jensimmons, lea, GameMaker,
18:18:22 <Zakim> ... miriam, emilio, bradk, dbaron
18:18:22 <Zakim> RRSAgent, please draft minutes v2
18:18:22 <RRSAgent> I have made the request to generate https://www.w3.org/2021/11/17-css-minutes.html Zakim
18:18:24 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
18:18:28 <Zakim> Zakim has left #css
18:54:28 <Seirdy> Seirdy has joined #css
19:22:04 <jensimmons> jensimmons has joined #css
20:12:49 <jensimmons> jensimmons has joined #css
20:54:10 <dauwhe> dauwhe has joined #css
20:55:36 <antonp> antonp has joined #css
20:59:29 <jfkthame> jfkthame has joined #css
21:18:32 <gtalbot> gtalbot has joined #css
22:15:34 <jfkthame> jfkthame has joined #css