16:02:00 <RRSAgent> RRSAgent has joined #css
16:02:00 <RRSAgent> logging to https://www.w3.org/2022/06/15-css-irc
16:02:02 <Zakim> RRSAgent, make logs Public
16:02:03 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:02:10 <smfr> present+
16:02:14 <lea> present+
16:02:16 <chris> https://developer.apple.com/documentation/safari-release-notes
16:02:22 <chris> present+
16:02:31 <jensimmons> present+
16:02:47 <masonf> masonf has joined #css
16:02:59 <masonf> present+
16:03:09 <argyle> present+
16:03:13 <fantasai> present+
16:03:19 <dandclark> present+
16:03:26 <emilio> present+
16:03:35 <Sebo> present+
16:03:42 <fantasai> Scribenick: fantasai
16:04:00 <futhark> futhark has joined #css
16:04:24 <chrishtr> Vote link for "isVisible" naming:  https://github.com/w3c/csswg-drafts/issues/7317#issuecomment-1154394479
16:04:26 <chrishtr> present+
16:05:32 <futhark> present+
16:05:41 <tantek> present+
16:05:49 <fantasai> Topic: Composition of Inset Shadows
16:05:51 <dbaron> Present+
16:06:06 <fantasai> astearns: Some additional discussion and a few attempts at mockups
16:06:10 <chrishtr> present+
16:06:13 <jfkthame> present+
16:06:24 <fantasai> astearns: trying to figure out what to do wrt text-shadow inset and text decorations
16:06:51 <astearns> github: https://github.com/w3c/csswg-drafts/issues/7251
16:06:52 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7251
16:07:06 <fantasai> Sebo: Discussing paint order and compositing fill/stroke/shadow
16:07:11 <fantasai> Sebo: lot of discussion around that
16:07:24 <fantasai> Sebo: My point of view was that composition should be done so that the inset shadow is between fill and stroke
16:07:35 <miriam> present_
16:07:38 <fantasai> Sebo: but fantasai said that this could lead to some perf issues ...
16:07:39 <miriam> present+
16:07:55 <flackr> flackr has joined #css
16:08:05 <bramus> bramus has joined #css
16:08:05 <fantasai> fantasai: not perf issue
16:08:41 <flackr> present+
16:08:58 <smfr> q+
16:09:17 <emilio> fantasai: One issues is that the stroke comes between the text and the text-decoration, so if you have a strike through you are going to stroke text then strike-through, so if you want to shadow between text and fill you are going to also need to shadow the text decoration
16:09:38 <emilio> ... the point of shadows is to create an inset / outset effect
16:09:51 <bradk> bradk has joined #css
16:10:04 <emilio> ... so you if you have text and decorations with their shadows it looks super weird
16:10:22 <emilio> ... for text that's decorated makes more sense to shadow text + decoration at the same time
16:10:33 <emilio> ... so you we can't shadow between fill and stroke
16:10:48 <bramus> present+
16:11:03 <emilio> ... that is also an issue because if you don't strike together a semi-transparent shadow will look darker on the decoration
16:11:04 <astearns> ack smfr
16:11:23 <emilio> smfr: for outset shadows I agree we want to composite + shade text and decoration together
16:11:36 <bradk> Issue link, please? Sorry, I arrived late
16:12:02 <emilio> ... does any of the illustrations in the example match what fantasai is proposing?
16:12:05 <bradk> Thanks
16:12:09 <emilio> fantasai: I don't think any of them are
16:12:21 <emilio> smfr: can we get an illustration of what the behavior should be?
16:12:21 <fantasai> https://github.com/w3c/csswg-drafts/issues/7251#issuecomment-1145287101
16:12:34 <emilio> fantasai: if we ignore the stroke on the second one that's the effect you'd get
16:13:12 <emilio> ... if you consider the stroke because the text decoration has its own independent stroke, but the shadow effect in that comment is what you'd get
16:13:24 <emilio> smfr: so you want stroking behavior of first line and shadowing behavior of the second?
16:13:27 <emilio> fantasai: yes
16:13:31 <Sebo> q+
16:13:37 <astearns> I think it would be weird to have a stroke on the decoration but no shadow cast by that stroke
16:13:45 <emilio> fantasai: I think most cases would have either stroke or text-decor
16:13:57 <emilio> ... the top rendering doesn't quite work
16:14:15 <emilio> ... you still have two things that are cut out but flat
16:14:36 <emilio> ... the second one seems like you pushed the text into the canvas which is somewhat consistent with the effect
16:14:45 <emilio> ... it's also consistent between inset and outset shadows
16:15:11 <emilio> ... there's cases where drawing the inset shadow between fill/stroke looks better but the effect is that when you have decorations it'd look wrong
16:15:28 <emilio> smfr: if we stroke using top and shadow using the bottom one it's going to look very weird too
16:15:48 <emilio> fantasai: let's say you have strokes that are similar color for shades of yellow/orange
16:16:04 <emilio> ... you cut that out and shade it behind the canvas
16:16:22 <emilio> smfr: maybe Sebo or fantasai can illustrate the behavior in a drawing tool
16:16:49 <emilio> ... if it's hard to do in a drawing tool it's possibly hard to do programmatically too
16:17:10 <emilio> astearns: hard to do for me in a drawing tool doesn't mean hard to do in a drawing tool :)
16:17:22 <emilio> fantasai: we can try to work on that tomorrow
16:17:44 <emilio> astearns: whenever we can have them it'd be great to have pictures of what fantasai is trying to express
16:17:52 <GameMaker> GameMaker has joined #css
16:18:00 <astearns> ack Sebo
16:18:00 <emilio> ... I'm having a hard time following
16:18:01 <smfr> q+
16:18:13 <astearns> ack smfr
16:18:22 <GameMaker> present+
16:18:37 <emilio> smfr: one more q and one more statement. Inset shadows are going to require masking on the text, so lots of texts with inset shadows are going to get pretty expensive
16:18:51 <emilio> ... and authors can have very small text with very large blur radius
16:19:05 <emilio> ... so not sure we need some limits here
16:19:23 <emilio> astearns: if you have a shadow with a big offset does it mean that the shadow appears in another line? That sounds tricky
16:19:29 <emilio> smfr: potentially? Good point
16:20:00 <emilio> topic: Is color-contrast() ready to ship?
16:20:13 <emilio> github: https://github.com/w3c/csswg-drafts/issues/7310
16:20:23 <chris> We believe the color-contrast() function needs significant modification  to make it future-compatible and to make it work as intended, and  propose deferring this feature to CSS Color Level 6 so that we can work  on it without holding back the rest of CSS Color 5.
16:20:32 <fantasai> scribe+
16:20:49 <fantasai> chris: Had a breakout about color-contrast(), partly prompted by an FO about using WCAG2.1's algorithm
16:20:58 <fantasai> chris: That is known to give bad results frequently, particularly in dark mode
16:21:03 <fantasai> chris: figures of around 40% being wrong
16:21:15 <fantasai> chris: There's work to develop a new one, but not ready, not normatively referenced in WCAG3
16:21:21 <fantasai> chris: Also complaints about syntax and so on
16:21:45 <fantasai> chris: On the one hand browsers have it working reliably, on the other hand it often give sthe wrong answer
16:22:01 <fantasai> chris: We don't want to ship something that is interoperable, but is harmful to the Web platform
16:22:10 <fantasai> chris: So we want to shift this to the next level
16:22:12 <lea> q?
16:22:16 <lea> q+
16:22:27 <fantasai> astearns: Any arguments for not deferring?
16:22:27 <astearns> ack lea
16:22:34 <fantasai> lea: I completely agree with deferring it, unfortunately
16:22:43 <fantasai> lea: one thing from breakout we wanted feedback from implementers
16:22:50 <fantasai> lea: breakbout was me, Chris, Adam, and fantasai
16:23:10 <fantasai> lea: Would help if we could ship color-contrast() without a specified algorithm, could use the best available algorithm
16:23:22 <fantasai> lea: we're concerned that implementers would be against doing something that changed over time
16:23:37 <fantasai> https://github.com/w3c/csswg-drafts/issues/7361
16:23:38 <argyle> this? https://github.com/w3c/csswg-drafts/issues/7361
16:24:16 <fantasai> fantasai: if we went this route, could ship a subset of functionality sooner
16:24:24 <fantasai> fantasai: but need to make some syntactic changes to make future-compatible first
16:24:30 <chris> q+
16:24:42 <smfr> q+
16:24:46 <fantasai> astearns: I would worry slightly about defaulting to best available, and then ppl expecting current results, and then getting different results when have a better algorithm
16:24:50 <fantasai> lea: yes, that's the worry
16:24:59 <fantasai> chris: Yes, concern that it will continue to do what it did earlier
16:25:14 <fantasai> chris: Also the target contrast values have different meanings depending on the contrast algorithm
16:25:31 <fantasai> chris: so I don't think it makes sense to use a mystery algorithm that works differently later on
16:25:38 <astearns> ack chris
16:25:39 <fantasai> chris: it's not small progressive change, it's a major change
16:25:40 <astearns> ack smfr
16:25:45 <fantasai> smfr: I agree with those concerns
16:25:58 <fantasai> smfr: also don't want push the burden of choosing algorithms to web authors
16:26:02 <bradk> bradk has joined #css
16:26:08 <astearns> ack fantasai
16:26:28 <emilio> fantasai: I think if we wanna push for something sooner we'd need to go for something very minimal
16:26:37 <lea> q?
16:26:48 <jensimmons> q+
16:26:55 <emilio> ... if it solves things like github labels or so then good, but everything else would need to be deferred
16:27:33 <emilio> ... if that's something that people thing it's important (having black / white text) maybe we can have a very minimal function
16:27:49 <fantasai> chris: even "black or white on this color", WCAG gets wrong substantially a lot of the time
16:27:53 <fantasai> chris: I don't think it's worth doing
16:27:58 <astearns> ack jensimmons
16:28:01 <lea> q+
16:28:17 <fantasai> jensimmons: it's very hard to teach authors that what they were doing with a thing earlier, and failing them, it's very hard to unteach that
16:28:30 <fantasai> jensimmons: we might have a year of it working poorly, ppl say "this sucks, don't use it" for the next 5 years
16:28:34 <chris> s/WCAG gets/WCAG 2.1 gets/
16:28:36 <fantasai> jensimmons: super hard to get people to change their habits
16:28:40 <astearns> ack lea
16:28:58 <fantasai> lea: I think the idea behind shipping minimal white/black is not that WCAG is good enough, but it is more likely to be able to change it
16:29:03 <fantasai> lea: I think that was the thinking behind it
16:29:22 <fantasai> fantasai: Yes, we would swap in better algorithm as soon as we have it
16:29:44 <fantasai> astearns: putting aside whether to do simple version at all, sounds like we generally agree that the more complex color-contrast() function needs to be deferred
16:29:48 <fantasai> astearns: can we resolve on that?
16:30:08 <fantasai> RESOLVED: Move color-contrast() to CSS Color Level 6
16:30:25 <fantasai> astearns: I think we could continue discussing possibility of smaller subset of functionality in an issue
16:30:40 <fantasai> astearns: but might be better to continue work on the function that we want, and put that out as quickly as we can
16:31:17 <fantasai> chris: Now that we've resolved that, my focus is on remaining bits in Interop 2022
16:31:22 <fantasai> chris: color-mix(), interpolation, etc.
16:31:26 <fantasai> chris: so let's move on to other issues
16:31:48 <fantasai> Topic: [css-color-5] Clarify serialization of color-mix()
16:31:55 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6206
16:31:58 <bradk> I just shared a rendering that I **think** is what fantasai was proposing
16:32:15 <bradk> Shared in WebEx
16:32:28 <fantasai> chris: agreement in general, remaining issue is should things like hsl come out as themselves, come out as rgb, or use the color() function which retains more precision
16:32:31 <bradk> Ok
16:32:43 <fantasai> chris: Emilio said it would be harder to ship, but could see the value of it, so not sure where we are on that
16:32:56 <fantasai> emilio: That's still my opinion
16:33:09 <bradk> bradk has joined #css
16:33:21 <fantasai> emilio: slight preference to serialize as input color
16:33:27 <fantasai> chris: I can see arguments both ways
16:33:37 <fantasai> chris: I have a slight preference for serializing as color()
16:33:48 <fantasai> jensimmons: any visual difference in the result?
16:33:52 <fantasai> chris: there could be, but very slight
16:34:09 <fantasai> chris: if only 8-bit, and do mix of a mix, lose some precision and could result in banding
16:34:15 <fantasai> emilio: that's also an implementation detail
16:34:25 <fantasai> emilio: no reason why colors can't be more precise than 8-bit
16:34:34 <fantasai> chris: that's not what implementations do
16:34:39 <bradk> bradk has joined #css
16:34:45 <fantasai> chris: spec mandates are higher precision for newer color spaces
16:35:05 <fantasai> chris: of course can implement at higher precision
16:35:11 <fantasai> chris: but concerned we'll get some degradataion
16:35:23 <fantasai> jensimmons: screens are getting better, and color precision going better, seems we should go with higher precision
16:35:39 <astearns> ack fantasai
16:36:21 <chris> qq+
16:36:23 <emilio> fantasai: can be confusing to give two hsl colors and get a different color
16:36:50 <emilio> ... from the precision argument I don't see why we won't just encourage implementations to have more precision
16:37:07 <astearns> ack chris
16:37:07 <Zakim> chris, you wanted to react to fantasai
16:37:07 <emilio> ... I don't understand why you'd have different precision on color() vs rgb()
16:37:24 <fantasai> chris: not just giving two colors, you specified color space to mix in and you get back in that color space
16:37:29 <fantasai> chris: shouldn't be that surprising
16:37:35 <emilio> q+
16:37:37 <fantasai> chris: wrt precision, implementations have been stuck on 8-bit for a long time
16:37:57 <fantasai> chris: but we've also written for other color spaces need 10-bit or 12-bit, or 16-bit for xyz
16:38:06 <fantasai> chris: so implementations going into those color spaces need more precision
16:38:22 <fantasai> chris: we did say that if you're giving a 0255 value in rgb you can get ?? when you serialize
16:38:36 <astearns> s/??/decimal places/
16:38:46 <fantasai> chris: but saying hope that everyone upgrades from 8-bit... harder than requiring upgrade for new stuff
16:38:49 <fantasai> emilio: I agree with fantasai
16:38:54 <fantasai> emilio: we use 8-bit colors for space-efficiency
16:39:11 <fantasai> emilio: so you can store an RGB color in one integer
16:39:20 <fantasai> emilio: but if we need more precision for htis feature, we can increase
16:39:32 <fantasai> emilio: if we implement high-precision sRGB we would do it both for color() and rgb()
16:39:42 <fantasai> emilio: there's no point in having two different representations for the same color space
16:40:05 <fantasai> astearns: just having higher precision for rgb() and color() wouldn't be sufficient, because color() can give you color spaces that are higher precision
16:40:35 <bradk> bradk has joined #css
16:41:09 <fantasai> fantasai: if I mix 2 rgb colors in xyz space, do I get a color in rgb or xyz space?
16:41:13 <fantasai> chris: xyz space
16:41:22 <fantasai> faceless: if I mix 2 rgb colors in rgb space, I get rgb space back right?
16:41:24 <fantasai> chris: yes
16:41:29 <fantasai> s/faceless/fantasai/
16:41:41 <fantasai> [missed]
16:41:50 <fantasai> astearns: so that you can plug that function into a nother property and not lose precision
16:42:32 <emilio> q+
16:43:27 <astearns> ack emilio
16:43:37 <fantasai> fantasai: if color(rgb) has a particular precision, no reason for rgb() to have different precision
16:43:41 <fantasai> emilio: ...
16:43:53 <fantasai> emilio: given you need to return a color in ?? color space, I don't think it we serialize as color() or rgb()
16:44:00 <lea> q?
16:44:01 <fantasai> emilio: maybe color() is more consistent with other colorspace outputs?
16:44:03 <lea> q+
16:44:11 <lea> q-
16:44:13 <fantasai> emilio: I'd be fine serializing as color() if easier for e.g. WebKit, for us it would be the same
16:44:23 <fantasai> astearns: I'm hearing a lot of, yeah, either way is fine I gues
16:44:32 <fantasai> astearns: so should we pick serializing as a color() function?
16:44:48 <fantasai> chris:  you're going to get color() function anyway in any of the other color spaces
16:44:58 <fantasai> chris: if you just happen to pick srgb, need to pick what to do there
16:45:05 <fantasai> chris: imho more consistent to say get a color() function back
16:45:12 <fantasai> astearns: so proposed resolution is to serialize as a color() function
16:45:17 <chris> +1
16:45:29 <fantasai> lea: It's not always [missed]
16:45:55 <fantasai> lea: it's not always possible to serialize everything as color() function, there are functions only available in their own function e.g. lab() lch()
16:46:04 <fantasai> chris: That's true, but you won't see them in rgb() form either
16:46:06 <emilio> q+
16:46:13 <fantasai> lea: so does proposed resolution affect only mixing in rgb()?
16:46:31 <fantasai> lea: because right now that is the only color available both in functional notation and a color() function, and these are distinct color formats
16:46:40 <fantasai> lea: color() function has 10-bit and I think it can go beyond the 0-1 range
16:46:52 <fantasai> lea: I'm not sure if browsers want to use 10-bit format every time someone mixes in sRGB
16:47:10 <fantasai> lea: want to get clarity if this resolution is only about sRGB or about every color space ... which is not even possible
16:47:23 <fantasai> chris: If you choose to mix in sRGB then you'll get in sRGB color space
16:47:32 <fantasai> lea: so interpolation token in sRGB, then ?? interchangeable?
16:47:36 <fantasai> lea: does the syntax allow both?
16:47:56 <astearns> s/??/interpolation token/
16:48:05 <fantasai> lea: You specify which color space you interpolate is "in <colorspace>", in gradients or color-mix() or whatever
16:48:19 <fantasai> lea: does that mean that "in rgb" is same as "in sRGB" ?
16:48:23 <fantasai> chris: you can't say "in rgb"
16:48:30 <fantasai> chris: we don't have a color space called "rgb"
16:48:32 <fantasai> lea: are you sure?
16:48:33 <fantasai> chris: yes
16:48:54 <fantasai> -> https://www.w3.org/TR/css-color-4/
16:48:54 <astearns> ack emilio
16:49:06 <fantasai> emilio: is there any good reason why lab colors can't be specified in color() notation?
16:49:17 <fantasai> chris: because color() started out as predefined rgb spaces
16:49:27 <fantasai> chris: it's a lot shorter for lab/lch to have their own functions
16:49:36 <fantasai> chris: we do have an open issue about throwing everything into color() function
16:49:51 <fantasai> chris: but that would just take existing syntax and make it longer
16:49:59 <fantasai> emilio: benefit is that color-mix() would have consistent output
16:50:11 <fantasai> jensimmons: want to get through these issues so can start shipping
16:50:28 <fantasai> astearns: proposed resolution is that we serialize as a color() function for color-mix that is being mixed in rgb
16:50:41 <fantasai> lea: no rgb, only sRGB, so makes sense to return color()
16:50:48 <fantasai> astearns: any objections to this resolution?
16:51:01 <fantasai> RESOLVED: color-mix() returns color() for sRGB mixes
16:51:12 <chris> q+
16:51:14 <fantasai> Topic: [css-color-5] What should the behavior of the CSS Color 5 color functions be when passed currentcolor as <color>
16:51:21 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6168
16:51:31 <astearns> ack chris
16:51:43 <fantasai> chris: I think we solved this in the issue, iterated the text with emilio
16:52:01 <fantasai> emilio: for context with the group, it behaves like calc() - doesn't go away in specified style
16:52:12 <fantasai> emilio: goes away in computed style if possible, but preserves currentColor
16:52:26 <fantasai> emilio: but this is only observable in typedOM because getComptedStyle returns resolved colors
16:53:20 <fantasai> RESOLVED: specified style maintains calculations, computed style computes everything as far as possible (but maintains currentColor's identity), resolved color resolves through to absolute color
16:53:33 <fantasai> chris: I believe this also resolves item 5 on the agenda,
16:53:40 <fantasai> https://github.com/w3c/csswg-drafts/issues/7302
16:54:00 <fantasai> Topic: Ready to Ship Color Stuff
16:54:17 <fantasai> chris: Would love to see the interpolation for gradients shipping, can we resolve and say it's ready to ship?
16:54:34 <fantasai> chris: color-mix(), relative color syntax, and interpolation of gradients in non-RGB color spaces
16:54:42 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7310
16:54:56 <fantasai> astearns: no more issues on color-mix()?
16:54:58 <fantasai> chris: no
16:55:02 <emilio> q+
16:55:03 <fantasai> astearns: relative color syntax?
16:55:10 <fantasai> chris: No, and ppl liked it. I talked about it last week
16:55:19 <fantasai> astearns: interpolation of gradients?
16:55:28 <fantasai> chris: Uses the same syntax as color-mix(), "in colorspace"
16:55:36 <fantasai> astearns: Any objections to marking these ready to go?
16:55:43 <astearns> ack emilio
16:55:55 <fantasai> emilio: So, color-mix() I'm fine saying current spec is shippable. We've gone through it a lot
16:56:30 <fantasai> emilio: The gradient one is relatively straightforward, would love to sanity-check it but seems reasonable assuming interpolation token gets preserved everywhere and no fancy computed style shenanigans, just only affects rendering
16:56:44 <fantasai> emilio: about relative color syntax, less enthusiastic because only one implementation
16:57:12 <fantasai> emilio: and their implementation seems to have same interop concerns as color-mix() where we had differences between WebKit / gecko
16:57:23 <fantasai> emilio: so not so sure about it ready to ship
16:57:52 <fantasai> astearns: we should have a high bar to say ready to ship, regardless of where spec in the process
16:58:02 <gtalbot> gtalbot has joined #css
16:58:07 <fantasai> [discussion about relative color syntax]
16:58:18 <fantasai> emilio: keep the token in specified and computed style, only affects rendering
16:58:22 <fantasai> emilio: if so, that seems reasonable
16:58:31 <fantasai> emilio: I think straigthforward enough, doesn't need super deep review
16:58:36 <fantasai> emilio: relative color syntax is trickier
16:58:50 <fantasai> chris: gradient is doing color-mix(), just doing it in all possible percentages. It's the same calculation
16:59:01 <fantasai> emilio: think it's probably fine. I would like more feedback on relative color syntax
16:59:07 <fantasai> emilio: but gradient interpolation seems straightforwad
16:59:11 <astearns> ack fantasai
16:59:15 <emilio> scribe+
16:59:34 <emilio> fantasai: happy with emilio's proposal to resolve on color-mix() + gradients but not yet on relative colors
16:59:46 <fantasai> astearns: declare color-mix() and non-rgb gradient interpolation as ready to ship
16:59:49 <fantasai> astearns: objections?
17:00:06 <chris> high five!
17:00:06 <emilio> RESOLVED: color-mix() and gradient interpolation are ready to ship
17:00:08 <fantasai> RESOLVED: colr-mix() and gradient non-sRGB interpolation are "ready to ship", add to Snapshot 2022
17:00:20 <fantasai> Topic: Reminders
17:00:29 <fantasai> astearns: Reminder that we have a scroll animation call tomorrow
17:00:35 <fantasai> Meeting closed.
17:03:02 <gtalbot> gtalbot has left #css
17:03:13 <gtalbot> gtalbot has joined #css
17:03:26 <astearns> zakim, end meeting
17:03:26 <Zakim> As of this point the attendees have been plinss, bkardell_, smfr, lea, chris, jensimmons, masonf, argyle, fantasai, dandclark, emilio, Sebo, chrishtr, futhark, tantek, dbaron,
17:03:29 <Zakim> ... jfkthame, miriam, flackr, bramus, GameMaker
17:03:29 <Zakim> RRSAgent, please draft minutes v2
17:03:29 <RRSAgent> I have made the request to generate https://www.w3.org/2022/06/15-css-minutes.html Zakim
17:03:31 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
17:03:35 <Zakim> Zakim has left #css
17:03:46 <jfkthame> jfkthame has left #css
17:03:56 <gtalbot> gtalbot has left #css
17:07:14 <bradk> bradk has joined #css
17:41:58 <jensimmons> jensimmons has joined #css
18:13:35 <fantasai> fantasai has joined #css
18:15:16 <plh> plh has joined #css
18:18:24 <jamesn> jamesn has joined #css
18:50:09 <jensimmons> jensimmons has joined #css
19:22:33 <jensimmons> jensimmons has joined #css
19:42:05 <jensimmons> jensimmons has joined #css
21:21:08 <GameMaker> GameMaker has joined #css