15:27:16 <RRSAgent> RRSAgent has joined #css
15:27:16 <RRSAgent> logging to http://www.w3.org/2012/08/29-css-irc
15:27:21 <glazou> Zakim, this will be Style
15:27:21 <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 33 minutes
15:27:26 <glazou> RRSAgent, make logs public
15:42:08 <logbot> logbot has joined #css
15:50:59 <lstorset> lstorset has joined #css
15:54:30 <dbaron> dbaron has joined #css
15:54:43 <Zakim> Style_CSS FP()12:00PM has now started
15:54:52 <Zakim> +??P6
15:54:52 <glazou> Zakim, who is here?
15:54:55 <Zakim> On the phone I see ??P6
15:54:58 <glazou> Zakim, ??P6 is me
15:54:59 <Zakim> On IRC I see dbaron, lstorset, logbot, RRSAgent, Zakim, glazou, jet, krit, koji, miketaylr, myakura, drublic, Ms2ger, tantek, arronei, Liam, decadance, Bert, trackbot, dholbert,
15:55:05 <Zakim> ... Hixie, hober, TabAtkins_, gsnedders, fantasai, jwir3, cabanier, shepazu, isherman, krijnh, alexmog, vhardy, sylvaing, shans, CSSWG_LogBot, heycam|away, paul_irish, stearns,
15:55:07 <Zakim> ... plinss, macpherson
15:55:09 <Zakim> +glazou; got it
15:55:16 <leaverou> leaverou has joined #css
15:57:19 <antonp> antonp has joined #css
15:57:37 <Zakim> +stearns
15:57:59 <Zakim> +plinss
15:58:38 <Zakim> +krit
15:59:24 <Zakim> +hober
15:59:38 <Zakim> +florian
15:59:47 <lstorset> Zakim, florian is me
15:59:47 <Zakim> +lstorset; got it
15:59:58 <Zakim> +antonp
16:00:14 <Zakim> +Bert
16:00:25 <Zakim> +SteveZ
16:00:32 <bradk> bradk has joined #css
16:01:14 <Zakim> + +1.415.615.aaaa
16:01:42 <rhauck> rhauck has joined #css
16:01:43 <SteveZ> SteveZ has joined #css
16:01:46 <glazou> Zakim: 
16:01:53 <glazou> Zakim, aaaa is rhauck 
16:01:53 <Zakim> +rhauck; got it
16:01:59 <oyvind> oyvind has joined #css
16:02:22 <smfr> smfr has joined #css
16:02:26 <glazou> lea: joining the call?
16:02:30 <Zakim> +dbaron
16:02:49 <glazou> Regrets: jjansen, sylvaing
16:03:01 <Zakim> +smfr
16:03:06 <florianr> florianr has joined #css
16:03:11 <Zakim> +??P37
16:04:02 <lea> glazou: yes
16:04:06 <plinss> rhauck: http://www.w3.org/1998/12/bridge/info/name.php3
16:04:17 <glazou> Zakim, mute ?P37
16:04:17 <Zakim> sorry, glazou, I do not know which phone connection belongs to ?P37
16:04:45 <Zakim> +lea
16:04:58 <glazou> right Bert
16:05:07 <glazou> and never had so many active members too
16:05:27 <TabAtkins> TabAtkins has joined #css
16:05:36 <rhauck> thanks Peter
16:05:39 <Zakim> + +1.281.305.aabb
16:05:45 <TabAtkins> zakim, aabb is me
16:05:45 <Zakim> +TabAtkins; got it
16:06:08 <Zakim> -TabAtkins
16:06:17 <SteveZ> scribenick SteveZ
16:06:28 <SteveZ> TPAC
16:06:53 <Zakim> +??P14
16:06:55 <SteveZ> Bert Do we need to reserve a polycom device
16:06:57 <florianr> florianr has joined #css
16:07:11 <Zakim> +TabAtkins
16:07:12 <Zakim> +[IPcaller]
16:07:13 <SteveZ> Daniel: Will a Skype device suffice"
16:07:23 <koji> zakim, [ipcaller] is me
16:07:23 <Zakim> +koji; got it
16:07:37 <SteveZ> Bert: using Zakim is no problem, but we would need to rent a polycom
16:07:56 <SteveZ> PeterL: just using Skype would be enough
16:08:30 <Zakim> + +1.650.275.aacc
16:08:40 <SteveZ> Daniel: John Daggett has provide the Skype device in the past; I will ping him to see if he is coming.
16:08:46 <Zakim> +[Microsoft]
16:08:55 <dbaron> Sylvain might also have one of those devices...
16:08:56 <SteveZ> Daniel" where are we re the Sunday meeting
16:09:00 <bradk> bradk has joined #css
16:09:02 <arronei> zakim, microsoft has me
16:09:02 <Zakim> +arronei; got it
16:09:40 <SteveZ> Bert: the people that offered to pay will get an invoice for their contribution from Alexandra who is working on the details
16:10:39 <SteveZ> Daniel: make sure to notify the contributers who gets the invoice
16:10:52 <bradk> zakim, who is here?
16:10:52 <Zakim> On the phone I see glazou, stearns, plinss, krit, hober, lstorset, antonp, Bert, SteveZ, rhauck, dbaron, smfr, ??P37, lea, ??P14, TabAtkins, koji, +1.650.275.aacc, [Microsoft]
16:10:55 <Zakim> [Microsoft] has arronei
16:10:55 <Zakim> On IRC I see bradk, TabAtkins, smfr, oyvind, SteveZ, rhauck, antonp, lea, dbaron, lstorset, logbot, RRSAgent, Zakim, glazou, jet, krit, koji, miketaylr, myakura, drublic, Ms2ger,
16:10:58 <Zakim> ... tantek, arronei, Liam, decadance, Bert, trackbot, dholbert, Hixie, hober, TabAtkins_, gsnedders, fantasai, jwir3, cabanier, shepazu, isherman, krijnh, alexmog, vhardy,
16:11:01 <Zakim> ... sylvaing, shans, CSSWG_LogBot, heycam|away, paul_irish, stearns, plinss, macpherson
16:11:19 <bradk> zakim, aacc is me
16:11:19 <Zakim> +bradk; got it
16:11:26 <SteveZ> SteveZ, Tab, Aaron: we will check if an invoice to INRIA in euros is OK
16:11:45 <Bert> s/INRIA/ERCIM/
16:11:51 <SteveZ> Daniel: Can we invite Florian Rivoval as an invited expert
16:11:57 <SteveZ> no objections
16:12:12 <SteveZ> Resolved: Florian is invited
16:12:39 <SteveZ> Daniel: Can we invite Simon Sapin as an Invited Expert
16:12:50 <SteveZ> no objection
16:13:05 <SteveZ> Resolved: Invite Simon Sapin
16:13:41 <stearns> http://testthewebforward.org/paris-2012.html
16:13:52 <SteveZ> Bert: Florian has already sent his form so I only need to tell Philippe LeHegaret to continue processing
16:14:04 <SteveZ> Topic: Test the Web Forward
16:14:05 <Zakim> +fantasai
16:14:24 <florianr> florianr has joined #css
16:14:39 <SteveZ> Stearns: The 3rd instance will be Friday and Saturday before TPAC
16:15:04 <stearns> please send a message to  testthewebforward@gmail.com if you will be able to attend
16:15:07 <SteveZ> Please send ability to attend to 
16:15:25 <SteveZ> Daniel: I will be there
16:15:41 <SteveZ> Venue is TBD
16:16:16 <glazou> http://wiki.csswg.org/topics/css-masking
16:16:17 <SteveZ> Topic: CSS Masking
16:16:18 <krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-mask-image
16:17:20 <glazou> krit: speak slower for minute taking plase
16:17:23 <glazou> please even
16:18:10 <SteveZ> krit: Some  people at F2F this was discussed and members requested more time to view spec.
16:18:39 <SteveZ> krit: via mailing list some properties were removed
16:19:51 <SteveZ> krit: can we remove some of the background properties: mask-attachment (not implemented by Webkit), mask-origin and mask-origin
16:20:53 <SteveZ> smfr: we should keep mask-origin be
16:20:56 <TabAtkins> ScribeNick: TabAtkins 
16:21:02 <glazou> Zakim, who is noisy?
16:21:13 <Zakim> glazou, listening for 10 seconds I heard sound from the following: glazou (14%), krit (4%), TabAtkins (58%)
16:21:24 <smfr> smfr: mask-attachment could be used for interesting design issues
16:21:26 <TabAtkins> krit: There's anothe rreason with keeping mask-origin.
16:21:37 <glazou> glazou: mask-attachment could be use for keyhole views effects
16:21:38 <TabAtkins> krit: CSS and SVG differ in how they apply.
16:21:58 <fantasai> smfr^: But it has the same problems wrt transforms as background-attachment
16:22:10 <TabAtkins> krit: SVG masks, all descendants of an element are grouped together and masked together.
16:22:17 <TabAtkins> krit: This is especially relevant for percentage values.
16:22:27 <TabAtkins> krit: 100% width is the boundingclientrect, etc.
16:22:49 <Rossen> Rossen has joined #css
16:22:51 <TabAtkins> smfr: In webkit, when you apply a mask to html, they create stackign contexts, just like opacity. So how is SVG different?
16:23:04 <TabAtkins> krit: The diff is that if you have border-box, padding-box, etc, you clip to these boxes.
16:23:18 <TabAtkins> krit: Every mask applied to these elements is clipped to the *-box of the element.
16:23:32 <TabAtkins> smfr: Ah, this is why dhyatt was reluctant to propose these.  They always hide overflow.
16:23:48 <Zakim> -??P14
16:23:48 <TabAtkins> krit: Right. SVG masking on firefox, though, allows overflowing content to be shown.
16:23:50 <Zakim> +[Microsoft.a]
16:24:06 <Rossen> Zakim, [Microsoft.a] is me
16:24:06 <Zakim> +Rossen; got it
16:24:13 <glazou> hi Rossen 
16:24:28 <TabAtkins> krit: So this is what I mean.  When you mask to a group element, it gets applied to the group's bounding box (which by definition includes the entire contents, no overflowing).
16:24:41 <TabAtkins> krit: I can post an example for it.
16:24:49 <Rossen> Hi Daniel, I was on my car phone til now a.k.a. ??P14 :-)
16:24:56 <TabAtkins> glazou: Speaking of the three properties you want to drop, would it be enough to mark them as at-risk?
16:25:00 <TabAtkins> krit: Yeah.
16:25:21 <TabAtkins> dbaron: at-risk is for when we think they're a good idea, but we're not sure we're going to get them. But this discussion is about whether they're a good idea or not.
16:25:31 <TabAtkins> dbaron: If they're not a good idea, they should just be dropped.
16:25:40 <TabAtkins> krit: There's already an issue that they might be dropped.
16:25:49 <TabAtkins> krit: Another issue is, do we keep clip-path?
16:26:03 <TabAtkins> krit: SVG already combines masking and clipping to one section.
16:26:25 <TabAtkins> glazou: I'd like to resolve on the first three properties.
16:26:31 <TabAtkins> smfr: I'd like to keep mask-origin.
16:26:42 <TabAtkins> glazou: krit, are you okay with keeping mask-origin, and dropping the others?
16:27:01 <TabAtkins> krit: Provisionally yes.  It might depend on how we handle clipping of masks (to border-box or bounding box).
16:27:12 <TabAtkins> zakim, who is noisy?
16:27:23 <Zakim> TabAtkins, listening for 10 seconds I heard sound from the following: Rossen (62%)
16:27:26 <TabAtkins> krit: So I can provide some examples to help us to decide to keep, drop, or redefine.
16:27:33 <glazou> Zakim, mute rossen
16:27:33 <Zakim> Rossen should now be muted
16:27:55 <krit> http://www.w3.org/Graphics/fx/wiki/Filter_Effects:_background_and_border_filter
16:28:57 <TabAtkins> krit: Here's an example from filter-effects to illustrate the problem.
16:29:33 <TabAtkins> krit: Two nested elements, the child overflows its parent.
16:29:45 <TabAtkins> krit: With SVG masking, percentages in the mask are referenced relative to the bounding box.
16:30:06 <TabAtkins> krit: For webkit-mask, it would just be the border-box of the parent.  Everything else would be masked away, and you can't do anything about it.
16:30:18 <dbaron> I didn't hear well enough to understand the problem.
16:30:45 <TabAtkins> smfr: There's a real attraction to reuse the background properties for simplicity.
16:30:49 <TabAtkins> smfr: [restates the problem]
16:31:43 <TabAtkins> fantasai: I think, if you're going to use the same things in filter effects, it makes sense to have it apply to overflowing content too.
16:31:56 <TabAtkins> dbaron: However, I don't think we want to take measurements based on an overflow rectangle.
16:32:06 <TabAtkins> dbaron: It's not well defined, and even if it were, it would likely be confusing.
16:32:44 <TabAtkins> fantasai: Similar issue - apply a mask to an inline with Zapfino, which overflows its em box.  You don't want it to clip.
16:32:55 <fantasai> or a filter
16:33:14 <TabAtkins> szilles: What did you mean "overflow is not well defined"?
16:34:09 <dbaron> krit: For ..., we just use the bounding client rect, which is just a union of border boxes, not overflow.
16:34:09 <krit> http://www.w3.org/TR/cssom-view/#dom-element-getboundingclientrect
16:35:56 <TabAtkins> dbaron: There's not a good definition for what overflwo means.
16:36:17 <TabAtkins> krit: You'd just use the concept of bounding rect, from CSSOM View.
16:36:46 <smfr> q+
16:37:07 <TabAtkins> TabAtkins: No, that's not what you want.  CSS's notion of this pays no attention to the children of an element, only the boxes of the element itself.  SVG has no elements which both have children and boxes, so it takes the collection of children and finds their bounding box.  This is why CSS "ignores overflow".
16:37:21 <glazou> Zakim, ack smfr
16:37:21 <Zakim> I see no one on the speaker queue
16:37:29 <TabAtkins> smfr: There's a possible solution here.
16:37:35 <SteveZ> Steve: if you have a line of text that overflows and you are puting a shadow on that text it is weird if the shadow disappears at the border boundary
16:37:53 <TabAtkins> smfr: Say that masking is not always clipping to the border box - you allow the mask image to project outside the border box, but the sizing is still specified in the same way that background is sized.
16:38:37 <TabAtkins> smfr: So it could cover the decorations of zapfino, but you'd keep the normal background sizing behavior.
16:38:39 <TabAtkins> fantasai: I agree.
16:38:58 <fantasai> TabAtkins: fantasai and I have been discussing allowing backgrounds to be drawn outside the border box, so agree with that 
16:39:01 <TabAtkins> TabAtkins: fantasai and I have been exploring a similar issue with backgrounds themselves, so I think this is a good direction to go in.
16:39:46 <TabAtkins> krit: What about percentages in sizing an SVG mask?
16:40:12 <TabAtkins> TabAtkins: Since SVG has no such thing as a padding box or border box, it can define what it wants (and use the bounding box of its descendants).
16:40:36 <krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#clipping-paths
16:40:40 <TabAtkins> krit: Okay, so next, should we keep clip-path in the spec?  It's already used in Firefox.
16:41:05 <Rossen> zakim, unmute me
16:41:05 <Zakim> Rossen should no longer be muted
16:41:08 <TabAtkins> krit: clip-path originally just referenced a <clipPath> from SVG, but I just extended it to also use the shape functions from exclusions.
16:41:47 <TabAtkins> smfr: I don't feel strongly.  It seems to overlap with 'clip'.
16:42:16 <TabAtkins> krit: Yeah, but 'clip' only does rect(), and requires abspos.
16:43:14 <TabAtkins> TabAtkins: I'm interested in us merging clip and clip-path.
16:43:27 <TabAtkins> dbaron: We'd probably have webcompat problems with that.
16:43:49 <TabAtkins> TabAtkins: There's a way around that - say that rect() only applies to abspos elements, but the other functions (including rectangle()) all work on all elements.
16:44:02 <smfr> i support this
16:44:19 <Rossen> Note that this discussion applies to CSS Shapes not CSS Exclusions, though they are in one spec at the moment we can split them at any time
16:44:34 <TabAtkins> RESOLVED: Keep clipping in the Masking spec.
16:44:42 <bradk> i would rather have a new "crop" property instead of "clip", with measurements from 4 edges
16:44:42 <fantasai> that is really vague resolution
16:45:00 <glazou> http://wiki.csswg.org/topics/interpolation-rotate3d
16:45:00 <TabAtkins> Make a better one.
16:45:02 <fantasai> RESOLVED: Keep clip-path in the Masking spec, mark integration with 'clip' as na issue
16:45:14 <TabAtkins> krit: We discussed rotate3d() and numerical interpolation at the f2f.
16:45:23 <TabAtkins> krit: Current behavior is that we always use matrix decomposition to interpolate.
16:45:31 <krit> http://wiki.csswg.org/topics/interpolation-rotate3d
16:45:33 <TabAtkins> krit: The group would like numerical interpolation.
16:46:00 <TabAtkins> krit: There are proposals near th eend of the wiki.
16:46:28 <glazou> fantasai: keep all with notes about potential drop
16:46:49 <TabAtkins> krit: If you have two vectors that describe the same axis but point in different directions...
16:47:03 <TabAtkins> krit: Right now we define rotation around the axis according to the direction of the vector.
16:47:18 <TabAtkins> krit: If they point in opposite direction, we need to decide how to interpolate the numbers.
16:47:27 <glazou> RESOLVED: keep mask-* with note about possibility to drop in the future
16:47:54 <fantasai> glazou, that seems very general... seems to say we should drop everything!
16:48:01 <glazou> why note :-)
16:48:03 <glazou> not
16:48:08 <TabAtkins> krit: If we interpolate the vectors, it gets smaller first, becomes a point, then points in the opposite direction.
16:48:17 <TabAtkins> krit: This means the rotation direction suddenly changes from CW to CCW.
16:48:26 <fantasai> glazou, I thought we were only talking about a few specific properties, -attachment, etc.
16:48:29 <glazou> yes
16:48:42 <fantasai> then I don't think your resolution is warranted by the discussion
16:48:47 <glazou> s/mask-*/mask-attachment mask-origin mask-clip
16:49:05 <dbaron> did we agree to keep all of them?
16:49:16 <fantasai> also, wasn't there agreement on having mask-clip somehow allow drawing outside the box?
16:49:21 <fantasai> or dropping it and doing that?
16:49:22 <dbaron> I thought there was discussion about mask-origin being useful
16:49:26 <TabAtkins> TabAtkins: I think it's uncontroversial to interpolate the angle when the vector is the same (after normalization).  Interpolating the vector is harder.
16:49:27 <dbaron> I don't remember support for the others.
16:49:47 <glazou> wait, let's finish rotate3d
16:50:01 <TabAtkins> krit: Yes.  And right now everyone supports it via decomposition, so it'll take time to change.
16:50:35 <TabAtkins> smfr: What I care about is that if the normalized vectors match, do angle interpolation.  I think it's fine to fall back to matrix interpolation otherwise.
16:50:59 <TabAtkins> smfr: One thing I think isn't clear is whether you interpolate from rotateX() to rotate3d(1,0,0,...), that'll give you angle rotation or matrix interpolation.
16:51:06 <TabAtkins> krit: Currently you do matrix.
16:51:10 <TabAtkins> smfr: That's unfortunate.
16:51:26 <TabAtkins> smfr: The spec currently defines a 2d set and a 3d set, and it's not clear whether they're equivalent.
16:52:51 <TabAtkins> krit: That seems easy.  I thought the resolution was for me to come up with a proposal to do vector interp.
16:53:04 <TabAtkins> krit: Which I've done (interpolate x,y,z numerically).
16:53:33 <TabAtkins> smfr: I don't think that's good.  The "snapping" effect when going from 1,0,0 to -1,0,0 is no good.
16:53:41 <TabAtkins> dbaron: Yeah, I'd rather fall back to matrix when the vectors don't match.
16:53:53 <TabAtkins> krit: Yeah, that would be the easiest way.
16:54:11 <drublic> drublic has joined #css
16:54:15 <TabAtkins> [no objections]
16:54:52 <TabAtkins> RESOLVED: rotate3d() is interpolated by its angle when the two (normalized) vectors match, by matrix interpolation otherwise.
16:55:12 <TabAtkins> RESOLVED: rotateX/Y() interpolate with rotate3d() in the obvious way.
16:55:24 <dbaron> and rotateZ() ??
16:55:34 <TabAtkins> RESOLVED: rotateX/Y/Z() interpolate with rotate3d() in the obvious way.
16:55:50 <TabAtkins> glazou: returning to the mask discussion...
16:56:06 <TabAtkins> fantasai: I heard we have concerns about attachment, people want origin, so what's hard?
16:56:15 <dbaron> does anybody actually want mask-clip ?
16:56:19 <TabAtkins> krit: Give me an action to come back with detailed proposals for these properties.
16:56:58 <TabAtkins> fantasai: My proposal. We drop -attachment unless someone asks for it.  We keep -origin.  We drop -clip, and say that masks don't clip.  (If you want to clip, use the box one.)
16:57:10 <TabAtkins> krit: Okay, so any objections to removing -attachment?
16:57:19 <TabAtkins> dbaron: I'm fine with that.
16:57:36 <TabAtkins> RESOLUTION: Remove mask-attachment from the Masking spec.
16:57:54 <TabAtkins> RESOLUTION: Keep mask-origin in the Masking spec.
16:58:00 <TabAtkins> glazou: What about mask-clip?
16:58:20 <TabAtkins> smfr: I think we want to keep it.  If we they extend out of the box, you may want to clip it.
16:58:33 <TabAtkins> fantasai: I think it should extend by default, but give us an ability to clip it.
16:58:56 <TabAtkins> dbaron: Do any of the options in mask-clip correspond to the behavior you're asking for?
16:58:59 <TabAtkins> smfr: No, we'll need a new value.
16:59:30 <TabAtkins> fantasai: Tab and I were thinking of no-clip when discussing this for background-*.
16:59:40 <TabAtkins> fantasai: I think we have agreement that we need the ability to have the image not clipped by the box.
17:00:03 <TabAtkins> fantasai: So either that becomes a new value of mask-clip, or it becomes the initial value of mask-clip, or we drop mask-clip and just make it how things always work.
17:00:35 <smfr> yes
17:00:45 <TabAtkins> glazou: No consensus, so defer to next call.
17:00:47 <smfr> smfr has left #css
17:00:47 <Zakim> -dbaron
17:00:49 <Zakim> -antonp
17:00:50 <Zakim> -[Microsoft]
17:00:50 <Zakim> -SteveZ
17:00:51 <Zakim> -smfr
17:00:52 <Zakim> -glazou
17:00:52 <Zakim> -lea
17:00:52 <Zakim> -bradk
17:00:54 <Zakim> -Rossen
17:00:56 <Zakim> -??P37
17:00:58 <Zakim> -krit
17:01:00 <Zakim> -koji
17:01:02 <Zakim> -hober
17:01:04 <Zakim> -lstorset
17:01:07 <Zakim> -plinss
17:01:09 <Zakim> -fantasai
17:01:10 <Zakim> -stearns
17:01:12 <Zakim> -TabAtkins
17:01:15 <Zakim> -rhauck
17:01:19 <Zakim> -Bert
17:01:20 <Zakim> Style_CSS FP()12:00PM has ended
17:01:22 <Zakim> Attendees were glazou, stearns, plinss, krit, hober, lstorset, antonp, Bert, SteveZ, +1.415.615.aaaa, rhauck, dbaron, smfr, lea, +1.281.305.aabb, TabAtkins, koji, +1.650.275.aacc,
17:01:25 <Zakim> ... arronei, bradk, fantasai, [Microsoft], Rossen
17:02:08 <lstorset> lstorset has left #css
17:04:29 <tpod> tpod has joined #css
17:07:29 <krit> krit has joined #css
17:07:39 <antonp> antonp has left #css
17:12:33 <dbaron_> dbaron_ has joined #css
17:12:42 <tpod> tpod has joined #css
17:16:03 <tantek> tantek has joined #css
17:18:09 <trackbot> trackbot has joined #css
17:20:10 <trackbot> trackbot has joined #css
17:21:16 <tantek_> tantek_ has joined #css
17:23:10 <trackbot> trackbot has joined #css
17:36:15 <florianr> florianr has joined #css
17:39:38 <dbaron> dbaron has joined #css
17:41:18 <oyvind> oyvind has left #css
17:42:38 <Ms2ger> Ms2ger has joined #css
17:45:14 <krit> krit has joined #css
17:48:19 <krit1> krit1 has joined #css
17:54:36 <florianr> florianr has joined #css
18:00:10 <tantek_> tantek_ has joined #css
18:00:53 <jet> jet has joined #CSS
18:04:55 <Ms2ger> Ms2ger has joined #css
18:24:51 <tantek> tantek has joined #css
18:35:06 <krit> krit has joined #css
18:39:51 <florianr> florianr has joined #css
18:57:23 <Zakim> Zakim has left #css
19:02:10 <nimbu> nimbu has joined #css
19:07:23 <drublic> drublic has joined #css
19:10:08 <florianr> florianr has joined #css
19:43:19 <nimbu> nimbu has joined #css
20:34:41 <jarek> jarek has joined #css
20:42:50 <dbaron> dbaron has joined #css
21:09:40 <rhauck1> rhauck1 has joined #css
21:21:53 <arronei> arronei has joined #css
21:26:14 <jarek> jarek has joined #css
21:48:56 <dbaron> dbaron has joined #css
22:05:27 <jet> jet has joined #CSS
22:33:28 <dbaron> dbaron has joined #css