00:05:53 zcorpan has joined #css 00:27:38 zhengxu has joined #css 01:02:52 I have made the request to generate https://www.w3.org/2020/10/20-css-minutes.html fantasai 01:03:21 I have made the request to generate https://www.w3.org/2020/10/20-css-minutes.html fantasai 01:18:47 zhengxu has joined #css 04:29:57 smfr has joined #css 04:30:16 i am trying to make sense of this text in cssom-view-1: “Elements and viewports have an associated scrolling box if the element or viewport has a scrolling mechanism or it overflows its content area and the used value of the overflow-x or overflow-y property is hidden. [CSS3-BOX]” 04:30:26 is *not* hidden? 04:37:25 yeah, i think so too, for what it's worth 04:45:30 and it should be “not hidden or clip” now 04:47:48 what's "it"? 04:48:03 The viewport overflows its content area? 04:48:06 what??? 04:48:17 what about if it overflows the content area but not the padding box? 04:48:34 why would that make any difference 04:54:29 this shuld be two or three separate sentences 04:57:34 anssik has joined #css 04:57:59 yeah there are some missing words 05:07:57 smfr has joined #css 20:02:08 RRSAgent has joined #css 20:02:08 logging to https://www.w3.org/2020/10/20-css-irc 20:02:10 RRSAgent, make logs Public 20:02:11 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 20:02:18 present+ 20:02:21 present+ 20:02:22 present+ 20:02:23 present+ 20:02:24 present+ 20:02:24 present+ 20:02:25 present+ 20:02:28 present+ 20:02:41 present+ 20:02:43 present+ 20:02:56 smfr has joined #css 20:03:21 present+ 20:03:22 present+ 20:03:25 present+ myles 20:03:35 I'm waiting to allowed in 20:03:46 we missed the last MQ discussion yesterday, can we start there? 20:03:54 present_ 20:03:57 present+ 20:04:35 present+ 20:04:40 present+ 20:05:08 Rossen Atanassov, Microsoft 20:05:11 present+ 20:05:15 present+ 20:05:15 Morgan Reschenberg, Mozilla 20:05:15 present+ 20:05:16 Alan Stearns, Adobe 20:05:16 Myles C. Maxfield, Apple Inc. 20:05:17 Simon Fraser, Apple 20:05:20 Manuel Rego, Igalia 20:05:21 Christian Biesinger, Google 20:05:22 Peter Linss, Invited Expert 20:05:22 Brian Kardell, Igalia 20:05:23 GameMaker has joined #css 20:05:24 Vladimir Levin, Google 20:05:25 Oriol Brufau, Igalia 20:05:26 Tab Atkins-Bittner, Google 20:05:26 Florian Rivoal, Invited Expert 20:05:27 brandonferrua has joined #css 20:05:28 Alison Maher, Microsoft 20:05:31 present+ 20:05:32 present+ 20:05:33 present+ 20:05:36 Megan Gardner, Apple 20:05:44 Brandon Ferrua, Salesforce 20:05:45 Miriam Suzanne, Invited Expert 20:05:48 Ting-Yu Lin, Mozilla 20:05:59 Cameron McCormack, Mozilla 20:06:04 Jen Simmons, Apple, Inc. 20:06:05 fremy has joined #css 20:06:09 Elika Etemad aka fantasai, Invited Expert 20:06:12 Topic: Masonry Layout 20:06:14 ScribeNick: fantasai 20:06:18 Chris Harrelson, Google 20:06:18 present+ 20:06:21 chris has joined #css 20:06:24 mats_: I wrote the Masonry spec 20:06:29 https://raw.githack.com/mozilla/gecko-dev/master/layout/docs/css-grid-3/Overview.html 20:06:56 dholbert has joined #css 20:06:59 mats_: That's what we'll discuss today. I didn't prepare any presentatin of it, but happy to answer any technical questions you might have 20:07:06 present+ 20:07:10 heycam: Last time I presented the explainer based on Mats's gh issue 20:07:15 heycam: Mats turned that into spec text 20:07:19 dholbert_ has joined #css 20:07:26 heycam: Main thing we want today is, ask to put this into a draft 20:07:32 heycam: and secondly, which spec does that go into 20:07:36 heycam: is it Grid 3 or something else 20:07:46 dlibby_ has joined #css 20:07:55 Rossen_: Last time discussed in F2F, was at Igalia 20:08:09 Rossen_: Have there been any major changes since then? 20:08:19 Rossen_: Some of the early conversation was should it be part of grid or own display value. 20:08:27 Rossen_: Did we resolve on this? Current proposal uses grid 20:08:33 fantasai is in favor of using grid 20:08:40 heycam: That hasn't changed in the spec 20:08:48 drousso has joined #css 20:08:51 q+ 20:08:53 q+ 20:08:54 present+ 20:08:54 heycam: Initial proposal was tied into grid and not a separate layout model 20:09:01 heycam: Not sure if that's captured as an issue in the spec itself 20:09:09 heycam: Mats, could you talk about open issues listed in the spec? 20:09:29 mats_: [garbled] 20:09:42 mats_: A few issues in the spec, but mostly resolving edge cases 20:09:42 present+ 20:09:59 present+ 20:10:34 Rossen_: We should make the issue clear 20:10:53 Rossen_: Do we want to adopt this module? 20:11:05 heycam: Maybe easier to resolve on that first, then file specific issues in GH 20:11:16 q? 20:11:21 iank_: Unsure if there was much follow-up discussion about in grid vs separate display tpe 20:11:24 s/tpe/type 20:11:51 q+ 20:11:59 q+ 20:12:08 ack TabAtkins 20:12:18 TabAtkins: First, I was looking for where the proposal was and had trouble finding it. Have URL now 20:12:32 TabAtkins: looking in the thread, back in January we already agreed to adopt this proposal 20:12:39 TabAtkins: editors me, mats, fantasai, jensimmons 20:12:49 TabAtkins: We haven't done anything with it, but it seems like we already agreed to adopt it 20:12:58 TabAtkins: so should dive into structural questions like is it grid or not 20:13:07 ack jensimmons 20:13:22 jensimmons: So not even sure what we're debating, but have comments on whether should be part of grid display type or own display type 20:13:29 jensimmons: Seems we haven't resolved that 20:13:38 jensimmons: I think it should be part of the grid display tpe 20:13:44 jensimmons: I really like how this proposal works. Read it again today. 20:13:45 jarhar has joined #css 20:13:53 jensimmons: I've been thinking about it the last few months, but re-reading again 20:14:06 jensimmons: think it would be awful lot of work to figure out making it not grid, in the other dimension etc. 20:14:12 jensimmons: and would perhaps settle on something simplistic 20:14:19 q+ 20:14:31 jensimmons: by making part of Grid, get an incredible body of work, resolved on gaps, alignment, repetition of tracks, etc. 20:14:34 If we did it as a separate thing, we would explicitly just do "exactly what Grid does" in everything that overlaps. 20:14:36 jensimmons: using minmax, etc. 20:14:42 jensimmons: Don't know why we would want to give authors a separate set of tools 20:14:48 jensimmons: Don't want to give authors two sets of things to learn 20:15:02 jensimmons: Argument from before, word "grid" means everything lines up in 2D but masonry is packing 20:15:05 jensimmons: but I think that's a pedantic argument 20:15:09 q+ 20:15:10 It would just let us get a slightly more optimized syntax for declaring the masonry, basically. 20:15:19 jensimmons: I don't think "grid" can't encompass this 20:15:32 jensimmons: I think it should be part of grid, and I really like the direction this is going so far 20:15:47 ack chrishtr 20:16:07 chrishtr: I'm wondering if, related to point already made about relation to grid, do you have data to show about how hard to implement or how much it re-uses the concept of grid? 20:16:36 mats_: It was pretty easy to fit into existing CSS grid code that we have 20:16:44 mats_: CSS grid, all the algorithms, are pretty standalone per axis 20:16:51 q! 20:16:52 mats_: so our code at least, just run the code for one axis 20:17:01 mats_: ... 20:17:04 mats_: It shouldn't be hard 20:17:13 mats_: to implement for an existing CSS Grid implementatin 20:17:14 fantasai: what's the keyword for moving yourself at the bacvk of the queue again? 20:17:20 mats_: get a lot of free structural [?] 20:17:35 ack fremy 20:17:42 q+ 20:17:56 iank_: I think my concerns from last time still hold 20:18:09 iank_: Unless I'm wrong, a few things in the grid model that not in the masonry model 20:18:13 iank_: e.g. grid-area 20:18:17 iank_: right? 20:19:05 iank_: If I have grid-area: 1/2 it will ignore one of the axes 20:19:10 I strongly suspect we'd just literally build Masonry stuff into the Grid Layout Algo, even if we did Masonry as a separate spec. 20:19:10 q? 20:19:16 ack iank_ 20:19:23 mats_: yes 20:19:25 present+ 20:19:26 iank_: That concerns me 20:19:37 iank_: Also, want to do things like splitting content over two grid areas 20:19:42 iank_: can re-use concepts 20:19:48 iank_: but I'd be hesitant to jump the gate 20:20:03 florian: I agree more with Jen than Ian 20:20:11 florian: Almost all the tools that work in Grid also should work here 20:20:28 florian: So theoretically we could have 'display: masonry' that either uses all the grid properties or has duplicate properties 20:20:28 q? 20:20:32 florian: but do we really need this? 20:20:40 florian: Having a few properties not apply some of the time is really OK 20:20:44 q+ about the set of properties applying to grid vs masonry 20:20:53 q? 20:20:57 florian: Other question, If you're trying to fall back from masonry, what happens? 20:20:58 ack florian 20:21:01 q+ 20:21:18 florian: If separate display type, you fall back to block. Grid is probably a better naive fallback. 20:21:28 florian: But I'm leaning towards keeping it a grid variation rather than a separate thing 20:21:36 florian: and not too concerned about Ian's concern 20:21:42 q- later 20:21:52 fantasai: I also think it makes sense to integrate it with grid, for all the reasons mentioned 20:21:58 ack fantasai 20:22:13 fantasai: in terms of various things not applying, if we wantt hem to apply i think we could have a masonry layout and grid layout if we wanted to 20:22:31 fantasai: So if you assign it to row 1 it's in a masonry layout in row 1, then if you put it in row 2 it's in a separate masonry layout 20:22:40 fantasai: Woudl be happy to adopt as an ED and possibly as a fpwd 20:22:44 ack TabAtkins 20:22:53 TabAtkins: Looking over the set of grid properties and whether or not they apply 20:23:10 TabAtkins: It is absolutely the case that Masonry should be built on Grid algorithm 20:23:14 TabAtkins: but as for property set 20:23:26 TabAtkins: Most of them will have weirdness that only one of the pair works in masonry layout 20:23:37 TabAtkins: grid-auto-rows vs grid-auto-columns 20:23:47 TabAtkins: We have different flow values for masonry that do something similar but distinct 20:23:52 TabAtkins: similar to placement properties 20:24:08 TabAtkins: and then I guess row gap vs column gap work similarly 20:24:20 TabAtkins: I think we should make a new display value with its own properties 20:24:25 TabAtkins: but have a single layout algorithm 20:24:50 TabAtkins: but I think we have a good opportunity to have a better developer-facing API instead of trying to re-use and half-ignore the grid properties. 20:24:59 q? 20:25:00 TabAtkins: but happy to be wrong, but I want to play around with making a new set of things just in case 20:25:08 ack fremy 20:25:14 fremy: I think I agree with Tab on this mostly 20:25:25 fremy: but also, want to accept as WD 20:25:35 fremy: I took a look, there's like one new property, masonry-auto-flow 20:25:41 fremy: but no definition of what the values do 20:25:48 fremy: Hesitant to accept when there's no definition 20:25:58 fremy: I feel like it's not working great 20:26:12 fremy: So leaning towards saying, let's make this something different and if in the end we find we re-use most of the things 20:26:22 q+ 20:26:26 fremy: but first let's define standalone and then later on if we find convergence, I think it would be more logical 20:26:45 ack myles 20:26:55 myles: Understand idea that some grid properties won't apply to masonry. And in the future, some masonry properties won't apply to grid either 20:27:19 myles: And understand argument that even if different specs, even if properties with different names in different specs, can share algorithm 20:27:32 myles: The strongest differentiator between the two solutions is what the fallback is 20:27:47 myles: is it better to have masonry fall back to block, or to have some properties that apply just to grid 20:27:58 q+ 20:28:01 myles: If masonry layout falls back to block, much worse than falling back to grid with some properties ignored 20:28:13 fremy: You can also fall back using @supports 20:28:24 fremy: There's no good reason to limit yourself because of fallback 20:28:32 ```display: grid; display: masonry;``` is what a lot of folks will do for this case. 20:28:33 fremy: Even if the properties work similarly, not quite the same 20:28:46 Karen has joined #css 20:28:50 myles: The argument there is about what authors get by default 20:29:00 ack TabAtkins 20:29:02 q+ 20:29:04 myles: of course you can do anything, but what about authors who don't think about these cases 20:29:19 TabAtkins: This is the same argument that led to multicol being built on block and not being a separate display tpe 20:29:33 TabAtkins: Multicol is different of block, and having one be variant of other is weird 20:29:47 q? 20:29:51 TabAtkins: The fact that it's a "block container" is awkward, and I'm afraid we'll run into the same problem again 20:30:04 TabAtkins: But because going to be slightly different 20:30:18 TabAtkins: I suspect we'll end up writing ourselves into awkward corners if one different from other 20:30:39 heycam: I think the comparison to multicol is interesting in another way because we have this precedent of having the gap properties, which apply to flex and grid etc. 20:30:48 heycam: we gave them one name to apply across multiple layout models 20:30:59 heycam: Here we have grid-specific properties, but if we considered masonry separate from grid 20:31:03 heycam: names ... obvious 20:31:21 Rossen_: Want to make the discussion more action-oriented. Repeating previous discussions 20:31:32 s/names ... obvious/names of some grid properties could be changed so that the commonalities are more obvious/ 20:31:33 Rossen_: want to make sure we arrive at an actual resolution of what we're doing with the current spec 20:31:48 Rossen_: keep separating the leading sort of differences on the table 20:32:10 Rossen_: implementers and what they prefer vs. fallback mechanism vs. users and authors and how they will perceive from an ergonomic point of view 20:32:27 ack jensimmons 20:32:39 jensimmons: The way I see it, alignment was created to go with flexbox and then folks realized it would be great to do in grid 20:32:53 jensimmons: and rather than come up with new set of keywords and values, because they do work slightly differently 20:33:12 github: https://github.com/w3c/csswg-drafts/issues/4650 20:33:13 jensimmons: but the argument that authors, it'll be too hard to say 'grid-template-rows: masonry' and then 'grid-auto-rows: ??' to set the default 20:33:23 jensimmons: but 'grid-auto-rows' doesn't aply 20:33:27 jensimmons: I don't think authors will be confused 20:33:31 jensimmons: to me it's very similar to alignment 20:33:54 q? 20:33:59 jensimmons: for alignment, making a separate set of syntax would have been much much more confusing 20:34:02 jensimmons: I'm really glad they share syntax 20:34:06 jensimmons: and that's my thought son this 20:34:14 jensimmons: It doesn't seem like a completely different layout model 20:34:19 jensimmons: It's an option in something bigger 20:34:26 jensimmons: and that is something that looks a lot like grid 20:34:35 jensimmons: Don't want duplication, new set of names and properties, etc. 20:34:58 jensimmons: Not just doing the simplest things possible in masonry.js, but much more powerful because built on Grid 20:35:25 fantasai: my proposal is that we adopt this as an ED, and i dont' reallyc are if we temporarily name it css-masonry or css-grid-3 20:35:32 fantasai: and think we should fill out the missing dfns, etc 20:36:11 fantasai: and come back to this topic and decide if we want to take it as fpwd as either name, and let Tab try his attempt at different names, let Jen survey authors, and come back to it in a month or two 20:36:18 fantasai: but adopt it for now as an official ed 20:36:29 fantasai: It'll be a diff spec built on top of grid anyway, at least at first 20:36:31 +1 20:36:55 fantasai: and publish FPWD when we think we're ready to show something to the world 20:37:06 Rossen_: Internally uses grid, but also is masonry layout 20:37:37 Rossen_: suggest adopt as-is and then decide upon FPWD 20:37:56 myles: We support progress on Masonry, and agree with fantasai, let's take the step we can take immediately 20:38:14 Rossen_: and might have other things to add to css-grid-3 also 20:38:31 fantasai: We have a list of stuff that's going into Grid 3 already, already resolved, just needs edits ... 20:38:37 RESOLVED: Adopt Mats's draft as ED 20:38:50 Rossen_: Mats, before you transition over, do you want to add the rest of the editors to this spec? 20:39:15 Rossen_: Jen, are you up to it? 20:39:23 jensimmons: yes, I would love to! yay new company that let's me do things 20:39:57 heycam: Firefox has recently gained a new experiments stage in the preferences 20:40:03 s/company/boss/ 20:40:10 heycam: can turn it on and play with it 20:40:18 heycam: Settings options preferences 20:40:23 heycam: I think you have to be using Nightly 20:40:31 q+ 20:40:58 ack fremy 20:41:07 fremy: Now that we adopted the ED, that sounds cool, but would like to discuss content of the draft 20:41:28 fremy: I'm not sure I understand the reason why we have all the keywords in 'masonry-auto-flow' 20:41:39 fremy: But reading the algorithms section, I'm not sure what's the goal 20:41:46 fremy: I think it would be a good idea to clarify a bit 20:42:00 Rossen_: We'll have the ED in the csswg repo pretty soon, hopefully by the end of the week 20:42:08 Rossen_: once this is the case, you can go ahead and file as many issues as you want 20:42:14 Rossen_: First issue might be display type 20:42:27 Rossen_: as well as everything else that is currently unclear, but at this point spent a lot of time and other agenda items 20:42:33 Rossen_: so please open issues 20:42:34 fremy: sure 20:42:47 q? 20:43:19 Topic: What Topic 20:43:32 Rossen_: MQ issue didn't take up yesterday, any others we missed? 20:43:57 Topic: media queries for foldable and dual-screen devices 20:44:27 ScribeNick: TabAtkins 20:44:33 Topic: Foladable screens 20:44:38 Topic: Foldable screens 20:44:45 github: https://github.com/w3c/csswg-drafts/issues/5621 20:45:10 dlibby_: This is an updated proposal for primitives we'd like to introduce for dual-screen and foldable devices 20:45:23 dlibby_: This one is a new media feature that describes the number of logical display regions a viewport is spanning across 20:45:36 dlibby_: Not th edevice itself, the relationship of the viewport to the device regions 20:45:48 dlibby_: The syntax is in two axises to allow for future form factors to use the same feature 20:46:08 dlibby_: goes hand-in-hand with the environment vars we discussed yesterday 20:46:24 q+ 20:46:25 dlibby_: Looking for opinions on this and if it's okay to add to mq5 20:46:39 q+ myles 20:46:42 q+ 20:46:50 q+ 20:46:55 ack heycam 20:47:24 heycam: my initial thoughts about this is whether these features are, don't wanna say complex bc the syntax isn't complex, but wondering if really there will be that many arrangements of displays that we need a feature shaped like this, as opposed to something simpler 20:47:41 dlibby_: in our original proposal we wer emore scoped, but that came with the baggage that as new form factors appeared, what is the syntax you would use for them? 20:47:59 dlibby_: So we feel this gives a more futur-eproof model, while allowing author to target today's devices 20:48:05 ack myles 20:48:08 dholbert_ has joined #css 20:48:31 myles: Sof or width queries, for example, if you say (display-span-x: 3), is that *at least* three screens, or exactly 3? 20:48:37 q? 20:48:53 dlibby_: Exactly, if you use the : or =. If you use < or > it gives less or more 20:48:54 q+ 20:49:16 myles: This also suggests authors might have different layouts for each arrangement - a different for 2x1 vs 1x2 vs 2x2, etc. That's the intent? 20:49:19 dlibby_: Yes. 20:49:36 ack fantasai 20:49:36 fantasai, you wanted to react to myles 20:49:50 fantasai: The mq would give you an exact number, but becuse it's an integer ti can take min/max prefixes as well, so you can just opt into "2 or more displays" 20:49:51 fantasai: display-span-x: min(2)? 20:50:00 dholbert_ has joined #css 20:50:09 fantasai: To respond to heycam, the reason I didn't want to do simpler syntax, if someone has a 3-fold device we'd need a new MQ 20:50:20 (myles, no, (min-display-span-x: 2)) 20:50:40 fantasai: The syntax for this simple case isn't any harder ot use than a more "specialized" one, but it lets us extend to a grid easily 20:50:47 fantasai: it doesn't let us extend to a non-grid, tho 20:51:00 fantasai: but i think most of the cases we'll need to worry about will be a grid or simplification of a grid 20:51:01 (TabAtkins: oh! are all number-taking media queries supposed to automatically get min- and max- prefixes?) 20:51:07 fantasai: So didn't want to box us into a corner 20:51:09 (yes) 20:51:10 q? 20:51:19 ack florian 20:51:23 florian: i think this works nicely 20:51:32 florian: as discussed yesterday, desktops can b emore complex arrangements 20:51:46 florian: but this isn't just windows that can be slightly offset from each other, it's a special display mode 20:52:03 florian: And I think a grid is really the only realistic mode to deal with 20:52:10 florian: [shows off an example] 20:52:23 florian: So i think we're good 20:52:33 q? 20:52:39 ack smfr 20:52:44 smfr: Does the asnwer to these mqs depend on which screen the browser is on? 20:52:53 smfr: From samsung demos, browser can be on left, right, ro spanning both 20:52:57 smfr: So will these change? 20:53:06 dlibby_: Yes, if you're only on a single screen, your display-span will be 1 20:53:16 smfr: So not about the physical device, about the current configuration 20:53:25 ack fantasai 20:53:39 fantasai: On that note, think we need some bikeshedding on this - we use "display" to refer to the physical device 20:53:50 fantasai: so like display-width vs width 20:54:00 fantasai: and we want consisten wording between env() and MQ 20:54:23 TabAtkins: note the MQ word is 'device-', not 'display-' 20:54:34 fantasai: Oh yeah. But the env() is using viewport, so we should be consistent between them 20:54:41 q? 20:55:08 Rossen_: So any preferences or opinions? 20:55:19 TabAtkins: No strong opinion on word, but strong opinion towards naming consistency like elika said 20:55:24 device-arrangement 20:55:35 florian: 'viewport' isn't great, it's how your viewport spans 20:55:51 heycam: perhaps something about presentation 20:55:59 fantasai: if you ahve a normal display it'll ahve a value of 1 20:56:00 dauwhe has joined #css 20:57:18 heycam: so i think like 'display-span-x' will sound like it should match if your single window spans across both segments even if it's just acting like a normal window 20:57:28 i/heycam/TabAtkins: If your window spans a folded device, is that span 2 or span 1? 20:57:48 florian: if you're on a device with a seam between screens, then eys absolutely 20:57:50 present- 20:58:03 florian: But on a device with a seamless pane separation, up to the UA to decide which way it goes 20:58:34 dlibby_: valid point, goes down to what cam was mentioning - if you're in more of a tiled mode that the device is informing the UA about 20:58:49 dlibby_: So possibility of a seamless device not presenting itself as multipane if you're not doing something 20:58:58 smfr: some implication of spanning the whole utility area 20:59:18 smfr: if you span both screens, but half of one screen is filled with a different app, your browser is 1.5 screens wide 20:59:36 smfr: So without information about what size each pane is... 20:59:45 TabAtkins: That's what the env() is for, reporting those pane sizes 21:00:12 Rossen_: So yeah in your example, the shared pane will just have a smaller viewport for the browser in that pane 21:00:30 florian: so my suggestion is to resolve to adopt it, bikeshed naming in github 21:00:43 florian: But i think we're agreeing to the proposal overall, maybe need a few details to be clearer 21:00:47 florian: But not hearing real pushback 21:00:56 q? 21:01:01 q+ 21:01:04 ack fantasai 21:01:04 fantasai, you wanted to comment on querying the gap 21:01:06 fantasai: agree with florian 21:01:30 fantasai: also might be useful to query info about the gap, how big it is and if there's content missing in the gap - if it doesn't paint or if it just jumps across 21:01:49 dlibby_: The env variables are designed let you avoid the gap, but perhaps there's a query to make it clearer up front 21:01:58 myles: are the env() indexed? 21:02:05 dlibby_: discussed that a bit yesterday, yes they are 21:02:29 dlibby_: based on discussion, should match the 2d grid indexing 21:02:38 The question of whether working on the "explode" model or the "window" model is probably relevant - http://fantasai.inkedblade.net/style/discuss/table-backgrounds/ 21:02:49 Rossen_: So any objections to adopting them into MQ5? 21:03:05 RESOLVED: Adopt the multiscreen MQs into MQ5. 21:03:12
21:12:36 topic: end 21:14:27 [side conversations about mixing environment variables and media features in comparisons as media queries] 21:17:11 [side conversation about breakout rooms] 21:17:34 [and trying to replicate hallway conversations virtually] 21:18:46 Topic: Contain 21:19:55