15:57:36 <RRSAgent> RRSAgent has joined #css
15:57:36 <RRSAgent> logging to https://www.w3.org/2021/06/16-css-irc
15:57:39 <Zakim> RRSAgent, make logs Public
15:57:40 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:58:20 <jfkthame> jfkthame has joined #css
15:58:29 <fremy> fremy has joined #css
15:59:53 <argyle> present+
16:00:10 <jfkthame> present+
16:00:25 <alisonmaher> alisonmaher has joined #css
16:00:35 <miriam> present+
16:00:36 <castastrophe> present+
16:00:37 <alisonmaher> present+
16:00:44 <Morgan> present+
16:00:55 <oriol> oriol has joined #css
16:00:56 <astearns> we will need a scribe today
16:01:11 <TYLin> present+
16:01:20 <astearns> any volunteers?
16:02:10 <dlibby> dlibby has joined #css
16:02:18 <fantasai> ScribeNick: fantasai
16:02:24 <dholbert> present+
16:02:37 <rachelandrew> present+
16:02:45 <fremy> present+
16:02:57 <dlibby> present+
16:02:59 <oriol> present+
16:03:10 <chrishtr> present+
16:03:17 <jensimmons> present+
16:03:18 <fantasai> Topic: Color Adjust
16:03:26 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6310
16:04:05 <fantasai> https://github.com/w3c/csswg-drafts/issues/6310#issuecomment-858112357
16:04:19 <Rossen_> Rossen_ has joined #Css
16:04:27 <fremy> fantasai: the current proposal is not gonna get us in good shape in all cases
16:04:40 <TabAtkins> present+
16:04:43 <fremy> fantasai: currently our resolution would not work if the svg has set its color explicitly
16:04:50 <gregwhitworth> present+
16:05:07 <sanketj> sanketj has joined #css
16:05:18 <fremy> fantasai: so my new proposal is that if the color is orginating from outside the svg then we recolor, but if not then we keep it
16:05:33 <plinss> present+
16:05:44 <fremy> fantasai: proposal is to add a new keyword for that magic behavior which depends on the origin of the value of color
16:06:00 <alisonmaher> q+
16:06:02 <iank_> I'm getting very warbled audio - is this is the for others?
16:06:04 <fremy> fantasai: (if you are not inheriting from outside, then we don't reset the color)
16:06:15 <fantasai> alisonmaher: I agree with the proposal
16:06:21 <astearns> ack alisonmaher
16:06:27 <fantasai> alisonmaher: only problem I wanted to ask about was whether we can do at computed value time
16:06:47 <fantasai> alisonmaher: if we take the used value of the color, might expose the color where otherwise wouldn't
16:06:54 <fantasai> TabAtkins: :visited won't be exposed that way
16:06:54 <smfr> smfr has joined #css
16:06:58 <fantasai> TabAtkins: that's done by selector-hacking
16:07:11 <fantasai> TabAtkins: and the rest of colors are already automatically exposed via getComputedStyle
16:07:18 <fantasai> TabAtkins: because gCS returns used value of color
16:07:19 <smfr> present+
16:07:20 <Rossen_> q
16:07:24 <fantasai> TabAtkins: so not sure there's info leakage problem
16:07:54 <fantasai> Rossen_: While we're on the topic, wrt TAG review
16:08:02 <cbiesinger> Present+
16:08:14 <fantasai> Rossen_: We convinced ourselves that having a grouping of color values that we essentially return just defaults for, and lie about the computed or used values
16:08:25 <fantasai> Rossen_: colors used for fingerprinting
16:08:30 <fantasai> Rossen_: could be a good path forward
16:08:42 <fantasai> Rossen_: These are magic values, you won't get the actual values though gCS
16:08:46 <fantasai> Rossen_: benefit of user for privacy
16:09:03 <astearns> ack fantasai
16:09:15 <fremy> fantasai: this is a different issue though
16:09:19 <fantasai> fantasai: That's a separate issue, here https://github.com/w3c/csswg-drafts/issues/5710
16:09:49 <fremy> fantasai: in that issue there are further comments there that says why it's probably not possible
16:10:00 <fremy> fantasai: but this is not linked to our current issue here
16:10:19 <fantasai> astearns: If we end up doing anything special for particular sources of colors
16:10:28 <fantasai> astearns: if we add this new mechanism, we'd have to do whatever magic here, too
16:10:44 <fantasai> fantasai: You'd also have to taint Canvas, and a lot of other things, yeah.
16:11:04 <fantasai> astearns: alisonmaher is it enough to note that, whatever protections would end up happening here also?
16:11:31 <fantasai> alisonmaher: We're storing [?] in chrome, so would be possible to do at used-value time
16:11:52 <fremy> fantasai: the issue is that would have to track this down the tree
16:12:16 <fremy> fantasai: and this type of tracking is usually done via inheritance
16:12:38 <fremy> fantasai: I don't think implementations have a special inherit for colors
16:12:45 <fantasai> alisonmaher: We inherit that info separately in Chromium
16:13:02 <fantasai> astearns: So what do we resolve to deal with this
16:13:07 <fremy> fantasai: we need to add a new value
16:13:12 <fantasai> fantasai: We need to a new value to forced-color-adjust
16:13:14 <bradk> bradk has joined #css
16:13:18 <fantasai> fantasai: as described in https://github.com/w3c/csswg-drafts/issues/6310#issuecomment-858112357
16:13:51 <fantasai> fantasai: We can call it something else, but need something that behaves like that
16:14:05 <fantasai> astearns: New value, not something to add to default?
16:14:10 <fantasai> TabAtkins: Yes, absolutely
16:14:54 <fantasai> TabAtkins: and needs to be set in default UA stylesheet for SVG root element
16:14:59 <fantasai> astearns: exposed to author styles?
16:15:07 <fantasai> TabAtkins: yes; don't want it to be special unspecifiable magic
16:15:13 <fantasai> astearns: So proposed resolution is to add this keyword
16:15:26 <bradk> bradk has joined #css
16:15:27 <fantasai> astearns: and to add that to the defautl UA stylesheet
16:15:45 <bradk> present+
16:15:49 <fantasai> RESOLVED: Add new keyword to forced-color-adjust as described above, apply it in UA default stylesheet for SVG root element
16:16:16 <fremy> fantasai: other than this issue
16:16:18 <fantasai> https://github.com/w3c/csswg-drafts/labels/css-color-adjust-1
16:16:23 <fremy> fantasai: we have no other remaining issue for the spec
16:16:32 <fremy> fantasai: so our plan is to make the edit
16:16:38 <fremy> fantasai: publish a new draft
16:16:51 <fremy> fantasai: and ask for last comments before trying to propose to make a recommendation
16:16:54 <fremy> fantasai: so, heads up
16:17:10 <fremy> astearns: and get wide review?
16:17:23 <fremy> fantasai: we already have sent an email (... missed)
16:17:26 <fantasai> https://github.com/w3c/csswg-drafts/issues/5768
16:17:28 <fantasai> in December
16:17:33 <fremy> astearns: sounds like a good plan
16:17:48 <fantasai> Topic: Compressible Elements
16:18:00 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6341
16:18:21 <fantasai> iank_: Added table kinda late, can punt to next week if we want
16:18:23 <fantasai> github: none
16:18:26 <fantasai> Topic: Transforms
16:18:55 <fantasai> sub-topic: clamping of perspective() function to >= 1px should affect interpolation
16:18:59 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6320
16:19:19 <fantasai> astearns: is dbaron on the call?
16:19:44 <fremy> fantasai: we can skip for a later time
16:19:58 <fantasai> github: none
16:20:06 <fantasai> topic: CSS Fonts 5: font-size-adjust
16:20:11 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6371
16:20:27 <fantasai> s/font-size-adjust/size-adjust/
16:20:45 <fantasai> jfkthame: We've implemented size-adjust descriptor in Firefox Nightly, and want to know if stable enough if we can ship to release
16:20:54 <fantasai> jfkthame: My understanding is that Chrome is also wanting to ship soon
16:21:00 <chrishtr> agree it's good to ship
16:21:02 <a-ja> a-ja has joined #css
16:21:09 <astearns> ack fantasai
16:21:13 <fremy> fantasai: I think the descriptor is pretty stable
16:21:26 <fremy> fantasai: the way it is defined is standard and I don't anticipate issues
16:21:34 <fremy> fantasai: so I think it's probably fine to ship
16:21:45 <fremy> fantasai: but we need to publish a First Public working draft first
16:21:51 <fremy> fantasai: this could happen very soon
16:22:21 <fantasai> astearns: Any other concerns?
16:22:30 <fantasai> smfr: let's ask Myles, he's not here today
16:22:39 <fantasai> astearns: Sounds good, also we still need an FPWD
16:22:58 <fantasai> https://www.w3.org/TR/css-fonts-5/
16:23:01 <fantasai> 404 ^
16:23:20 <fantasai> astearns: It's most important to publish FPWD, but even for a regular WD would like to publish before group says "you can ship" :)
16:23:31 <fantasai> astearns: So let's get edits in and get Myles' comments
16:23:38 <fantasai> astearns: but generally seems like it'll be OK
16:24:14 <fantasai> jfkthame: Would help to know schedule
16:24:23 <fremy> fantasai: we can get a draft within a month
16:24:33 <fantasai> Topic: Contain
16:24:39 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6287
16:24:57 <fantasai> TabAtkins: Some time ago we removed 'style' from set of containments applied by 'strict'
16:25:02 <fantasai> TabAtkins: since at-risk, unsure if FF would implement
16:25:05 <fantasai> TabAtkins: no longer at-risk
16:25:20 <fantasai> TabAtkins: Question is should we have a keyword that applies 'strict'?
16:25:27 <fantasai> TabAtkins: if so, should we add a new keyword or build it back into 'strict'?
16:25:45 <fantasai> TabAtkins: chrishtr commented that he thinks it'd be fine to add into existing 'strict', and willing to do experimentation in Chrome
16:25:50 <fantasai> fremy: I agree, makes sense to me
16:26:01 <dholbert> Sounds fine by me
16:26:12 <fantasai> oriol: Wouldn't just be strict, but also ...
16:26:24 <fantasai> oriol: content
16:26:32 <fantasai> TabAtkins: content used to be 'strict' without 'size', so add to that as well
16:26:36 <fantasai> fantasai: sgtm
16:26:55 <fantasai> astearns: so proposed resolution is to add back in style containment to 'strict' and 'content' values of 'contain'
16:26:58 <fantasai> astearns: Any objections?
16:27:06 <chrishtr> I will get this change made in Chromium asap so we can get canary channel feedback. Will report back if there are any found.
16:27:08 <fantasai> RESOLVED: add style containment back to 'strict' and 'content' values of 'contain'
16:27:16 <fantasai> Topic: Filter Effects
16:27:52 <fantasai> github: none
16:28:01 <fantasai> [Florian is not here, so skipping until next week]
16:28:24 <fantasai> Topic: cssom-view
16:28:31 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6339
16:28:38 <TabAtkins> https://wicg.github.io/visual-viewport/index.html
16:28:48 <fantasai> TabAtkins: Visual Viewport spec that allows getting bounds of visual viewport in JS
16:28:55 <fantasai> TabAtkins: has been implemented cross-browser for awhile
16:28:59 <fantasai> TabAtkins: probably should be on standards-track
16:29:05 <fantasai> TabAtkins: suggestion is to put into cssom-view
16:29:07 <fremy> LGTM
16:29:21 <astearns> ack fantasai
16:29:24 <TabAtkins> fantasai: Who's the editor?
16:29:26 <fremy> fantasai: who is gonna be editor?
16:29:47 <fantasai> TabAtkins: bokan is editor of visual viewport spec... and is a member of CSSWG
16:29:51 <fantasai> TabAtkins: could just add him
16:30:07 <fantasai> smfr: Emilio and I are editors of CSSOM-view, and would appreciate editorial help
16:30:30 <fremy> fantasai: sounds like a good idea to have one more person on this
16:30:45 <fantasai> TabAtkins: chrishtr, can we volunteer bokand?
16:31:00 <fantasai> chrishtr: We can try, and if he's busy, we'll find somone else on our staff
16:31:18 <fantasai> astearns: so propose to incorporate visualViewport into cssom-view and add bokand as editor
16:31:31 <fantasai> RESOLVED: Incorporate visualViewport into cssom-view and add bokand as editor
16:31:34 <fremy> welcome to the css family, new spec :)
16:31:44 <fremy> fantasai: one more comment
16:31:46 <dbaron[m]> Present+
16:32:05 <fremy> fantasai: it's a bit weird how things happened here
16:32:14 <fremy> fantasai: we are not doing standardization, we are doing documentation
16:32:23 <fremy> fantasai: I don't find this workflow appropriate
16:32:43 <fremy> fantasai: so I agree to do it here, but it's worth nothing I think it is not a good workflow
16:32:47 <fantasai> fantasai: It's too late to make any changes now, so what's the point of putting in a "standardization" process
16:33:11 <fremy> astearns: I agree
16:33:19 <fremy> astearns: that said, it happens, and we can't change it
16:33:25 <fremy> astearns: and documentation is still good
16:33:39 <fremy> TabAtkins: also, it shipped in multiple browsers
16:33:46 <fremy> TabAtkins: discussion happened, in another venue
16:33:58 <fantasai> Topic: Transforms
16:34:00 <fremy> TabAtkins: but patent protection was not part of this, and this is not ideal
16:34:04 <TabAtkins> Like, look at the issues list, showing definite cross-browser discussion https://github.com/WICG/visual-viewport/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc
16:34:30 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6320
16:34:37 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6346
16:34:47 <fantasai> dbaron[m]: Discussing 6320 and 6346 together
16:34:57 <fantasai> dbaron[m]: Group resolved that values less than 1px should be clamped to minimum of 1px
16:35:03 <fantasai> dbaron[m]: At the time, discussed as a render-time clamp
16:35:12 <fantasai> dbaron[m]: I tried implementing this. Believe I was the first
16:35:26 <fantasai> dbaron[m]: in the process, became clear that the time at which it became clamped was the time you convert to a matrix
16:35:36 <fantasai> dbaron[m]: problem with zero is that it puts infinite components into the matrix
16:35:42 <fantasai> dbaron[m]: There are 3 different ways convert to a matrix
16:35:47 <fantasai> dbaron[m]: 1) need to render, to find used value
16:35:53 <fantasai> dbaron[m]: 2) find resolved value for gCS()
16:36:03 <fantasai> dbaron[m]: computed value of transform function is "as specified with lengths made absolute"
16:36:08 <fantasai> dbaron[m]: but resolved value is a matrix
16:36:18 <fantasai> dbaron[m]: The third one, which is maybe more interesting, is interpolation
16:36:28 <fantasai> dbaron[m]: Perspective function gets interpreted as matrices
16:36:41 <fantasai> dbaron[m]: if you were to not clamp, and then interpolate from 0 to 2px,
16:36:56 <fantasai> dbaron[m]: entire range of animation would be clamped to 1px during render time, because animating from infinity to 0.5
16:37:04 <fantasai> dbaron[m]: which crosses 1 basically right when it gets to 0.5
16:37:20 <fantasai> dbaron[m]: Conclusion was do the clamp anytime I convert to matrices
16:37:25 <fantasai> dbaron[m]: so for gCS and for interpolation also
16:37:44 <fantasai> dbaron[m]: I've already implemented this in Canary ... does anyone think we should do something different?
16:37:49 <fantasai> dbaron[m]: not clear to me what that could be
16:37:54 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6320
16:38:28 <fantasai> smfr: Seems fine. What happens when perspective property or transform with only perspective, not converting matrices, do we need to describe beahvior there?
16:38:41 <fantasai> dbaron[m]: for perspective property, group explicitly resolved in 3084 that the animation should be different
16:38:47 <fantasai> dbaron[m]: so perspective property should interpret as specified
16:39:01 <fantasai> dbaron[m]: 2nd point, spec says that even a perspective() on its own gets interpolated as matrix
16:39:12 <fantasai> dbaron[m]: it describes the rules for interpolating matrix and perspective as the same thing
16:39:21 <fantasai> dbaron[m]: so decompose and do the pieces
16:39:26 <fantasai> dbaron[m]: for perspective it's trivial
16:39:37 <fantasai> dbaron[m]: but still the decomposition that gets interpolated is the matrix component, so ?? reciprocal
16:39:44 <fantasai> smfr: so that part is affected by your proposal
16:39:51 <fantasai> dbaron[m]: yes
16:39:56 <fantasai> smfr: I think it's reasonable
16:40:12 <fantasai> smfr: As long as we agree on where conversions to matrices happen
16:40:34 <fantasai> dbaron[m]: issues I filed are in terms of this should happen for inteprolation and this shoul dhappen or gCS
16:40:43 <fantasai> dbaron[m]: but rational was "wherever convert to matrix"
16:40:45 <fantasai> smfr: sounds fine
16:40:59 <fantasai> astearns: So original resolution for 413, did that cover resolved value?
16:41:05 <fantasai> dbaron[m]: no, said "for purpose of rendering"
16:41:16 <fantasai> astearns: so have a resolution for rendering, and you're saying extend to interpolation and resolved value
16:41:23 <fantasai> astearns: any other opinions?
16:42:08 <Rossen_> Rossen_ has left #css
16:42:35 <fantasai> astearns: ... implementation detail?
16:42:47 <fantasai> dbaron[m]: when editing spec, I'll see if it makes sense to fit that note in
16:43:04 <fantasai> [scribe missed, but guesses note was about the "convert to matrix" rationale]
16:43:29 <fantasai> RESOLVED: clamp to 1px for both getComputedStyle() and interpolation as well
16:43:39 <fantasai> dbaron[m]: possible not web-compatible, but can figure that out when we have data
16:43:54 <fantasai> Topic: font-size-adjust vs writing modes
16:44:01 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6288
16:44:33 <fantasai> jfkthame: Was working on implementing in Gecko, and it occurred to me that the behavior that falls out for the new ch and ic units probably isn't what we really want
16:44:57 <fantasai> jfkthame: if you set font-size-adjust: ch 0.4, for example, and then use vertical writing mode with upright typesetting
16:45:01 <fantasai> jfkthame: you'd get completely different scaling
16:45:09 <fantasai> jfkthame: Seems that would be unexpected and undesirable
16:45:28 <fantasai> jfkthame: Expectation would be that font + font-size-adjust should give consistent results
16:45:39 <fantasai> jfkthame: So my suggestion is that it applies in the horizontal axis
16:45:50 <fantasai> jfkthame: so not quite the same as the units
16:45:56 <fantasai> jfkthame: so maybe need to rename to make more explicit what they are
16:46:07 <fantasai> astearns: I think I'd like ch-width name
16:46:11 <fantasai> astearns: very explicit
16:46:33 <fantasai> jfkthame: We'd have the option of introducing a ch-height for vertical mode, but usage expected to be quite different
16:46:57 <fremy> fantasai: that would be more difficult than helpful
16:47:13 <fremy> fantasai: the vast majority of the authors wont need that second number
16:47:24 <fremy> fantasai: I would be ok with it if it is optional
16:47:30 <fremy> astearns: I think that was the proposal
16:47:36 <fantasai> fantasai: and sets to no effect
16:48:14 <fremy> fantasai: currently if you wanted to have an effect in the vertical axis, we have a syntax for two values
16:48:38 <fremy> fantasai: the disadvantage of that is that you might want different values for the different axes
16:49:01 <fremy> fantasai: but given few people would want to use two values
16:49:13 <fremy> fantasai: maybe we should just have one value and be clear about what it means
16:49:15 <fantasai> fantasai: and when would you know which one you want, if both are specified?
16:50:06 <fantasai> astearns: were we going to have ic-height and ic-width that can set at the same time?
16:50:10 <fantasai> jfkthame: no, just one at a time
16:50:36 <fantasai> astearns: So propoed resolution is to replace ic and ch with ic-width ic-height and ch-width
16:50:52 <fantasai> astearns: to lock things to the appropriate axis and make that explicit
16:52:05 <fantasai> fantasai: The one thing we might consider is adding 'ic' and having it compute to 'ic-width' or 'ic-height' as appropriate to the writing mode and then inherit as that computed value
16:52:22 <fantasai> fantasai: worth consideration, but I haven't thought about it much
16:52:55 <fantasai> astearns: but whatever value you add to that ic would be based on one or other metric, so unlikely to have single value that works for both
16:53:27 <fantasai> fantasai: unless you're using 1em, in which case no effect execpt for non-square fonts anyway...
16:53:33 <fantasai> jfkthame: [...]
16:53:41 <fantasai> jfkthame: Could look into it, but doesn't seem worth the complexity
16:54:02 <fantasai> RESOLVED: Switch ic and ch to ic-width/ic-height/ch-width
16:54:26 <fantasai> Topic: Flexbox
16:54:37 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/5985
16:54:40 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/5985
16:54:48 <fantasai> TabAtkins: just got approval from dholbert so probably easy
16:54:56 <chrishtr> I need to follow up some more on issue 5896, let's cover it another time.
16:55:13 <fantasai> TabAtkins: dholbert noticed that collaped flex items aren't explicitly excluded from intrinsic size calculation
16:55:22 <fantasai> TabAtkins: so we updated to explicitly skip those items
16:55:31 <fantasai> commits are https://github.com/w3c/csswg-drafts/commit/60ffc4058780d832d880a076fe02788f0cc6e8a7
16:55:38 <fantasai> TabAtkins: We made the fix, just wanted WG confirmation it's OK
16:55:48 <cbiesinger> I haven't read the text but your description sounds good
16:56:03 <fantasai> astearns: proposal to accept?
16:56:08 <fantasai> RESOLVED: Accept edits
16:56:15 <fantasai> Topic: Scrollable overflow
16:56:20 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/4791
16:56:56 <fantasai> fantasai: Seem to have weird but interoperable behavior here, question was should we spec it
16:57:07 <fantasai> iank_: not so weird, we compute the "inflow" bounds
16:57:15 <fantasai> iank_: ...
16:57:27 <fantasai> iank_: If you add a transform to the item and move it outside the scrollable area
16:57:49 <fantasai> iank_: all browsers transform out
16:58:11 <fantasai> iank_: if something is zero area, it doesn't itself contribute, but it might contribute to "infow bounds"
16:58:16 <fantasai> fantasai: ???
16:58:29 <fantasai> iank_: If you have something like a grid area, that's where we determine where to put the "padding" to contribute to overflow
16:59:10 <fantasai> iank_: Here it's the body element contributing to the scrollable area
17:00:04 <fantasai> fantasai: OK, so need to set body to zero to test correctly and issue is invalid?
17:00:22 <fantasai> iank_: question of adding to overflow is just if it's empty
17:01:19 <fantasai> fantasai: Actually, there is an issue, but it's just that if the border area is empty, we need to exclude from the scrollable area
17:01:22 <fantasai> iank_: yea, but also this other thing
17:01:37 <fantasai> Topic: none
17:01:39 <fantasai> Meeting Closed.
17:19:02 <astearns> zakim, end meeting
17:19:02 <Zakim> As of this point the attendees have been argyle, jfkthame, miriam, castastrophe, alisonmaher, Morgan, TYLin, dholbert, rachelandrew, fremy, dlibby, oriol, chrishtr, jensimmons,
17:19:05 <Zakim> ... TabAtkins, gregwhitworth, plinss, smfr, cbiesinger, bradk, dbaron[m]
17:19:05 <Zakim> RRSAgent, please draft minutes v2
17:19:05 <RRSAgent> I have made the request to generate https://www.w3.org/2021/06/16-css-minutes.html Zakim
17:19:07 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
17:19:11 <Zakim> Zakim has left #css
17:55:56 <fantasai> s/what's the point of putting in a/it's not exactly accurate to say you're shifting it to the CSSWG for the/
18:57:03 <jensimmons> jensimmons has joined #css
19:44:49 <markiemark> markiemark has joined #css
19:48:29 <markiemark> markiemark has left #css
20:14:43 <jfkthame> jfkthame has joined #css
22:09:06 <dauwhe> dauwhe has joined #css
22:26:46 <dauwhe> dauwhe has joined #css
22:28:35 <dauwhe> dauwhe has joined #css
22:34:41 <dauwhe> dauwhe has joined #css
22:46:51 <dauwhe> dauwhe has joined #css
23:19:37 <dauwhe> dauwhe has joined #css
23:51:48 <dauwhe> dauwhe has joined #css