16:50:26 <RRSAgent> RRSAgent has joined #css
16:50:26 <RRSAgent> logging to https://www.w3.org/2022/11/30-css-irc
16:50:26 <fremy> fantasai: punctuation does not trigger this
16:50:34 <fantasai> s/punctuation/symbols and punctuation/
16:51:06 <fremy> florian: if there is a span with padding, does the separation the padding causes text-spacing to be disabled?
16:51:26 <fremy> fantasai: we did not think of this yet, but we have other cases where we have some rules, so we could add one up
16:51:44 <fremy> florian: I think we should do it, so we don't cause double-spacing for existing content
16:51:50 <fremy> fantasai: yes
16:52:11 <fremy> florian: I would still like browser implementations before going further, but I'm okay with just moving forward
16:52:12 <astearns> ack fantasai
16:52:39 <fremy> fantasai: second point I want to cover, if there is non-zero padding we should disable this behavior
16:52:50 <tantek> present+
16:53:06 <fremy> fantasai: third point, if you insert extra spaces to get this behavior today, we should take this spacing into account so it gets correct in the end
16:53:19 <fremy> florian: for CJK this seems rare
16:53:33 <fremy> florian: but for French, this might be something we want indeed
16:53:43 <fremy> florian: because you need a special space for some cases
16:53:57 <fremy> florian: but keyboards don't have the right keys so people use the wrong spaces
16:54:04 <fremy> florian: so we might want to replace them indeed
16:54:14 <fremy> (some discussion about keyboard being wrongs)
16:54:20 <fremy> astearns: any objection to accept this?
16:54:36 <fremy> RESOLVED: accept the text-spacing values for spacing adjustments?
16:54:50 <fremy> astearns: any objection to the second point about paddings?
16:55:05 <fremy> RESOLVED: non-zero padding disables text-spacing adjustement for spaces
16:55:10 <fremy> astearns: what about the third?
16:55:18 <fremy> fantasai: let's do it too
16:55:45 <fremy> astearns: so, the suggestion is to take spaces into account at the boundaries?
16:55:58 <fremy> fantasai: no, replace it
16:56:09 <fremy> astearns: I think there might be cases where the choice is intentional
16:56:20 <fremy> astearns: let's open a separate issue on that
16:56:24 <fantasai> ACTION: Open separate issue on space replacement
16:56:32 <fremy> fantasai: maybe this shouldn't be a default, but something we can ask explicitely
16:56:48 <fremy> astearns: let's go to 1 / 8
16:56:56 <fremy> florian: should we resolve on that?
16:57:04 <fremy> astearns: we should have an action for that
16:57:12 <jensimmons> jensimmons has joined #css
16:57:18 <fremy> florian: up the editors
16:57:23 <fremy> astearns: anything else on this issue?
16:57:58 <fremy> github-bot, take up https://github.com/w3c/csswg-drafts/issues/5995
16:57:58 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/5995.
16:57:58 <github-bot> Topic: [css-ruby-1] Should auto-hide match use NFKC and/or strip white space?
16:58:27 <fremy> fantasai: we have a feature in ruby where if the annotated text and the base are identical if they are presented on top of each other
16:58:40 <fremy> fantasai: but if they are side by side, they are kept for example
16:58:55 <fremy> fantasai: the question is "what is identical"?
16:59:07 <fremy> fantasai: should we normalize before doing this?
16:59:18 <fremy> fantasai: should we deal with white space
16:59:41 <fremy> fantasai: should we collapse unicode characters that merge in rendering if possible? (NFKC)
16:59:58 <fremy> fantasai: but the internationalization group thought it might be too aggressive in some cases
17:00:18 <fremy> fantasai: they recommended NFC instead
17:00:35 <TabAtkins> q+
17:00:38 <fremy> fantasai: which only deal with things that are simpler (e.g. A + an accent vs A accent)
17:00:51 <florian> q+
17:00:53 <fremy> fantasai: so, do we want to perform NFC before comparing the texts?
17:00:59 <astearns> ack TabAtkins
17:01:07 <fremy> TabAtkins: I support whitespace stripping
17:01:18 <fremy> TabAtkins: because it can be due to source code formatting
17:01:35 <fremy> TabAtkins: but I don't think we should do NFC because we don't do this elsewhere
17:01:58 <fremy> TabAtkins: I expect that authors use the same typing convention in the same markup
17:02:07 <fremy> TabAtkins: we are not comparing html vs css
17:02:13 <astearns> ack florian
17:02:16 <fremy> florian: I agree about whitespace
17:02:30 <fremy> florian: for normalization, I'm less sure
17:02:45 <fremy> florian: if one persons types the text, and another the annotations
17:03:03 <fremy> florian: NFC is not very aggressive, I think it would make things more rational for users
17:03:21 <fremy> florian: however, it will be rare I think
17:03:32 <fremy> florian: but if it did occur, I think the correct behavior is to normalize
17:03:40 <fremy> florian: (so, preference for NFC, but not strong)
17:03:52 <jfkthame> +1 to nfc
17:03:57 <fremy> astearns: can we resolve on stripping whitespace, and leave off normalization?
17:03:58 <heycam> q+
17:04:14 <fremy> fantasai: I think yes, I agree with TabAtkins, we don't do it elsewhere
17:04:21 <fremy> fantasai: so it seems ok to drop this
17:04:30 <astearns> ack heycam
17:04:38 <fremy> heycam: this is just a content check, correct?
17:04:53 <fremy> heycam: we don't look at display:none etc... ?
17:05:04 <fremy> fantasai: we might be looking at display:none?
17:05:08 <fantasai> s/TabAtkins, we don't do it elsewhere/TabAtkins and Florian: it's definitely the right thing to do, but it's also not done elsewhere in the platform and is quite rare to mismatch/
17:05:14 <fremy> florian: but not generated content etc
17:05:17 <astearns> jfkthame: would you be OK not doing NFC, or would you prefer we resolve to use NFC?
17:05:27 <fremy> heycam: okay, hopefully the spec is very clear on that
17:05:49 <fremy> astearns: reading IRC comments
17:05:58 <fantasai> [note: those of us on the call are somewhat ambivalent about NFC, given pros and cons]
17:06:04 <jfkthame> astearns: I'd be ok with not, though I think it's less good (sorry, in another meeting)
17:06:07 <heycam> (I kind of don't quite understand the need for this automatic hiding, and why the author doesn't use visibility:hidden on ruby text that they know is the same as the base text)
17:06:34 <fremy> astearns: okay, since we have lots of doubts on NFC, let's just do whitespace and leave if at that
17:06:34 <fantasai> heycam, it's because whether it should be invisible or not depends on how it's styled
17:06:48 <fremy> florian: and also put an action on me to clarify the display:none behavior
17:06:55 <fantasai> heycam, and there's no selector for "this is the same text as the other thing" :)
17:07:01 <heycam> ok
17:07:09 <fantasai> heycam, plus it's what you want by default so we should do it by default
17:07:22 <fremy> astearns: so, the proposed resolution would be to only perform whitespace stripping before comparing the base and annotation texts
17:07:25 <fremy> astearns: any objection?
17:07:38 <fremy> RESOLVED: only perform whitespace stripping before comparing the base and annotation texts
17:07:53 <heycam> text-transform? :o
17:08:06 <fantasai> ”The content comparison for auto-hiding takes place prior to white space collapsing (white-space) and text transformation (text-transform) and ignores elements (considers only the textContent of the boxes).
17:08:06 <fremy> ACTION florian: make sure the way to determine what text we are talking about (display:none, etc...)
17:08:10 <fantasai> ”
17:10:23 <fremy> Topic: none
17:10:23 <fremy> https://github.com/w3c/csswg-drafts/issues/8029
17:16:43 <Rossen_> Rossen_ has joined #css
17:18:20 <fantasai> scribenick: fantasai
17:18:37 <github-bot> Topic: [css-nesting-1] Yet another nesting proposal
17:20:13 <jensimmons> I'd like to begin this discussion by requesting we call this "Option 5".
17:21:05 <fantasai> RESOLVED: call this Option 5 :)
17:21:51 <fantasai> plinss: This is something I've been wanting to do since the 90s, and immediately ran into problem of conflicts when nesting selectors inside a rule that expects properties
17:22:04 <fantasai> plinss: I understand option 3 is trying to find workaround, an doption 4 a different approach
17:22:13 <fantasai> plinss: Wondering what if we turn the problem around entirely
17:22:23 <fantasai> plinss: and introduce a top-level construct that only contains nested rules
17:22:33 <fantasai> plinss: so never mix properties and rules in a single context
17:22:44 <fantasai> plinss: My concern with Option 3 is that even if we have a syntactic way to disambiguous, that does paint us into a corner
17:22:55 <fantasai> plinss: harder to introduce new things in the future
17:23:01 <fantasai> plinss: My proposal is to introduce an @rule, calling @nest
17:23:07 <fantasai> plinss: and inside that block is nothing but nested rules
17:23:17 <fantasai> plinss: Can have no selector for a block, and that applies properties to the top-level selector
17:23:21 <TabAtkins> q+
17:23:34 <fantasai> plinss: No parsing changes, no extra lookahead, no changes to OM, easy to explain, no special bizarre syntax rules, just works
17:23:47 <fantasai> plinss: Downside is you add an extra layer of indenting for properties that apply to top-level rule
17:24:01 <fantasai> plinss: but I don't see that as a problem because I add extra blocks to code all the time, modern tools make this easy
17:24:09 <fantasai> plinss: it's easy to see what happens
17:24:23 <oriol> q+
17:24:24 <fantasai> plinss: I think this is much better than adding cognitive load to authors, learning weird parsing exception rules
17:24:31 <fremy> q?
17:24:32 <Rossen_> ack TabAtkins
17:24:41 <oriol> q-
17:24:46 <fantasai> TabAtkins: As I said in issue, my objection is still that it requires a non-local edit
17:25:00 <fantasai> TabAtkins: Can't just add stuff, need to go back and change the existing rule to allow nesting
17:25:17 <fantasai> TabAtkins: It's a non-trivial bit of work, and is distinct from the way that every preprocessor has tried to do things since they invented nesting
17:25:38 <fantasai> TabAtkins: Also, I continue to think that any statement about complexity of the rules for Option 3 is overstated, it's literally just "does the selector start with an identifier? if so need a prefix"
17:25:41 <fremy> q+
17:25:44 <fantasai> TabAtkins: not that big a deal to learn or work around
17:25:59 <fantasai> TabAtkins: Doing non-local edits to add nested rules to something is also a cognitive load when making edits in place
17:26:02 <fantasai> TabAtkins: I don't like it
17:26:09 <fantasai> TabAtkins: it does have better qualities than some other proposals
17:26:29 <fantasai> TabAtkins: but it's roughly equivalent to just prepending @nest to all rules in terms of overall functionality, just changes where @nest shows up basically
17:26:39 <fantasai> TabAtkins: That's been mildly rejected by authors and WG already, would like to avoid
17:27:07 <fantasai> plinss: On the conflict issue, the point that you're missing is that mixing selectors and properties in one block does constrain us for future expansion
17:27:17 <fantasai> plinss: if we ever want to put [missed] in a property block, we can't do that
17:27:30 <fantasai> plinss: I'm very concerned about contraining our ability to expand CSS later
17:28:03 <fantasai> TabAtkins: I share your concern. Still have some room for expansion, so I'm okay with it. E.g. if your expansion is after property name, can still do that; or if we introduce functional notations, we can still do that
17:28:09 <fantasai> TabAtkins: neither of these would be parsed as a nested rule
17:28:19 <fantasai> TabAtkins: so think there's still enough space for expansion, in my opinion
17:28:32 <ydaniv> s/contraining/constraining/
17:28:36 <fantasai> plinss: Also, you can interleave properties and nested rules, how does that show up in the OM? Will lose that on reserialization
17:28:42 <fantasai> plinss: my proposal avoids because can't do that
17:28:59 <fantasai> TabAtkins: Assigning meaning to ordering seems fraught in first place, but it does mean when reserialize it'll look different from input
17:29:15 <Rossen_> q
17:29:27 <fantasai> plinss: no functional difference, but authors will order things for organizational reasons, and it's a loss to the author if lost on reserializatoin
17:29:46 <astearns> In option 5 you can still interleave, I think `@nest foo { & {} bar {} & {} }`
17:29:47 <fantasai> fremy: I feel like there's a way of serializing this
17:29:54 <fantasai> fremy: I don't agree that if you allow properties after rules it's meaningless
17:30:01 <fantasai> fremy: it's same as selector with & only
17:30:05 <fantasai> fremy: It affects ordering
17:30:12 <fantasai> fremy: If your property defined after a rule doesn't work
17:30:18 <fantasai> fremy: but that's a different topic, but it's something to consider
17:30:23 <plinss> astearns, yes, but the ordering is preserved because they're all style rules
17:30:29 <astearns> ok
17:30:30 <fantasai> fremy: Other than that, I feel like one positive point from plinss's proposal he didn't mention
17:30:37 <fantasai> fremy: Shared with Option 4
17:30:42 <fantasai> fremy: It's ability to copy / paste
17:30:57 <fantasai> fremy: If you nest with Option 3, cannot copy paste without running into problems maybe
17:31:03 <fantasai> fremy: Both this and option 4 have this ability
17:31:23 <fantasai> fremy: I agree that when you change from one rule to nesting, you have t oadd some stuff before/after, but I think it's worth mentioning that for Option 3 that if you go from nesting to not nesting or vice versa
17:31:27 <fantasai> fremy: you need to change things
17:31:36 <fantasai> fremy: refactoring is a pain in both cases, but it's different kind of paint
17:31:51 <fantasai> fremy: but I wanted to mention this important point
17:31:54 <tantek> copypaste++ and and also +1 for adding/removing nesting without having to rewrite the contents as a design principle
17:31:55 <Rossen_> q?
17:31:58 <argyle> q+
17:31:58 <Rossen_> ack fremy
17:32:04 <jensimmons> +q
17:32:26 <fantasai> argyle: I'm confused by the copy/paste scenario? I'm writing CSS using nesting 1, 2, 3,
17:32:39 <fantasai> argyle: I copy paste stuff in and out of socpe, in and out of ..., just use & everywhere
17:32:59 <fantasai> fremy: You decided to use & everywhere, but if you remove nesting it'll break
17:33:02 <Rossen_> ack argyle
17:33:03 <fantasai> argyle: it only breaks with :has()
17:33:24 <fantasai> fremy: that's not what I mean, what I mean is if you have a CSS file with a lot of rules, they can start with any selector
17:33:27 <fantasai> fremy: html or p or whatever
17:33:39 <fantasai> fremy: If you want to take all these rules and nest them, and say they only apply in this div with special ID
17:33:46 <fantasai> fremy: you have to add & to selectors or they will break
17:33:52 <fantasai> fremy: You can't just copy paste them into the brackets
17:34:10 <fantasai> argyle: Concern in general, & makes it better and more clear
17:34:21 <fantasai> fremy: Even if it was required, you would have to add these when you paste into nested context
17:34:31 <dino> dino has joined #css
17:34:48 <fantasai> fremy: When you have a stylesheet with normal selectors, if you want to nest this stylesheet, you have to add & before every selector or it won't work
17:34:53 <fantasai> argyle: I would like to see examples
17:35:08 <fremy> stylesheet was " html { color: red }
17:35:17 <fantasai> Rossen_: Sounds like some conversation paste each other, but 2-3 line example from fremy you will be able to see what he means about usability
17:35:21 <fremy> if you want to nest this in #id
17:35:35 <fremy> "#id { html { color: red } }" is not valid
17:35:39 <fantasai> argyle: I've been using this stuff, it's not just theoretical
17:35:49 <fantasai> argyle: I have 100s of lines of nested lines of CSS, I don't find a portability issue
17:35:55 <fremy> you have to go and edit "#id { & html { color: red } }"
17:36:01 <fantasai> argyle: I don't see what you're talking about
17:36:30 <Rossen_> q?
17:36:35 <fremy> and you have to do that for potentially a lot of selectors
17:36:39 <fantasai> argyle, you're one of 50% of authors who think it's fine to prefix all their style rules everywhere forever with &. The other 50% of authors don't want to do this.
17:37:02 <argyle> i'm in both camps, trying both..
17:39:03 <fantasai> jensimmons: I really like this option, I like this a lot. I like it better than Option 4
17:39:15 <fantasai> jensimmons: what I would hope is that folks who've done a lot of work on this, and advocating to make this reality
17:39:28 <fantasai> jensimmons: I hope that you are honestly willing to consider these other possibilities
17:39:43 <fantasai> jensimmons: what's interesting about this is that it's a deviation from how web developers have thought about nesting from e.g. sass
17:39:56 <fantasai> jensimmons: it is more like writing an @rule and doing stuff inside it, isntead of having the shape from sass
17:40:00 <fantasai> jensimmons: but I don't think we should reject out of hand
17:40:08 <fantasai> jensimmons: there is something elegant of it
17:40:28 <miriam> q+
17:40:36 <fantasai> jensimmons: and I thinkw e ened to think of the full range of ppl who write CSS, from students to hobbyists to professionals that write lots of JS to professionals that do other type of software engineering to professionals that do [msised]
17:40:40 <fantasai> jensimmons: want it to be not breaking
17:40:44 <fantasai> jensimmons: make it easy to understand
17:40:54 <fremy> q?
17:40:55 <fantasai> jensimmons: think this proposal is very elegant and straightforward
17:41:07 <fantasai> miriam: 2 things
17:41:24 <fantasai> miriam: 1. This proposal is very much like @scope, doesn't have scoping aspects but otherwise the shape of it is basically identical to socpe
17:41:37 <fantasai> miriam: I don't know if that's positive or negative, but worth pointing out
17:41:49 <fantasai> miriam: I agree with Jen about who we should think about, but also with Tab about how this seems problematic
17:42:06 <fantasai> miriam: copy/paste is pitched as an advantage, but you're not abile to copy/paste int osomething not @nest, takes a lot of adjustment
17:42:20 <fantasai> miriam: All of these proposals have tradeoffs, and we keep fighting about which tradeoffs, and aruging which are better for authors
17:42:25 <Rossen_> ack jensimmons
17:42:29 <Rossen_> ack miriam
17:42:30 <fantasai> miriam: I think all of theme are hard for authors, but we need to pick one
17:42:44 <fantasai> fremy: I thought we agreed to make a survey and see what ppl think, but we now have another proposal
17:42:52 <fantasai> fremy: but we should probably should do that
17:43:01 <fantasai> Rossen_: Agreed
17:43:26 <fantasai> Rossen_: getting away from topic which is review of this proposal
17:43:38 <fantasai> Rossen_: appreciate plinss for describing the proposal and its pros/cons wrt others
17:43:46 <jensimmons> q+
17:44:00 <fantasai> Rossen_: My hope is that we'll get to next step and at some point will need to close the door on more options
17:44:12 <fantasai> Rossen_: and start scoping down which we will go with, which will work best for authors
17:44:19 <fantasai> Rossen_: with that, I want to move on...
17:44:42 <fantasai> Rossen_: but I want to simply take the conversation down to a closure with next steps being, let's figure out what ppl think about these options in a representative way
17:44:46 <fantasai> Rossen_: and then come back to making some choices
17:45:09 <fantasai> jensimmons: I would really love for us to come to a decision, a final decision, by the end of the year. That might be a little ambitious
17:45:15 <fantasai> jensimmons: I do think we're close.
17:45:30 <fantasai> jensimmons: we could just decide on Option 3 and call it a day, but I think we do want to have a bit more debate about 4 or 5
17:45:39 <fantasai> jensimmons: but I also hear the clock ticking, so would like a decision by early January
17:45:57 <fantasai> Rossen_: Appreciate pressure and urgency, and hope we'll have something end of year or beginning of next
17:46:05 <fantasai> Rossen_: Ok, let's wrap up this conversation. Thanks plinss for bringing this up
17:46:19 <fantasai> Rossen_: one last closing question, do we have a path forward to organize non-biased survey, and who would that be?
17:46:50 <fantasai> Rossen_: jensimmons, can you do that? You seem most non-biased :)
17:47:03 <fantasai> fremy: I think last time miriam, TabAtkins, fantasai and leaverou agreed to help
17:47:21 <fantasai> plinss: I can edit the new proposal into the table
17:47:59 <fantasai> -> https://drafts.csswg.org/css-nesting-1/proposals
17:48:08 <fantasai> ACTION: plinss to update proposals table
17:48:19 <fantasai> ACTION: jensimmons, miriam, leaverou, fantasai, etc. to create survey
17:48:43 <github-bot> Topic: [css-tables] Allow 'order' on table columns
17:50:03 <Rossen_> q?
17:50:07 <Rossen_> ack jensimmons
17:50:12 <JakeA> my bad, I thought we'd moved to another issue
17:50:18 <fantasai> fantasai: question is whether to ask fremy to draft up a specific proposal for applying order to tables
17:50:35 <fantasai> fantasai: would be restricted within boundaries of a rowspan/colspan, can't shuffle those, but in any case we need a detailed proposal
17:50:45 <fantasai> fantasai: and question to WG is do we want a detailed propsoal
17:51:06 <Rossen_> q?
17:51:12 <fremy> q+
17:51:13 <smfr> q+
17:51:14 <fantasai> -> https://github.com/w3c/csswg-drafts/issues/7340#issuecomment-1247390415
17:51:19 <JakeA> Rossen_: opinons?
17:51:23 <Rossen_> ack fremy
17:51:38 <JakeA> fremy: I think it's a good time to think about it. I'll spend time in December working it - eg the table spec & this
17:51:51 <JakeA> fremy: I think I agree. It doesn't feel like a huge amount of work
17:52:11 <JakeA> fremy: I think this is a reasonable thing to do
17:52:25 <Rossen_> ack smfr
17:52:32 <JakeA> smfr: I think webkit has a low level of enthusiasm to do this.
17:52:32 <PaulG> q+
17:52:44 <dholbert> +1 to smfr, I have the same feeling RE Gecko's table code
17:52:47 <JakeA> smfr: col order has semantic value. I don't think we'd implement this any time soon.
17:52:55 <Rossen_> ack PaulG
17:53:24 <JakeA> PaulG: MS's spec for focus groups may be impacted by this
17:53:37 <Rossen_> q?
17:53:41 <JakeA> PaulG: Different things may be correct depending on perspective
17:53:43 <iank_> q+
17:53:52 <JakeA> Rossen_: I see similar reservation from Mozilla
17:54:03 <Rossen_> ack iank_
17:54:12 <JakeA> iank_: Q: Would this logic be pre or post col sizing?
17:54:20 <JakeA> fremy: Before I guess
17:54:48 <JakeA> iank_: We have the newest impl right now. Our proposal would be fine. Table code is tricky due to legacy.
17:55:20 <JakeA> iank_: eg how do mergeable columns work? If it's like the order prop in grid & flex, that's simpler
17:55:38 <JakeA> iank_: If it's pre sizing, it may have unintended effects on space distribution
17:55:49 <JakeA> iank_: If there's a simple way that's clean, that would be fine
17:56:00 <JakeA> iank_: tables are complicated :D
17:56:19 <JakeA> fremy: Can we move this to tables 4? That gives time for folks to reconsider. Does that make sense?
17:56:25 <JakeA> iank_: That's fine by me
17:57:00 <JakeA> Rossen_: Freshness of impl doesn't impact complexity due to legacy behaviour.
17:57:13 <JakeA> Rossen_: Let's put it on the backlog. Deal with it later.
17:57:25 <JakeA> Rossen_: Legacy things aren't going to be removed before then
17:57:45 <JakeA> Rossen_: if anyone wants to reopen it, we can
17:58:05 <JakeA> fantasai: we can reconsider it in the next level
17:58:11 <JakeA> (not 100% I heard the above correctly)
17:58:39 <JakeA> fantasai: the problem with closing it is it falls off the radar, and we lose context.
17:59:04 <JakeA> jensimmons: What's the usecase? We want to reorder the table without impacting the semantic order?
17:59:20 <JakeA> Rossen_: That's exactly where there's pushback. I'm in favour of closing. Objections?
17:59:37 <JakeA> Rossen_: Sorry, resolution? It's not a path forward we want to adopt
18:00:01 <JakeA> Rossen_: Hearing no objections. Let's close it, and not generate activities on it, that won't have impact.
18:00:06 <jensimmons> Giving authors a way to more easily reorder columns & rows is something the web should do! But not in CSS.
18:00:10 <fantasai> s/context/context, if we don't want to actually reject it we should defer rather than closing/
18:00:21 <JakeA> RESOLUTION: Close the issue. Lack of interest.
18:00:34 <fremy> @ jensimmons, I think I agree
18:00:37 <astearns> RESOLVED: Close the issue. Lack of interest.
18:00:49 <emeyer> emeyer has left #css
18:00:49 <Rossen_> Topic: end
18:01:33 <JakeA> Rossen_: Next week we'll have two calls. One in the morning, one regular time. One where we go through scroll timeline issues. Then later, the APAC call
18:01:52 <JakeA> Rossen_: Thank you for dialing in and getting up early / staying up late. Thank you!
18:02:12 <Rossen_> Thank you scribers!!
18:02:16 <fantasai> Meeting closed.
18:02:22 <Rossen_> Zakim, end meeting
18:02:22 <Zakim> As of this point the attendees have been Rossen_, flackr, ydaniv, \, jensimmons, heycam, fremy, JakeA, fantasai, jfkthame, chrishtr, miriam, PaulG, masonf, oriol, vmpstr, dbaron,
18:02:25 <Zakim> ... argyle, plinss, tantek
18:02:25 <Zakim> RRSAgent, please draft minutes v2
18:02:25 <RRSAgent> I have made the request to generate https://www.w3.org/2022/11/30-css-minutes.html Zakim
18:02:28 <Zakim> I am happy to have been of service, Rossen_; please remember to excuse RRSAgent.  Goodbye
18:02:32 <Zakim> Zakim has left #css
18:05:22 <jfkthame> jfkthame has left #css
18:38:09 <liam> liam has joined #css
18:40:05 <geheimnis`> geheimnis` has joined #css
19:04:41 <jamesn> jamesn has joined #css
20:27:25 <liam> liam has joined #css
21:55:07 <jensimmons> jensimmons has joined #css
23:35:35 <jensimmons> jensimmons has joined #css