22:57:30 RRSAgent has joined #css 22:57:30 logging to https://www.w3.org/2019/08/07-css-irc 22:57:32 RRSAgent, make logs public 22:57:32 Zakim has joined #css 22:57:34 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 22:57:34 Date: 07 August 2019 22:57:41 bdc has joined #css 22:58:13 present+ 22:58:18 ScribeNick: dael 22:58:34 bkardell_ has joined #css 22:58:39 present+ 22:59:55 smfr has joined #css 23:01:32 present+ 23:01:41 present+ 23:01:50 astearns: We'll wait a few more minutes. There were a lot of regrets today 23:01:57 present+ 23:02:05 present+ 23:02:09 present+ 23:02:14 Rossen_ has joined #css 23:02:18 present+ 23:02:20 present+ myles 23:02:20 astearns: For those that are on, look who else is on and look through the agenda for items that could get some useful work done with the group we've got on. 23:03:01 birtles has joined #css 23:03:11 Present+ 23:03:31 present+ 23:03:52 estellevw has joined #css 23:04:12 astearns: Let's get started 23:04:17 Topic: Charter Update 23:04:24 AmeliaBR has joined #css 23:04:31 https://w3c.github.io/charter-drafts/css-2019.html 23:04:32 astearns: xfq ay update or anything you need from me or Rossen_ ? 23:04:39 xfq: Link to current draft^ 23:04:44 https://github.com/w3c/charter-drafts/issues?utf8=✓&q=is%3Aissue+is%3Aopen+csswg 23:04:51 heycam has joined #css 23:04:52 xfq: Nothing needed from chairs. Here ^ is open issues from florian 23:04:57 present+ 23:05:04 xfq: Agree with testing policy change. haven't done it yet 23:05:26 present+ 23:05:32 xfq: Delays of horizontal review haven't made the change b/c likely to get obj from horizontal groups. Not a blocker of w3c mgmt review. 23:05:54 xfq: W3C doesn't have mgmt meeting this week. I will request review next week. If it gets approved will start AC review soon 23:05:54 https://github.com/w3c/strategy/issues/188 23:06:19 xfq: Had a comment ^ from Richard that it would be good to group deliverables into WD & CRs. I don't object. If no objections I can do that 23:06:41 astearns: I like Richard's suggestion. I would put CRs at the top so stuff furthest along is at the top. 23:06:49 xfq: Looks good to me 23:07:18 astearns: For horizontal review might be good to go with template and open florian issue on template itself to get wider discussion on how things should get processed 23:07:27 astearns: Sounds great to get review started next week 23:07:35 astearns: Any other issues on the charter please open on the repo 23:08:05 astearns: Anything anyone would like to add or amend to the agenda? 23:08:10 fantasai: I've only got 20 minutes 23:08:17 images stuff and text-decor 23:08:19 astearns: fantasai anything you want to get to in your 20 minutes? 23:08:24 Karen has joined #css 23:08:35 present+ 23:08:36 astearns: Everyone else please look at issues and if an issue is fantasai related move it up 23:08:53 fantasai: Images, text-decor, Lists 3 on counter 23:08:58 astearns: So follow first 4 items 23:09:05 astearns: Other re-ordering? 23:09:13 fantasai: Let's pull #13 above text-decor 23:09:20 fantasai: I think after that can repub images 23:09:23 Topic: Specify fallback behavior when replaced or background image content not available 23:09:31 github: https://github.com/w3c/csswg-drafts/issues/1984 23:09:48 astearns: TabAtkins added but he's IRC only 23:09:54 fantasai: Have some discussion from last week 23:10:09 fantasai: Wanted to get WG review I believe. Then we were supposed to make edits 23:10:14 astearns: Needs edits tag was removed 23:10:17 fantasai: I'll fix that 23:10:24 astearns: Maybe were edits...There is a PR 23:10:27 https://github.com/w3c/csswg-drafts/commit/73d7635574d54f5afb154b5bcf24a2fc086e2093 23:10:46 AmeliaBR: There were edits 3 weeks ago discussed last week. nothign since last week 23:10:54 Topic: none 23:10:55 Github: none 23:11:26 Topic: Rename `text-decoration-thickness` to `text-decoration-weight`? 23:11:43 Topic: Should CSS decorative images respect EXIF-orientation by default 23:11:51 github: https://github.com/w3c/csswg-drafts/issues/4165 23:11:56 astearns: Added by smfr 23:12:34 smfr: Cleaning up issues for if images respect EXIF. Question came up if decorative ones should respecte exif. Should we allow authors to control orienation in decorative images? 23:12:47 smfr: Simple question is do decorative images respect exif by default 23:13:14 AmeliaBR: I think default behavior should be to respect it, esp if that's the default for content images. We should be consistent unless there is webcompat reasons 23:13:28 AmeliaBR: Like having extra param that can change things. Adding the extra shouldn't delay spec default 23:13:44 fantasai: Default behavior will have to go in L3, image function is in L4 so it would go there 23:14:02 smfr: One data point I don't think w have web compat data b/c no platform has respected exif for decorative images by default 23:14:17 astearns: Disctinction between content and docorative is backgroud? 23:14:27 smfr: Yeah. Content images are images in replaced elements 23:14:59 AmeliaBR: Instead of decorative we should say css images. Images spec through css prop. Exception is content property. New image orientation would effect images embedded using content 23:15:33 fantasai: Yeah. Early defined replaced to work using content property. Def interchangable. List markets and background images and stuff are not replace in box tree. Content images are 23:15:43 smfr: Images in SVG too which we haven't talked about 23:15:58 s/New image orientation/New image-orientation property/ 23:16:10 astearns: Concern was on compat for spec default to honor exif. Do you have any idea of what % images used on web have exif data? 23:16:42 smfr: TabAtkins had data. It's less common to use thing with exif data as decorative. I'm not as concerned as I was with content images. We can try and see what happens 23:17:05 astearns: I know people use background image for content data. I think it would be surprising to take a URL that's an image, but it in background and it flips 23:17:17 Yeah agree. 23:17:18 fantasai: Agree with AmeliaBR default should be consistent between all the images 23:17:27 Should agree unless there's compelling compat data. 23:17:27 smfr: Happy to resolve now and come back if compat 23:17:42 astearns: Prop: default behavior for all images to respect exif orientation 23:17:49 astearns: Additional concerns? 23:17:51 astearns: Obj? 23:18:00 RESOLVED: default behavior for all images to respect exif orientation 23:18:19 astearns: My understanding is we do not yet have param in image function to override in next module 23:18:50 fantasai: No. Inclination is not to add unless authors say they want this. We've historically had problems getting image-orientation impl so I'd rather not add without demand 23:19:04 s/image-orientation/image()/ 23:19:22 AmeliaBR: Have vauge resolutions to add params to control image for things like lazy-load. Once we get all that ecosystem of params maybe this gets added in if there is demand 23:19:45 astearns: Seems fine place to leave it. Anyone want to fight to put in a param now? 23:19:51 tantek has joined #css 23:19:53 smfr: I think it's fine. Agree with fantasai to wait 23:19:55 present+ 23:20:17 smfr: It is odd we have image-resolution apply to all aster but image-orientation is content images. Should think in the future 23:20:25 AmeliaBR: Re-access image resolution? 23:20:38 smfr: I would go in other where image-orientation should effect all images. 23:20:58 astearns: Since we're consistent in orientation data, consisten in orientation prop makes sense 23:21:46 fantasai: Reason why not is that images typically come from different sources. Might have a bunch of SVG used for background or border. NOt going to want to have that roate but might correct rotatio os a photograph. Discussed this in the past and decided does not effect anything other then content and images 23:22:20 fantasai: Makes sense to be consistent on exif. I don't think explicit values need to be everywhere. I don't think orientation wants to effect decorative and content 23:22:32 smfr: from-image is the only one you'd care abuout for css images 23:23:12 AmeliaBR: ONly you can assume applies to many images. If you had content and bg images wouldn't nec. align. Prob try for image-resolution prop. might be worth considering finger grain control there. I don't know if there are impl of that to get author feedback 23:23:38 fantasai: Idea was for css images that we would address use case to override explicit orientation through image() 23:23:51 astearns: Sounds like we're toward no change for rest of questions in issue. Correct? 23:24:18 fantasai: Open to adding image oritentation overrides in image() if there's demand. Defeault is respect exif 23:24:24 astearns: Then let's close this issue. 23:24:31 Topic: publication 23:24:42 fantasai: Just need to make edits for first 2 issues so next week 23:24:47 astearns: And for this issue as well. 23:25:00 astearns: Please take a look at images 3 and likely will call for republication next week. 23:25:19 For reference, DoC is at https://drafts.csswg.org/issues?spec=css-images-3&doc=cr-2012 23:25:38 Topic: need for clarification on how ::selection text-shadows work 23:25:47 github: https://github.com/w3c/csswg-drafts/issues/3932 23:26:39 fantasai: I was going over what we want for text-shadows. Came up with a bunch of questions for ::selection text-shadows 23:27:04 fantasai: Last time we discussed only thought about ::selection but have multiple highlight pseudos that can layer. Models discussed don't make too much sense. 23:27:11 https://github.com/w3c/csswg-drafts/issues/3932#issuecomment-510220043 23:27:25 fantasai: Summary ^ 23:28:16 fantasai: Default case selection with a background suppresses text-shadows because otherwise might not get enough contrast. Spelling and grammer do not suppress text-shadows. Need to make it that having a highlight there shouldn't suppress text-shadow below 23:28:39 fantasai: 2 models. Any non-transparent background disables shadows on layers below. Background on any paints over layers below. 23:29:00 fantasai: Highlight pseudos might want to change order and paint background inbetween 23:29:26 fantasai: There are questions on multi-layers with text-shadows and they all spec text shadow do we draw top most non-none? All? 23:29:38 fantasai: I don't have a clear answer to these questions so I want feedback from WG 23:30:09 AmeliaBR: I don't think have any other way in CSS where you can composit together text-shadow from different declarations 23:30:53 fantasai: Right, because shadows inherit. Parent inherits to child so shadow takes effect on child unles syou do something. Here is a bunch of layers without parent/child so no clear inheritence. But we don't want something like spelling-error to prevent a shadow 23:31:15 s/shadow/shadow just because it now exists/ 23:31:20 AmeliaBR: As with everything on selection highlight classes I wish we could make sense of this in normal cascade way. I think trying to draw 2 text shadows on same text is strange. 23:31:49 AmeliaBR: For background layering multiple backgrounds seems to make sense. Question of if it's performant to draw shadows that will be obsurced. 23:32:11 fantasai: I don't care if we draw background over or don't draw because the background will obscure. Either gets reasonable behavior 23:32:36 astearns: Main thing is pick easily impl and can be consistent. Seems edge case b/c selection happens on editable text. 23:32:44 fantasai: COuld select to copy out. THat's frequent 23:32:55 smfr: Some add funcky text shadow to change anti-aliasing 23:32:58 astearns: ooh, fun. 23:33:37 smfr: I'm confused about how thigns are supposed to work. Understand text-shadow style gets cascade into text-shadow on elemnt and paint result. fantasai sounds like saying selection has own text-shadow style hence the layers 23:34:01 fantasai: Didn't quite follow. In this case you have a word and it is a spelling error and a grammar error and it's selected. 23:34:35 fantasai: Properties on each pseudo element cascades in and inherited through...trying to remember b/c changed...[reads spec] 23:35:36 fantasai: You aren't going to have the text-shadow value inherit from base document element. Properties are inherited from parent. Each element has own ::selection and the ::selection of span inherits from ::selection of p which inherits from ::selection of body. Text-shadow around that word text-shadow prop won't have that value on it. 23:36:15 fantasai: If going to draw text we would see text-shadow:none and that's not okay for spelling error. You don't expect a spelling error to suppress shadows. Even though spelling errors don't have text-shadow you want to draw the shadow 23:36:20 https://drafts.csswg.org/css-pseudo-4/#highlight-cascade 23:36:29 smfr: It's about the decoration style clobbering the text-shadow of unselected version 23:37:00 fantasai: Could do it for selection, but not for spelling and grammar. Making it disappear with only difference is underline doesn't make sense and could make text unreadable 23:37:17 smfr: Impl no problem paining multi shadow. Prefer to avoid complex logic if thigns are transparent 23:38:03 fantasai: 2 related questions. 1: How do we deal with suppressing shadows when drawing background b/c selection has background. Can do that by saying if bg in non-transparent we don't paint shadows below. Or paint shadows first and then paint background 23:38:08 smfr: bg may nto be opaque 23:38:14 fantasai: Right. Or smaller then text-shadow 23:38:38 fantasai: You could dsitinguish between two, but difference isn't that important question of what's easier to implement 23:38:55 smfr: Want to look at native platform to see if those make sense and should be matched 23:39:59 fantasai: Second question is if we have multi-layers spec text-shadow. So author decides spelling error creates a blurred red ext-shadow and grammar is green shadow and selection is orange shadow, do we draw all or only top most non-none? 23:40:09 smfr: I think draw all. Draw what author asked for 23:40:25 smfr: Mac native does paint text shadow under selection, I think. You do get combination 23:40:35 fantasai: Prop: If multiple layers with text-shadows we draw them all 23:40:40 fantasai: Resolve on that? 23:40:45 astearns: Objections? 23:40:53 RESOLVED: If multiple layers with text-shadows we draw them all 23:41:15 fantasai: Background either suppress or paint over lower level, I think smfr suggests we paint over? 23:41:17 smfr: Yes 23:41:30 fantasai: Background on a highlight layer paints over shadows on layers below 23:41:32 astearns: Obj? 23:41:40 RESOLVED: Background on a highlight layer paints over shadows on layers below 23:41:47 I'm not crazy about the background painting over thing. 23:41:52 astearns: Is that enough to spec interop? 23:41:56 seems like the shadows may well peek out at the edges. 23:42:03 fantasai: THat's enought o spec. Interop depends on impl. 23:42:16 astearns: There are test cases I expect will need to be ammended to cover 23:42:18 fantasai: Yeah 23:42:28 (I'm listening, but I'd need to reconnect in order to unmute) 23:42:50 astearns: dbaron you mentioned you're not crazy about peaking out? I believe that is the case and shadows will show if larger then background 23:43:00 fantasai: I don't care which way it goes between the 2 23:43:09 as long as we have an answer 23:43:17 astearns: Let's go with that option. dbaron if you have a change or obj please update the issue 23:43:21 yeah, I don't feel that strongly, but the behavior seems a bit ugly 23:43:23 Also OK if we want to make it a UA choice between the two 23:43:25 astearns: Anything else on this? 23:43:33 just so long as it's only those two options and not "do anything" :) 23:43:56 Topic: Rename `text-decoration-thickness` to `text-decoration-weight`? 23:43:58 github: https://github.com/w3c/csswg-drafts/issues/4138 23:44:37 astearns: jen suggested weight b/c typographic term. We have width, thickness, and weight as possibilities for the prop that determines how wide/thick a text underline is 23:44:44 astearns: Opinions on what we should do? 23:44:53 myles: We shipped thickness. Pref no change 23:44:56 astearns: Anyone else? 23:45:09 I prefer no change 23:45:19 (I prefer we'd kept it as 'width', but oh well.) 23:45:19 https://github.com/w3c/csswg-drafts/issues/4138#issuecomment-517121344 23:45:21 fantasai: I personally favor width b/c every other line thickness in css is width and that's helpful to authors 23:45:32 fantasai: bradk said same ^ 23:45:34 +1 fantasai 23:45:51 heycam: Prefer not to change here. I'd like to stick with [missed] 23:46:03 AmeliaBR: Would have leaned width, but not worth changing shipped impl 23:46:14 seriously how did we all screw this up? 23:46:19 astearns: I believe heycam wanted preference for width 23:47:01 astearns: jen suggested weight b/c it's typographic. Somewhat against because we don't use it for line thickness elsewhere. Font has more then line thickness 23:47:08 myles: Also 400 is reasonable weight 23:47:22 astearns: Should reject weight. Have people on both sides of width and thickness 23:47:43 outline-width etc. 23:48:02 fantasai: Sympathetic that we impl and shipped. Inconsistency will effect authors going forward and will have to remember this is only one that has a different name for what it's doing. THat's an ongoing cost 23:48:35 devin: Would argue it's different. Thickness of line under text I don't think is a width. border-width is how wide is it. Underline people think thick or heavy 23:48:55 agreed with fantasai, for non-native English speakers, it makes no sense to appeal some minute difference of meaning between thickness and width 23:49:00 fantasai: majority of people don't speak english, they're looking for patterns. It's just another line. 23:49:09 myles: Value in css matching coloqueal talk 23:49:12 tantek: https://github.com/w3c/csswg-drafts/issues/3118#issuecomment-432288810 23:49:15 fantasai: Yes. And in css matching itself 23:49:38 astearns: tantek asked for where we resolved on thickness 23:49:52 s/And in/But higher value in/ 23:50:12 myles: At f2f, forget location. Did twitter poll asking people what width means, horizontal distance or vertical distance of line. 60/40 split with 60% being wrong answer 23:50:32 atrigent_ has joined #css 23:50:49 wow those linked minutes do not have any reasoning for thickness 23:50:52 that's really bad 23:51:15 astearns: I'm torn. Like consistency, but things are shipped. I'm inclined to leave things as they are with thickness. It's poss a mistake and we need to create line-weight alias 23:51:16 https://lists.w3.org/Archives/Public/www-style/2018Dec/0004.html 23:51:23 "shipped" is not good enough 23:51:26 webcompat would be 23:51:31 fantasai: We won't make an alias. We'll either get this right now or we live with this 23:51:39 myles: Agree. If we didn't do font-stretch we won't do this 23:52:00 astearns: tantek in IRC says shipped isn't enough, should only consider web compat. Do we have content using this? 23:52:08 fantasai: Hardly any I think, shipped recently 23:52:14 myles: We did resolve before we shipped 23:52:34 tantek: There's no reasoning in that, not even a straw poll. I think we should throw that resolution out. I don't trust it. 23:52:39 myles: You were in the room tantek 23:52:44 tantek: I don't remember it. 23:52:56 astearns: I remember more discussion that in minutes, but it was short. 23:53:14 tantek: Well, it was scribed more now then it was then 23:53:54 tantek: We had resolution on some discussion. I see a non-trivial amount of folks uncomfortable after the fact. I'd request a straw poll to see if it's a few of us uncomfortable or if it's wider questions of the resolution 23:53:58 astearns: Can straw poll 23:54:25 Rossen_: We don't have as many people as compared to other calls. If this is problematic resolution let's push to next week with more people and give a week to think 23:54:36 tantek: I don't disagree, but doesn't conflict with my straw poll 23:54:53 14 23:54:56 fantasai: 1 23:54:56 astearns: For people on call to get tone of room. Please type 0 if don't care. 1 if prefer width. 2 if you prefer thickness 23:54:57 0 23:54:58 bradk: 1 23:54:58 2 23:54:59 2 23:55:00 2 23:55:02 2 23:55:02 0 23:55:03 2 (because I prefer not changing) 23:55:03 1 23:55:16 2 (because i'd rather not change) 23:55:19 0 23:55:23 0 23:55:26 0 23:55:26 1 / 0 (weak preference) 23:55:39 astearns: People on call slight preference for no change 23:56:00 astearns: Let's set this to go over next week with more people on call. Decision will be keep thickness or change it back to width 23:56:02 I'm not seeing fantasai or tab on the poll who previously said 'width' in the above 23:56:06 slight/weak preference prob, but I said 0 because i think it is weak 23:56:32 Topic: What happens to the wavy & double lines when `text-decoration-thickness` is applied? 23:56:42 github: https://github.com/w3c/csswg-drafts/issues/4134 23:56:56 astearns: Should we spec how wavy lines should be drawn? 23:57:28 heycam: More control over these thigns, more authors will expect specific effects. Presence of thickness will make people aware of difference in render for wavy lines 23:57:47 AmeliaBR: Agree something should be spec. No strong opinion of what. Clear rendering def is worthwhile 23:58:02 Rossen_: Any expectation that this property will be different then stroke? 23:58:28 fantasai: Yes b/c when scaling stroke thickness you're not changing path. Here you expect thickness of line and size of wave will scale 23:58:37 Rossen_: Suggestion is botht he control points and stroke change? 23:58:49 more thickness = lower frequency? 23:58:53 fantasai: Yeah b/c if you don't change control points you just get a thick line. It is spec as wavy line 23:59:19 tantek: more thickness = more amplitude 23:59:37 text-decoration-radius? 23:59:50 :( 00:00:04 AmeliaBR: Better compare at least for double line is double borders where as you scale up the total width of broder is devided between wo strokes and pace between. I'd expect that for double line. Wavy I'd expect waves to take full width. If the waves stretch to keep rpoportional curve that's unspecified since we don't define what it is to start with. 00:00:53 Rossen_: I'd be interested to hear behavior on differen platforms. Desktop word when scaling overall text the thickness and waviness of underlines does not change. Consistent across office products. Curious if different 00:01:39 rossen, the issue here is that the thickness of the underline is specified to change, in that case we can't be consistent with the platform if the platform isn't changing the thickness 00:01:59 myles: Couple points. Straight double underlines we've got platform conventions for position. Shouldn't spec gap. Wavy underlines a use case is spelling market or cjk names/titles as an honorific. The shape of those might intend to be different. SHould't give amplitude and frequency controls. If give controls should be for semantic. 00:02:10 myles: I don't see authors asking for high level of control on shaping underline 00:02:32 astearns: I don't think talkign adding properties. Just specifying something so get slightly mroe consistent rendering across brwosers and platforms 00:03:30 fantasai: Might need to jsut spec that for wavy lines that thickness of line as well as amplitude and frequency are meant to scale up. UA can adjust and it doesn't have to be a linear curve. If you're increasing thickness of line then amplitude and frequency needs to scale up 00:03:55 fantasai: Can say something similar for doubling. THickness of 2 underlines and space between should scale. Should look good in large font sizes. 00:04:02 astearns: We're past time. We should close this. 00:04:12 astearns: fantasai can you come up with a proposal for what to do? 00:04:21 fantasai: If people are happy with the general guidlines I can draft 00:04:36 astearns: Draft it, put in issues, and then we'll agenda+ for specific text 00:04:54 fantasai: Agree with myles shouldn't spec exact curves and amplitude. 00:04:56 topic: end 00:05:14 astearns: THanks everyone for calling in and letting me go a bit over. We'll talk next week. 00:08:17 Rossen__ has joined #css 00:10:50 Karen has joined #css 00:18:18 estellevw has joined #css 00:55:14 estellevw has joined #css 02:25:43 estellevw has joined #css 02:45:16 dustinm has joined #css 03:04:34 dustinm has joined #css 04:07:22 estellevw has joined #css 04:30:58 Zakim has left #css 05:22:11 rego has joined #css 06:18:19 estellevw has joined #css 06:28:24 estellevw has joined #css 07:09:20 drousso has joined #css 08:19:03 drousso has joined #css 08:55:33 lajava has joined #css 10:02:42 projector has joined #css 10:03:12 Rossen has joined #css 10:03:43 shans has joined #css 10:04:13 sylvaing has joined #css 10:05:14 leaverou has joined #css 10:05:44 plinss_ has joined #css 11:03:20 lajava has joined #css 11:11:05 Ms2ger has joined #css 11:19:18 antonp has joined #css 11:59:24 Karen has joined #css 12:01:53 lajava has joined #css 12:53:10 lajava has joined #css 13:53:20 Karen_ has joined #css 13:57:59 nigel has joined #css 14:00:08 anssik has joined #css 14:54:20 florian has joined #css 15:03:20 estellevw has joined #css 15:42:48 lajava has joined #css 16:41:30 drousso has joined #css 16:50:34 jamesn has joined #css 17:11:59 estellevw has joined #css 17:14:23 atrigent_ has joined #css 18:04:52 lajava has joined #css 18:14:59 estellevw has joined #css 18:17:59 liam has joined #css 19:41:19 estellevw has joined #css 19:46:12 estellevw has joined #css 20:02:15 drousso_ has joined #css 20:22:47 antonp has joined #css 20:39:04 drousso has joined #css 20:59:29 estellevw has joined #css 21:23:43 https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/CSSModules/v1Explainer.md might be of interest to folks here 22:42:47 estellevw has joined #css 23:14:34 birtles has joined #css 23:19:53 estellevw has joined #css 23:42:16 aja has joined #css 02:00:51 drousso has joined #css 02:06:30 atrigent_ has joined #css 02:27:25 estellevw has joined #css 02:39:46 estellevw has joined #css 03:02:58 dauwhe has joined #css 03:37:39 atrigent_ has joined #css 03:38:56 dauwhe has joined #css 03:46:33 dauwhe has joined #css 03:49:48 drousso has joined #css 03:59:16 drousso has joined #css 04:03:08 drousso_ has joined #css 04:03:56 dauwhe has joined #css 04:05:16 dauwhe_ has joined #css 04:08:41 estellevw has joined #css 04:21:30 estellevw has joined #css 04:30:50 estellevw has joined #css 04:35:56 dauwhe has joined #css 04:42:00 dauwhe_ has joined #css 04:52:37 dauwhe has joined #css 05:38:32 drousso has joined #css 06:53:29 dauwhe has joined #css 07:46:05 dauwhe has joined #css 07:53:41 dauwhe_ has joined #css 08:03:43 Ms2ger has joined #css 08:04:28 dauwhe has joined #css 08:46:52 antonp has joined #css 08:55:13 lajava has joined #css 09:08:54 drousso has joined #css 09:26:12 projector has joined #css 09:26:43 Rossen has joined #css 09:27:13 shans has joined #css 09:27:43 sylvaing has joined #css 09:28:44 leaverou has joined #css 09:29:14 plinss_ has joined #css 09:30:28 dauwhe has joined #css 09:38:30 dauwhe has joined #css 10:30:22 dauwhe has joined #css 10:32:45 florian has joined #css 11:10:40 Karen has joined #css 11:40:48 dauwhe has joined #css 11:51:13 dauwhe has joined #css 12:01:43 antonp has joined #css 12:06:31 dauwhe has joined #css 13:25:30 innovati has joined #css 13:53:07 Karen has joined #css 14:21:14 estellevw has joined #css 14:31:37 estellevw has joined #css 14:43:52 estellevw has joined #css 16:27:35 drousso has joined #css 16:32:35 Karen has joined #css 16:52:30 drousso_ has joined #css 17:05:55 estellevw has joined #css 17:21:41 innov4ti has joined #css 17:35:42 innovati has joined #css 17:42:05 drousso has joined #css 18:04:24 innov4ti has joined #css 18:07:27 plh has joined #css 18:19:47 bkardell_ has joined #css 19:20:56 dauwhe has joined #css 21:32:40 Karen has joined #css 21:37:39 innovati has joined #css 00:01:08 dauwhe has joined #css 01:48:05 dauwhe has joined #css 01:51:40 plh has joined #css 02:04:41