15:59:32 RRSAgent has joined #css 15:59:32 logging to https://www.w3.org/2020/03/25-css-irc 15:59:34 RRSAgent, make logs Public 15:59:35 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 16:00:23 present+ 16:00:28 ScribeNick: dael 16:00:31 present+ 16:00:36 present+ 16:00:38 present+ 16:00:45 present+ 16:00:46 present+ 16:00:48 present+ 16:00:53 present+ 16:00:56 present+ 16:00:59 dholbert has joined #css 16:01:04 present+ 16:01:16 Present+ antonp 16:01:20 present+ 16:01:22 rniwa has joined #css 16:01:23 present+ 16:01:29 present+ 16:01:36 present+ 16:01:39 present+ 16:01:48 Rossen_: We'll get going in about a minute 16:01:49 present+ 16:01:52 present+ 16:02:16 present+ 16:02:59 smfr has joined #css 16:03:25 Rossen_: Let's get started 16:03:29 aja has joined #css 16:03:35 Rossen_: As usual, asking for any extra items for the agenda 16:03:45 present+ 16:04:12 present+ 16:04:22 Rossen_: One I have is about virtual F2F trial meeting we wanted to run soon to check and see how a typical virtual F2F meeting would run 16:04:51 Rossen_: Idea is pick a topic that's ideally going to attrack wide and active audience as well as ask and encourage as much participation as possible so we can put stress on the tool 16:05:26 Rossen_: Only topic proposed so far was from myself which is Color Scheme discussions. I had combed through GH and this topic spans a fair number of issues and specs. 16:05:37 masonfreed has joined #css 16:05:38 Rossen_: In absense of better proposals we can proceed with this 16:06:12 Rossen_: In terms of tech we want something with video and audio but there's good discussion about something a11y built in. Good ongoing discussion in chairs area 16:06:24 Rossen_: Once we land on something that works for everyone we'll proceed with that 16:06:36 Rossen_: That's everything about housekeeping and F2F 16:06:41 Rossen_: Comments or questions? 16:06:42 present+ 16:06:50 drousso has joined #css 16:06:53 Topic: [css-align][css-grid] Do grid items that have "no baseline set" participate in baseline alignment? 16:06:56 present+ 16:07:00 github: https://github.com/w3c/csswg-drafts/issues/4675 16:07:01 present+ 16:07:23 present+ 16:07:24 Rossen_: This was discussed a couple weeks back 16:07:34 Rossen_: We don't have a resolution yet. Can we make any progress now? 16:07:39 q+ 16:07:50 present+ 16:07:59 fantasai: I thought we had discussed if such items participate and decided that they do. Happy to re-resolve unless someone thinks different. 16:08:15 ack lajava 16:08:28 oh, sorry 16:08:30 lajava, are you talking? 16:08:32 Rossen_: lajava we can't hear you 16:09:28 yes, I don't know what happens with my mic 16:09:33 Rossen_: While lajava looks into audio issue...fantasai I'm happy to move on and remove agenda tag. Re-reading discussion we left it as leaning on previous resolution and making progress. Since additional information I wanted to see if there's need to re-resolve or discuss 16:10:46 lajava: I wanted to comment for me examples from fantasai are clear. We already resolved for orthogonal flow items synthesize. Only doubt that triggered discussion is he considered empty items were different. It's not clear in the spec that those items participate 16:10:58 lajava: Only thing to clarify in spec is if empty items participate or not in baseline 16:11:12 lajava: Only sentence I found in spec is the one I added in my last comment 16:11:15 baselines of empty boxes: https://github.com/w3c/csswg-drafts/issues/439 16:11:42 lajava: If I understood having alignment properties set to baseline implies any item should participate. Mats prefers something more explicit to be added. 16:11:52 lajava: That's only thing up for discussion I think 16:12:05 Rossen_: fantasai linked to a discussion about empty boxes for alignment in grid 16:12:33 Rossen_: There's a clear resolution in the past. With that resolution linked into the minutes and GH I'm happy to move on 16:12:39 Resolution from 439: Have grid and flexbox keep saying that empty boxes have no baseline and they're synthesized with bottom border edge. 16:13:03 lajava: I mentioned that to Mats in bugzilla. Point is this only clarifies how to syntesize. He continues to state that they don't participate in baseline 16:13:13 lajava: I'd prefer Mats to define his point. 16:13:38 lajava: I'm okay closing this issue and resolve that any item that has align or justify self as baseline participates in baseline alignment 16:13:42 Rossen_: Reasonable 16:13:51 Rossen_: Anything else on this? 16:14:26 Topic: [css-pseudo-4] Custom state pseudo class proposal 16:14:35 github: https://github.com/w3c/csswg-drafts/issues/4805 16:14:54 fantasai: Do we have resolution on last? 16:15:14 Rossen_: No I thought way we closed last time was valid. I'm assuming if Mats wants to revist he can do 16:15:17 github: none 16:15:24 fantasai: Can we resolve b/c there are unclear cases 16:15:32 Topic: css-align][css-grid] Do grid items that have "no baseline set" participate in baseline alignment? 16:15:40 github: https://github.com/w3c/csswg-drafts/issues/4675 16:15:56 fantasai: All boes can participate in baseline alignment. If they don't have a baseline one is syntesized 16:16:02 Rossen_: Objections? 16:16:15 RESOLVED: All boxes can participate in baseline alignment. If they don't have a baseline one is synthesized 16:16:23 Topic: [css-pseudo-4] Custom state pseudo class proposal 16:16:31 github: https://github.com/w3c/csswg-drafts/issues/4805 16:16:50 AmeliaBR: Did you mean to agenda +? 16:17:09 TabAtkins: I put a comment in the wrong thing. Last comment from me on 4805 is part of contructable style sheets. 16:17:41 TabAtkins: Web components F2F happened yesterday and MOnday. Discussed const ss. While Web components has no power, we came to consensus on issues. Need to record here. 16:17:52 github: https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-600279738 16:18:06 chris has joined #css 16:18:13 present+ 16:18:16 q? 16:18:45 s/[css-pseudo-4] Custom state pseudo class proposal/[construct-stylesheets] what kind of array/ 16:18:47 TabAtkins: Change from last F2F resolution. At F2F we weren't sure what to switch to. Matching stylesheet list with new mutable version which no one likes since it was an old dumb API where it's not an array in many ways. But it's well known 16:19:15 TabAtkins: Option 2 is wait for someone to put down details for a good fake array in webIDL. Fake array option was better but had no timeline so we went with mutable stylesheet. 16:19:27 TabAtkins: Dominik has since written it and it's been well reviewed. 16:19:43 s/Dominik/Domenic/ 16:19:45 https://heycam.github.io/webidl/#idl-observable-array 16:19:50 TabAtkins: I believe we should revisit and change to have adopted stylesheets use this new once it's added to WebIDL 16:20:20 TabAtkins: Still want consistency so should make stylesheet lists if possible a subclass of obserable array, read only one, so looks same and it's only read only with some legacy things 16:20:30 ??: I don't think there was consensus 16:20:35 s/??/rniwa/ 16:20:35 TabAtkins: Okay, so first part first. 16:20:39 s/??/rniwa/ 16:20:46 TabAtkins: Switching from mutable version to observable array 16:21:03 TabAtkins: I vote aye, let's get the part for nay 16:21:29 rniwa: Issue with assignment is as I mentioned in comment on thread people are writing racy code where grab content of array. 16:21:46 TabAtkins: Let me inturrupt. DIfferent issue. not about assignment. Just switch to observable array 16:21:50 rniwa: tied, though. 16:22:00 TabAtkins: If we need to do both we can. But if possible to sep we do 16:22:19 rniwa: Objection to switch to observable is we shouldn't unless we can change document.stylesheet o same model 16:22:42 q? 16:22:47 dominic: Mutable is new consept which is not inconsistent. If we're choosing between two concepts that are new we should pick the better 16:22:53 s/dominic/domenic/ 16:23:03 TabAtkins: It's a necessary point of difference. It's not an inconsistency that should count againt 16:23:07 q+ 16:23:17 domenic: We're creating a third interface 16:23:24 TabAtkins: In parts were it overlaps it would be consistent. 16:23:33 Domenic: observable would also be consistent. No parts 16:23:41 TabAtkins: Stylesheet list has terrible but existing... 16:23:51 Domenic: Benefit is it fails arra.isarray check? 16:24:04 TabAtkins: Acts same between two. Only difference is things that corrispond to mutability. 16:24:20 TabAtkins: Agree we need consistent. One mutable one not or one read only and one not. 16:24:34 q? 16:24:59 Rossen_: Sounds like we're going to have debate going. To avoid talking over each other, let's use the queue. We have emilio on next. Before we do that I want to make sure we have the right issue 16:25:27 Rossen_: I'm hearing push back from rniwa if we can resolve on switching first given gCS has an effect. Happy to switch, but let's define a logical order to discuss. 16:25:35 Rossen_: Who will propose order? 16:25:51 TabAtkins: I introduced #5 as first thing to discuss and that's what we're talking about 16:26:14 Rossen_: Declaring change from frozen to observable and I'm hearing push back about needing another resolution about gCS using same API 16:26:23 q? 16:26:29 TabAtkins: It's in the same issue. That's why I said it was a sub issue we need to discuss together. 16:26:37 Rossen_: Okay. Back tot he queue 16:26:57 emilio: We didn't resolve on mutable, we resolved on adding methods to document.shadowRoot so methods are consistent. 16:27:05 TabAtkins: I don't remember that. Have to expose array somehow 16:27:08 s/tot he queue/to the queue/ 16:27:08 q+ 16:27:13 ack emilio 16:27:23 emilio: Yes, as immutable. I think we resolved on adding insert and so on to document.shadowRoot 16:27:37 TabAtkins: Gotcha. Essentially the same thing. Sure. Yeah 16:27:40 ack hober 16:27:41 s/document.shadowRoot/DocumentOrShadowRoot 16:27:54 hober: Confirming emilio is right about that resolution I'm pretty sure 16:28:18 fantasai: COmment on web components. Can you put it as a resolution in your minutes? Even if it's non-binding 16:28:32 hober: That was the A Coruna resolution 16:28:37 s/binding/binding, at least it's clear/ 16:28:39 Rossen_: Going through F2F minutes 16:29:09 https://lists.w3.org/Archives/Public/www-style/2020Feb/0012.html 16:29:16 q? 16:29:19 A Coruña minutes ^ 16:29:19 q+ 16:29:20 TabAtkins: My arguement doesn't change, though. The two are isomorphic. It subs in for the same reasoning in my argument. 16:29:42 ack rniwa 16:29:45 - RESOLVED: Make adopted stylesheets a CSSStyleSheetList and add the 16:29:45 appropriate add/remove methods to the document or 16:29:45 shadowRoot interface (WICG Constructable Stylesheets 16:29:45 Issue #45: CSS() and FrozenArray) 16:30:02 rniwa: Clarifying there's no resolution at web components b/c don't have formal methods to come to resolution. That's why we're here. 16:30:28 q+ 16:30:31 TabAtkins: Now that we're up to speed on previous resolution. Keeping things consistent with both APIs being legacy stylesheet or moving both to observable array, the nice new thing that works like people want. 16:30:42 rniwa, yeah, but if you record consensus in your meeting clearly as such, then even if it's not a formal WG resolution, at least your minutes are clear on what you agreed on 16:30:53 TabAtkins: I push for both with document.stylesheet becoming a read-only but they both act like an array. 16:31:04 ack hober 16:31:05 rniwa, actively avoiding recording resolutions because you don't have the power to bind any WG to it means your minutes lack clarity 16:31:06 TabAtkins: Objections to doing that? Otherwise I seek resolution 16:31:22 hober: Agree with TabAtkins and rniwa that they should have similar interfaces. 16:31:56 rniwa, that might also be worth noting explicitly then. Basically any discussion should have its conclusion clearly called out, whatever it is 16:31:57 hober: One of the ways to do that and make very consistent and match resolution spirit is make both same subclass or read-only observable area and then add menthods emilio mentioned on shadow root to mutate 16:32:21 this is why I hound Rossen on explicit resolutions whenever we're missing one :) 16:32:23 hober: Gets consistency, underlying data structure. Avoids footgun. I think that's the middle ground that satisfies all desires 16:32:56 q? 16:32:57 TabAtkins: I don't see why we make this mutable but only through unrelated functions when you have array editing functions. Observable array lets you do mutations that work correctly. This feels worse. I don't like it 16:33:19 Rossen_: Do we have a resolution for keeping both interfaces the same? 16:33:40 hober: I think it's implied by a coruna resolution. It resolves they should both be stylesheet lists 16:33:58 Rossen_: Not sure it's same. Sounds like consensus they should be same. Let's resolve they should and then work on what 16:34:01 hober: I think that works. 16:34:13 hober: If we move on I think there are 3 options. But I think we can resolve on that 16:34:25 Rossen_: Your prop doesn't negate the proposal to keep them the same 16:34:33 rniwa: [missed] 16:34:44 rniwa: keeping both the same is a good resolution 16:34:46 Rossen_: Objections or comments as to why we shouldn't keep the two interfaces the same? 16:35:07 Domenic: I don't think consistent is highest value. I think users better served by good apis. Willing to go along 16:35:36 GitHub: https://github.com/WICG/construct-stylesheets/issues/45 16:35:57 github: https://github.com/WICG/construct-stylesheets/issues/45 16:36:20 RESOLVED: keep the two interfaces the same? 16:36:33 s/same?/same 16:36:47 point of clarification: same as each other, not necessarily the same as they are now 16:37:17 RESOLVED: keep the two interfaces the same as each other 16:37:43 Rossen_: Now let's move on to what the same means 16:37:43 q+ 16:37:46 Option 1: Both .sS and .aSS use StyleSheetList; ShadowRoot gains methods to mutate .aSS 16:37:46 Option 2: Both .sS and .aSS use a readonly ObservableArray; ShadowRoot gains methods to mutate .aSS 16:37:46 Option 3: .sS is upgraded to a readonly ObservablyArray; .aSS is an ObservableArray 16:38:05 ack hober 16:38:19 hober: One way to keep the same is for both to be read only which implies mutation of adopted stylesheets would be by some other means. I think that's option 2 of what TabAtkins typed 16:38:21 TabAtkins: Yep 16:38:47 q+ 16:39:27 TabAtkins: Making read only observable that's only available by out of band method seems bad. Whole point of observable is it's mutable. If you're doing exactly obserable but moving mutable somewhere else I don't see the point of that. To be slightly impolite hober it seems assinine. 16:39:56 ack Domenic 16:40:05 q+ 16:40:06 Domenic: Another dimension is consistency with rest of platform. There's a lot of arrays that would like to be with observable and would use the full observable approach. If we look at the 20-ish APIs that would want to do this observable array will be the best bet there 16:40:10 q+ 16:40:17 ack rniwa 16:40:45 rniwa: I wanted to say there's no proof that would happen. We have not done deep studies if that's possible. So removing the other idea isn't a good idea for that reason 16:40:59 Domenic: We can delay until we deploy this for html since it's backwards compat there 16:41:07 ack chrishtr 16:41:26 chrishtr: Question on reason to consider option 2 as opposed to option 3. Am I correct conern is about race conditions? 16:41:37 TabAtkins: No, that's about assignment question which is after this stuff. 16:41:47 chrishtr: assignment is also race consitions? 16:42:03 TabAtkins: Assignment is only race conditions. This has nothing to do with race conditions 16:42:12 chrishtr: hober why prefer option 2 over 3? 16:42:46 hober: Trying to find a middle ground between A Coruna resolution and what TabAtkins proposed. Thought in doing that was to have stronger consistency between exsiting object and the new thing then in TabAtkins proposal 16:42:52 chrishtr: b/c more read only? 16:43:14 hober: One of the ways, yes. Another is they both have weird legacy document.stylesheets has. If you're already using it you know how to use it 16:43:25 Domenic: document.stylesheets only has one item. Not a big mismatch 16:43:33 s/one item/one method: item()/ 16:43:55 hober: People are used to coding to document.stylesheets when they want to interrogate. Making the new thing consistent with that is of high value. More likely people can resuse code with small modifications 16:44:06 hober: Also argument to collapse 2 and 3 if you're willing to add ident 16:44:28 Domenic: Way I'm going. We could go to T39 and ask to add item method to array. Then it's consistent between every array on platform 16:44:36 TabAtkins: Observable array exends.. 16:44:40 Domenic: Doesn't it is an array 16:44:56 TabAtkins: On hober note I guess a lot of the legacy items have .item 16:45:06 hober: Right. Helps observable be a good substitutue 16:45:25 Domenic: Right. SHould go to T39. Add counters too for usage. BUt going to T39 is safer. 16:45:37 Rossen_: Until have resolution from TC39 which way to go? 16:45:47 q? 16:45:57 TabAtkins: If observable is just an array it's still possible to sub-class and add a .item method for use of document.stylesheets 16:46:04 Domenic: Not possible now but could add 16:46:17 TabAtkins: Lothe to upgrade docuemnt.stylesheet if remove method 16:46:42 Domenic: Three paths to that. use counters and remove if no usage, T39 adds it. Third is add a subclass adhoc 16:46:47 TabAtkins: That third is my preferred 16:47:00 rniwa: Object to try and remove ident 16:47:06 s/ident/item/ 16:47:09 Domenic: We can measure and see usage. Might be moot 16:47:21 TabAtkins: Without data we won't remove .ident 16:47:42 s/.ident/.item/ 16:48:05 TabAtkins: I propose we take obserable array, subclass to add.ident. Keep both consistent. There's already people rpoposing to add this method and I can lend support to that and chamption in TC39 16:48:13 s/ident/item 16:48:23 TabAtkins: It's option 3 but make sure document.stylesheet has ident 16:48:30 chrishtr: hober and rniwa okay with this? 16:48:40 hober: It's an improvement on previous option 3 16:48:41 s/document.stylesheet/document.adoptedStyleSheets 16:48:47 rniwa: That's the option? 16:49:07 TabAtkins: #3 but for both we use a subclass with .ident so we maintain compat 16:49:19 rniwa: IMprovement but we still have issue of assigment 16:49:30 TabAtkins: Yes, but that can go either way regardless of what we decide 16:49:52 rniwa: Not sure. Someone arguement mutable could be made the same. If someone is making that argument we need to discuss together 16:50:04 TabAtkins: Assignment is if it's ddeclared read-only. Nothing to do with reach interface 16:50:24 chrishtr: rniwa point is valid. It's possible to have race conditions when splicing in using similar syntax 16:50:33 Domenic: Also with methods proposed adding to shadow root 16:50:46 TabAtkins: All apply equally well regardless of the method we choose here 16:50:56 rniwa: Don't see why issue. Adding I'm not sure how it's racy. 16:51:18 TabAtkins: A await in an argument list is racy because pauses in middle of argument 16:51:39 Domenic: Array starts in one state, you try and add, your program pauses, you then add and array is in a different state 16:52:34 rniwa: THat's not the race. If someone has stylesheet h1 and h2, someone adds h3, you have a wait, someone adds h4. You could end us with s1 s2 and s4 but not s3. If you have method to add a stylesheet you're not removing anything. [??] 16:53:15 TabAtkins: But that can only plausably happen with old frozen array. Only way to append is read, make a new, and then assign it. If you had to wait in there underlying data could change. That is still a thing you can do if you assign but it's weird when you can push to the array. 16:53:51 Ryosuke's concern is `.aSS = [...document.aSS, await s4]` 16:54:00 Domenic: Problem before is assignment was overused. It has valid uses but when overused it introduces races. Point of this is to minimize the overuse of assignment when you can use .push 16:54:02 Which you'd just do as `.aSS.push(await s4)` 16:54:20 rniwa: Previous argument that we should allow assignment so I don't see how I can argee with your argument 16:54:39 TabAtkins: If it's assignment allow is if we put read-only on. Either way we can allow direct assignemnt 16:55:30 rniwa: Arguement made in how to solve race condition people argued it exists due to this approach. You'r saying they're independent but other say they're the same. If we resolve mutable array will never use argument for assignment ever maybe, but how do you enforce that? I don't know. I don't think I can agree 16:55:52 TabAtkins: I rpomise you we will not use this resolution as input to if it should allow assignment. If I promise you that they should be separable, right. 16:56:11 rniwa: If WG agrees maybe. But if it allows [missed] it's also race 16:56:24 TabAtkins: But every array has a possible race if you splice and wait 16:56:58 rniwa: Evidence people are writing racy code. I don't see why this is better then option 2 which does not have that issue. Why adding API where even those that are experts write racy code? 16:57:35 TabAtkins: Because not our place to say all JS is wrong and we produce a new type of array. TC39 is right arbiter of that. It effects all JS arrays. We shouldn't do awk API contortions to reflect this. 16:58:05 Rossen_: Couple minutes remaining. rniwa are we ready to get to resolution of modification for #3? 16:58:21 rniwa: I think there is an issue with race condition. At this moment I'm not comfortable with that resolution. 16:59:00 Rossen_: Options are stay with A Coruna resolution. We did record to keep them same. Folks will follow up with TC39 and see about adding .item. 16:59:14 Rossen_: Any other resolution we can take now? If not we can move on 16:59:26 TabAtkins: No, we can't decide on any resolution until they're all decided. 16:59:33 Rossen_: Then we'll end here. 17:00:13 Rossen_: astearns made a good observation to use this as a virtual F2F tryout. If people are interested in doing this in a breakout I'm happy to make this an experiment 17:00:17 hober: I think break idea 17:00:21 rniwa: Sounds great 17:00:26 s/break/a great/ 17:00:27 s/break/great 17:00:42 Topic: end 17:01:22 Karen has joined #css 17:01:49 Rossen_: We have to care enough not just CSS itself. object model is important in how people use CSS and make it successful. DOn't often have API related discussion in that depth. I know some members are expressing concerns on how the call went but this is fundamental part of CSS we need to make platform successful 17:02:04 Rossen_: Thanks to everyone who called in and participated. 17:02:32 Rossen_: If people want to make this in virtual F2F please chime in on mailing list. TabAtkins and hober can wrangle people 17:07:23 Zakim, end meeting 17:07:23 As of this point the attendees have been dael, Rossen_, rachelandrew, dauwhe_, AmeliaBR, plinss, florian, dbaron, chrishtr, dholbert, antonp, lajava, jensimmons, miriam, Domenic, 17:07:26 ... astearns, fantasai, rniwa, oriol, TabAtkins, emilio, GameMaker, drousso, iank_, cbiesinger, hober, chris 17:07:26 RRSAgent, please draft minutes 17:07:26 I have made the request to generate https://www.w3.org/2020/03/25-css-minutes.html Zakim 17:07:28 I am happy to have been of service, Rossen_; please remember to excuse RRSAgent. Goodbye 17:07:32 Zakim has left #css 17:20:01 fantasai: Consider setting up a "mentions" filter ("mentions@noreply.github.com" showing up in the cc list)? I find it really helpful to spot things I should pay more attention to. 17:23:16 Yeah, same. But the "mention" label at least helps me prioritize, and catch issues that I would normally have ignored/skimmed. 18:39:54 I've set up good email filters for github, and I think the appropriate set of emails are getting into my primary inbox, but I end up ignoring them anyway because the subject lines are garbage... 18:40:16 I'm trying to teach myself not to ignore them, with only middling success. 18:40:55 e.g., what I see is something like "Re: [w3c/csswg-drafts] [cssom-view] Let offsetWidth / offsetHe" 18:41:14 lol what are you getting those from 18:41:34 that's the subject line of the github email, truncated to the width that I actually see in my client 18:41:47 oh, ok, so the truncation is on your end 18:41:50 or "Re: [w3c/csswg-drafts] [css-backgrounds] 'border' shorthand re" 18:42:01 Yeah I imagine that's less than useful, heh 18:42:09 yeah, my problem is that there's so much garbage at the beginning of the subject that it's no longer useful 18:46:34 I'd say your problem is your truncation strategy, but yeah. 18:51:29 I mean, I guess I could read email in a maximized window, but I'd prefer not to? 18:51:47 I guess your client doesn't support linebreaking the titles? 18:52:12 not in the view of a folder/mailbox 18:52:39 Yeah, that's unfortunate then 19:01:11 myles has joined #css 19:19:04 Tavmjong has joined #css 19:25:26 Tavmjong has joined #css 19:47:22 Tavmjong has joined #css 21:17:17 Karen has joined #css 22:14:53 fantasai: fyi I filed https://github.com/w3c/csswg-drafts/issues/4901 22:15:28 TabAtkins: uh, what client does support linebreaking email subjects? 22:16:27 Ah, hm, I suppose gmail doesn't do so on desktop. I just always have it fullscreen so I didn't notice. ^_^ 22:16:38 And hm, it doesn't do it on mobile either, wtf, why are all these things useless 22:16:52 Mobile linebreaks the summary, but not the title. 22:19:52 Karen has joined #css 23:47:21 Karen has joined #css