17:01:57 <RRSAgent> RRSAgent has joined #CSS
17:01:57 <RRSAgent> logging to http://www.w3.org/2010/02/17-CSS-irc
17:01:59 <trackbot> RRSAgent, make logs member
17:02:01 <trackbot> Zakim, this will be Style_CSS FP
17:02:02 <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
17:02:02 <trackbot> Date: 17 February 2010
17:02:02 <Zakim> ok, trackbot, I see Style_CSS FP()12:00PM already started
17:02:16 <dbaron> RRSAgent, make logs public
17:02:25 <anne42> Zakim, passcode?
17:02:25 <Zakim> the conference code is 78953 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), anne42
17:02:47 <smfr> smfr has joined #css
17:02:52 <dbaron> Zakim, who is on the phone?
17:02:52 <Zakim> On the phone I see dsinger_ (muted), Bert, David_Baron, sylvaing, CesarAcebal
17:03:00 <Zakim> +[Microsoft]
17:03:05 <smfr> sorry, can't make the call right now; will try to join later
17:03:15 <arronei> zakim, Microsft is me
17:03:15 <Zakim> sorry, arronei, I do not recognize a party named 'Microsft'
17:03:16 <dbaron> Zakim, [Microsoft] has arronei
17:03:17 <Zakim> +arronei; got it
17:03:28 <Zakim> -dsinger_
17:03:52 <Zakim> +SteveZ
17:03:57 <Zakim> +dsinger_
17:04:04 <dsinger> zakim, mute dsinger_
17:04:04 <Zakim> dsinger_ should now be muted
17:04:16 <szilles> szilles has joined #css
17:04:32 <Zakim> +TabAtkins
17:05:01 <Zakim> +??P10
17:05:11 <dbaron> Zakim, ??P10 is anne
17:05:11 <Zakim> +anne; got it
17:05:12 <TabAtkins> Scribenick: TabAtkins
17:05:38 <Zakim> +??P11
17:05:47 <dbaron> Zakim, ??P11 is fantasai
17:05:47 <Zakim> +fantasai; got it
17:05:49 <TabAtkins> Bert: I'm chairing today, at request of glazou and plinss, as they can't attend.
17:06:00 <TabAtkins> Bert: First item on agenda is testsuite.  What's the status?
17:06:13 <TabAtkins> fantasai: Status is, I'm working on build script and trying to fix some of the errors in html generation.  Nothing else new to say.
17:06:21 <TabAtkins> Bert: You're confident that will work fine shortly?
17:06:24 <TabAtkins> fantasai: I hope so!
17:06:44 <TabAtkins> Bert: Anything more coming up after that to be done?
17:07:47 <TabAtkins> fantasai: * preserve doctypes across conversion * munging sgml comments, shouldn't do that * htaccess merging * need structured directory support * build scripts need to filter html-only vs xhtml-only * adding support for reftests
17:08:39 <TabAtkins> Bert: Second topic, issue in background property grammar, raised by Yves Lafon.
17:08:45 <TabAtkins> Bert: I just sent a reply.
17:08:48 <Bert> http://lists.w3.org/Archives/Public/www-style/2010Jan/0248.html
17:09:15 <TabAtkins> fantasai: We can add more restrictions on where this can be placed.
17:09:32 <TabAtkins> fantasai: Or alternatively, if it hasn't been implemented/deployed yet, we might be able to change the syntax to not use a slash
17:09:49 <TabAtkins> Bert: That sounds like a big change.
17:09:52 <fantasai> something like background: url(foo.png) as 2em 2em
17:09:59 <TabAtkins> Bert: There are two questions in the email from Yves.
17:10:16 <TabAtkins> Bert: First, / at start isn't compatible with appendix G.  I don't think that appendix applies to CSS3.
17:10:30 <TabAtkins> Bert: Second is if we want to allow starting with a slash.  Elika, you say we might not want that.
17:10:54 <TabAtkins> Bert: Anyone have opinions on it?
17:11:08 <TabAtkins> TabAtkins: I've never used it, so I can't comment on it.
17:11:12 <TabAtkins> sylvaing: What does it actually do?
17:11:27 <TabAtkins> Bert: It separates size from position.  Behind slash, it's a size, not behind, it's a position.
17:11:35 <TabAtkins> sylvaing: What happens today with it?  Ignored, or what?
17:11:48 <TabAtkins> Bert: It's new in B&B3, so I'm not sure what it does today.
17:12:06 <TabAtkins> anne: Per css2.1 it should be ignored.
17:12:32 <TabAtkins> Bert: Elika, you had a specific idea to make this better?
17:12:54 <TabAtkins> fantasai: I don't know impl status, but one alternative is to change the / to "as", like "url() as <size>".
17:13:21 <TabAtkins> Bert: That would maybe work, but it would be a pity to take it out of CR.
17:13:33 <TabAtkins> fantasai: We may need to do that anyway, for gradients.
17:13:51 <TabAtkins> sylvaing: I don't like having the separator, and being able to skip what comes before it.  If the slash is there, it should have something on both sides.
17:14:12 <TabAtkins> Bert: So you want there to be a position every time there is a size?
17:14:24 <TabAtkins> dbaron: Sorta, yeah.  I've lost this argument before, but...
17:14:44 <TabAtkins> Bert: You have another chance to convince people.  The cost is that we need to change a CR.
17:15:01 <TabAtkins> sylvaing: If it's not widely implemented it's not costly, it's just editting the spec.
17:15:25 <TabAtkins> fantasai: Sicne it's only been CR for a few months, if we can talk to impl and see it's not implemented, we can change it.
17:15:36 <TabAtkins> Bert: We have implementors here.  Has it been implemented?
17:15:54 <TabAtkins> dbaron: We (mozilla) haven't done the shortcut yet.  Just background-size itself, not the shorthand.
17:16:00 <TabAtkins> sylvaing: We (microsoft) haven't implemented it yet.
17:16:03 <dbaron> just did background-size as -moz-background-size
17:16:31 <TabAtkins> Bert: 1) change slash to someething else, like a keyword 2) require a position when you specify a size, 3) leave it as is.
17:16:56 <TabAtkins> Bert: I hear some support for #2.  Would the size have to be in a particular place, or just *somewhere* before the slash?
17:17:16 <TabAtkins> fantasai: Anywhere before the position, by current spec.
17:17:30 <TabAtkins> Bert: Preferences?
17:17:53 <TabAtkins> dbaron: My position is that, if you have a slash, there is a size right before it, and a position right after it.
17:18:11 <TabAtkins> szilles: Is there an example elsewhere of a slash without something before it?
17:18:17 <anne42> <ratio> from css3-mediaqueries requires both sides too
17:18:27 <TabAtkins> dbaron: It only appears in the font shorthand, and there you need two things.
17:18:43 <TabAtkins> Bert: A slash doesn't have to be a 'separator', it could just be punctuation.
17:18:56 <TabAtkins> sylvaing: Are we just trying to support a pattern that no one will want to use?
17:19:11 <TabAtkins> anne: Best to require a style that is consistent, so authors can read it more easily.
17:19:21 <TabAtkins> sylvaing: Agreed.  Dangling separators all over the place is no good.
17:20:20 <TabAtkins> Bert: So I'm hearing some consensus on #2.
17:20:26 <fantasai> Tab: I'm ok with requiring both, although I prefer using 'as'
17:20:35 <TabAtkins> szilles: I echo Tab.
17:20:53 <TabAtkins> szilles: Basically keeping / requiring a pair makes things easier to do things.
17:21:06 <TabAtkins> szilles: But since in many cases you *dont'* need a position, it might be better to have size as an independent thing.
17:21:18 <dsinger> dsinger has joined #css
17:21:31 <TabAtkins> fantasai: Slight preference for the keyword as well.
17:21:43 <Zakim> +[Apple]
17:21:44 <TabAtkins> Bert: So, how to proceed?  Should we have someone draw up the grammar?
17:21:50 <dsinger> zakim, [apple] has dsinger
17:21:50 <Zakim> +dsinger; got it
17:21:58 <Zakim> -dsinger_
17:22:20 <TabAtkins> fantasai: The keyword sort of directs you more towards that the number is doing something to the image.
17:22:26 <fantasai> background: url(foo.png) as 100%
17:22:29 <anne42> Bert, I have to leave a little early, so if items involving CSSOM could be moved forward that'd be cool
17:22:50 <TabAtkins> sylvaing: As long as a / has things on both sides I'm fine, so I'm fine with either 1 or 2.
17:22:55 <anne42> Bert, around 18:45
17:23:10 <TabAtkins> Bert: So, consensus seems to be around the keyword, unless people have preference for a slash?
17:23:31 <TabAtkins> Bert: Okay, then someone should write up the proposal for the new text/grammar.
17:23:35 <TabAtkins> fantasai: I can do that.
17:23:40 <fantasai> ACTION: write new text/grammar for using keyword
17:23:40 <trackbot> Sorry, couldn't find user - write
17:23:50 <TabAtkins> Bert: Do we need to come back to this?  Or is the change simple enough that we can just accept it?
17:23:57 <TabAtkins> dbaron: I think it would be useful to see what the proposal actually is.
17:24:24 <TabAtkins> fantasai: Also we should check in with webkit and opera (re: implementing the / in the shorthand already).
17:24:45 <TabAtkins> Bert: Next, CSSOM issues, per anne's request.
17:24:47 <anne42> Bert, if I have to leave beforehand, I'd basically like people to look at the email and give some feedback, some kind of approval or disapproval at the minimum would be cool
17:24:53 <TabAtkins> Bert: Property value api.
17:25:21 <TabAtkins> anne: Currently all apis in cssom are string-based, so every time you query for a property you get a string back which represents the value.
17:25:30 <TabAtkins> anne: the idea is that instead of a string you get a more specialized object back.
17:25:38 <TabAtkins> anne: We discussed the idea briefly at tpac.
17:25:55 <TabAtkins> anne: It would look like a string, but also have typed properties for the values the proeprty supports.
17:26:06 <TabAtkins> anne: Frex, the background property would have a url property
17:26:54 <TabAtkins> anne: Or, frex, length values, if you wanted to animate the length, you could just increase the value of the length using style.width.px or whatnot, rather than asking for a string, parsing it, changing it, sending the string back, and making the browser turn it back to a value.
17:27:05 <TabAtkins> anne: Which is a lot more work than should be necessary.
17:27:11 <TabAtkins> sylvaing: It makes a lot of sense in principle.
17:27:24 <TabAtkins> sylvaing: It's kind of amazing that authors have to reparse css that's parsed by the browser.
17:28:07 <TabAtkins> TabAtkins: Agreed, the bit of work I've done in pure css manipulation has been very annoying due to the string handling.
17:28:26 <TabAtkins> sylvaing: Yeah, the javascript libraries often take away that difficulty, so we're all just spinning cycles.
17:28:50 <TabAtkins> anne: The specific way I'm talking about it, there may be cross-compat issues.  It will no longer do string equality, and typeof will return something new.
17:29:10 <TabAtkins> anne: So we might need, say, a new accessor on the style object.  style.superAwesomeTypeObject.width.px
17:29:26 <TabAtkins> anne: Best is to get an experimental impl in the brwoser and see what happens.
17:29:51 <TabAtkins> szilles: You said you wont' get string equality.
17:30:25 <TabAtkins> anne: Like, if you get a string that's "0px", and use === to test, it would fail, becausee the object isn't a string (though it will act like one in some cases).  == equality will still work.
17:30:45 <TabAtkins> anne: Also, some more tpac issues - the getComputedStyle API, specifically the concept of resolved values.
17:30:57 <TabAtkins> anne: Also, about how individual components get serialized to a string.
17:31:28 <TabAtkins> anne: These are for the string apis.  Currently everyone does something differenet.  We'd like some convergence, and I'd like some feedback on exactly what should happen here.
17:31:31 <TabAtkins> Bert: Current API, or new?
17:31:34 <TabAtkins> anne: Current api.
17:31:59 <TabAtkins> anne: Frex, if you used stylesheet value to go over the stylesheet rules, you get strings, but evereyone has a different canonical form for these string values.
17:32:28 <TabAtkins> anne: I'm trying to define how these should be serialized.  But since everyone does different...
17:32:45 <TabAtkins> sylvaing: Yeah, even if you get convergence, you'll probably be breaking compat with older versions of each browser.
17:33:06 <TabAtkins> sylvaing: I'd like a separate api on the side that can do something new so we dont' have to worry as much about painful compat issues.
17:33:17 <TabAtkins> anne: This is also something that new css drafts should take into account in due course.
17:33:30 <TabAtkins> anne: Frex, <image> type, like gradients, how they should be serialized to string.
17:33:46 <TabAtkins> sylvaing: It would be good to document, if for no other reasons just to see how much damage would be required to converge.
17:33:59 <TabAtkins> sylvaing: So we can see if possibly the property value api might be easier and cheaper for everyone.
17:34:10 <TabAtkins> anne: Yes, but I think we *also* want interop on the string level.
17:34:18 <TabAtkins> dbaron: I agree on string serialization.
17:34:39 <TabAtkins> dbaron: I've been amking changes to our serialization where we might be returning different precisions, etc.
17:34:48 <TabAtkins> dbaron: There were occasional compat problems, but they weren't horrible.
17:34:49 <dbaron> s/agree on/agree we should try to converge on/
17:34:58 <TabAtkins> fantasai: I think some serializations might be harder to change than others.
17:35:23 <TabAtkins> fantasai: At very least, for things that are less common to be parsed, they can converge.
17:35:39 <TabAtkins> sylvaing: In the property value api, the main thing is that you *don't have to* parse anymore.
17:36:04 <TabAtkins> sylvaing: If you no longer have to parse, what's the reason for converging the strings except prettiness?
17:36:14 <TabAtkins> anne: Authors will still depend on it.
17:36:51 <TabAtkins> anne: I alos think that once we start property value api, we may not do all types at the start, just the most common, eg length, color manipulation.  maybe not time and frequency.
17:37:16 <TabAtkins> sylvaing: I agree.  It's not hard to change, we just have a lot of corporate customers depending on existing behavior.  It's why we end up with modes
17:37:32 <TabAtkins> dbaron: Back to anne's point, I agree we shouldn't try and make the value api cover everything.
17:37:43 <TabAtkins> dbaron: times and frequencies i'm not worried about, it's the complex data types i'm worried about.
17:38:04 <TabAtkins> dbaron: A lot of times when adding new properties, i have *no idea* what data structure to use underneath.
17:38:27 <TabAtkins> dbaron: Many of our new property values, even ones in css2, still don't have a sensical mapping to the value api (style level 2)
17:38:36 <TabAtkins> Bert: Have you thought about that, anne?
17:38:36 <dbaron> for the DOM Level 2 Style value api that we implement only for getComputedStyle
17:38:45 <Zakim> +smfr
17:38:50 <TabAtkins> anne: My idea was to have a base type, which is effectively a DOMString which has a cssText property.
17:39:19 <TabAtkins> anne: each property would at least return the base type, serializes to a string.  cssText would return whatever we agree the serialization rules should be.
17:39:50 <TabAtkins> anne: For other properties, we'd have an object that inherits from this base type, and also exposed additional properties, eg color property object as r,g,b properties, maybe alpha, etc.
17:40:00 <TabAtkins> anne: So you'd at least get back the string, and some would expose a little more.
17:40:13 <TabAtkins> anne: And if we have properties that really need this api, we can start defining this at that point.
17:41:02 <TabAtkins> anne: And hopefully CSSOM can modularize as well, so each new css spec can have a cssom part that explains how to serialize the property, and possibly value apis.
17:41:37 <TabAtkins> TabAtkins: So is the idea that the DOMString object contains the current legacy browser serialization, and cssText contains the agreed on proper serialization?
17:41:54 <TabAtkins> anne: No, if you call toString on the object it will just return the cssText property.
17:42:32 <TabAtkins> anne: I don't think we should expose the [something something someething].  Frex, background-image would right now return just the url property, but later on when we change it, it would return a urlList property.
17:43:11 <TabAtkins> Bert: I think we hear some encouragement for the approach, at least, with some caution about possible difficulties.  Is this what you wanted to hear, anne?
17:43:26 <TabAtkins> anne: This is a start.  It would be nice to have the specific emails on www-style get input.
17:43:51 <TabAtkins> sylvaing: Is there anything in your thoughts about api and design that *couldn't* be donee with javascript, so we could experiment with it?
17:44:16 <TabAtkins> anne: I don't think you can extend DOMString.  You may be able to change getComputedStyle itself ot return a custom object.  You could probably get pretty far there.
17:44:46 <TabAtkins> fantasai: As far as css specs giving serialization rules, could you post some examples of how that would look in an actual draft?
17:45:12 <TabAtkins> anne: Sure, in section 7.4 it returns serialization as a generic concept.  I'm hoping to deal with properties that accept multiple components to give instructions.
17:45:22 <TabAtkins> anne: ie, if it's comma separated, serialize it in this way, etc.
17:46:04 <TabAtkins> anne: It can be very simple.  Frex, something that takes a time in seconds it serialized as a number followed by "s".  Or urls serialzied as "url('" followed by literal string followed by "')".
17:46:12 <TabAtkins> fantasai: What about properties that take multiples values?
17:46:38 <TabAtkins> anne: For those my plan is to define that there should be at most 1 space between components, if they're comma separated the comma is adjacent to the previous value and followed by a space, etc.
17:46:46 <TabAtkins> fantasai: So for most properties we'd just have to specify the order?
17:47:02 <TabAtkins> anne: Yeah.  And for things with multiple orders, like background position, there you'd say it is in a specified order.
17:47:56 <TabAtkins> anne: Frex with margin you'd have a rule that when components can be omitted you omit as much as possible, so frex "margin: 2px 0 0 0" serializes as "2px 0 0".
17:48:04 <TabAtkins> Bert: All right, so what you going to do now, anne?
17:48:16 <anne42> http://dev.w3.org/csswg/cssom/
17:48:19 <TabAtkins> anne: I will update the document further.
17:48:30 <TabAtkins> anne: I need to finish some more details on serialization and how it maps to getComputedStyle.
17:48:48 <TabAtkins> anne: Next step is to draft the proeprty value proposal, and draft a few samples like the color interface, and get feedback.
17:49:01 <Zakim> -anne
17:49:16 <TabAtkins> Bert: Next topic, css3 values.
17:49:31 <TabAtkins> Bert: The agenda says scinot, but the emails talk about other things.
17:49:44 <TabAtkins> dbaron: I haven't gotten a chance to write my proposal calc (regarding min/max) yet.
17:49:54 <TabAtkins> Bert: I just sent an email with an example grammar this morning.
17:50:12 <TabAtkins> Bert: We may want to talk about that later, once people have a chance to read it.
17:50:21 <TabAtkins> Bert: So, back to scinot.
17:50:27 <TabAtkins> Bert: Any actions from that last week?
17:50:45 <TabAtkins> sylvaing: ONly concerns, which I introduced, was that it would become a new CSS hack to separate browsers.
17:50:59 <TabAtkins> sylvaing: But it turns out that IE already does this, so the hack has been out there already.
17:51:05 <TabAtkins> Bert: Explain the hack?
17:51:23 <TabAtkins> sylvaing: Once a new browser supports scinot, you can use it to exclude older browsers from parsing that rule.
17:51:45 <TabAtkins> sylvaing: I don't think it's a serious issue, since Selectors already allows that, and Selectors-based ones are more powerful anyway.
17:51:56 <TabAtkins> sylvaing: So I don't think scinot is much of a hack in practice anyway.
17:52:07 <TabAtkins> sylvaing: But given that the hack is *already out there* in IE if you want it, I think the issue is moot.
17:52:21 <TabAtkins> Bert: I understand for the selectors hack, but what's this about IE notation already doing the hack?
17:52:35 <TabAtkins> sylvaing: in IE, you can already specify "width:1e2px", and it will work in IE but not other browsers.
17:52:59 <TabAtkins> sylvaing: So the argumeent that we shouldn't introduce this notation because it would introduce this hack is bogus, since it's already supported.
17:53:14 <TabAtkins> Bert: In fact it seems to make the hack impossible to use, since legacy browsers already use it.
17:53:41 <TabAtkins> Bert: Is anyone going to write up examples?
17:53:54 <TabAtkins> szilles: I think Chris got tasked with some of that; this is based just on reading the minutes.
17:54:28 <TabAtkins> Bert: So no new information?
17:54:51 <TabAtkins> TabAtkins: Apart from the knowledge about the ie hack, no.  We might want to ping Chris about it.
17:56:24 <TabAtkins> sylvaing: What are the details of exactly how SVG allows it?
17:56:42 <TabAtkins> TabAtkins: It was explained on the list; I forget the exact details, but some types of values allow it, but not all.
17:56:52 <TabAtkins> sylvaing: So like Hakon's talking about allowing it when necessary?
17:57:04 <TabAtkins> TabAtkins: Not quite.  it's not property-specific, but rather value specific.
17:57:36 <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Sep/0304.html
17:57:50 <TabAtkins> TabAtkins: Also, HTML5 and JS all rely on the ecmascript serialization, which uses scinot.  So we could align with HTML as well.
17:58:03 <TabAtkins> Bert: All right, so leet's move to a simpler topic for now.  Image fit?
17:58:23 <TabAtkins> fantasai: I want to write up a response to the most recent image-fit email.  Some things I agreed with, some I didn't.
17:58:32 <Bert> http://lists.w3.org/Archives/Public/www-style/2010Jan/0476.html
17:58:39 <TabAtkins> Bert: Ok, let's just look at the message detailed in the agenda.
17:58:52 <shepazu> (I think image-fit would be a good topic for discussion in the FXTF)
17:59:15 <TabAtkins> bert: 4 issues in the email.
17:59:25 <TabAtkins> Bert: When dealing with overflow on replaced elements.
17:59:43 <TabAtkins> fantasai: I think last time I discussed this with Molly, we suggested always clipping.
18:00:01 <TabAtkins> Bert: That's different from what's in the email, which suggests overflowing and letting overflow apply.  You're suggesting always clip?
18:00:19 <TabAtkins> szilles: That seems dangerous if you're losing content.  Best might be scrollbars; some kind of warning tha tyou're not seeing all the image.
18:00:45 <TabAtkins> Bert: I do see examples in practice of people using a wrapper to force clipping the image.
18:00:49 <TabAtkins> TabAtkins: I've done precisely that.
18:01:00 <TabAtkins> fantasai: [something about default behavior]
18:01:07 <TabAtkins> fantasai: contain is no scrolling, just a cover.
18:01:19 <TabAtkins> Bert: As soon as you use that, you're assured you will get clipping.  That's sort of explicit?
18:01:47 <TabAtkins> fantasai: And then image-position lets you specify exactly which part gets shown.  I don't htink it makes sense to combine that with scrollbars.
18:01:52 <Skaterband1> Skaterband1 has joined #CSS
18:01:56 <Skaterband1> hi all
18:01:59 <TabAtkins> szilles: As long as it's clear that it's a conscious decision to force the clipping.
18:02:16 <TabAtkins> Bert: I like this idea, but are there any other ideas?
18:02:25 <Skaterband1> i was needing some irc help
18:02:34 <TabAtkins> Bert: No dissent.  We may need to come back to this topic, since there are more issues anyway.
18:02:46 <TabAtkins> Bert: I suggest we continue on image-fit next week.  anything else to be said?
18:03:07 <Skaterband1> im trying to build a multi room irc
18:03:24 <TabAtkins> dsinger: I sent an email to peter/glazou on hosting the meeting, but i haven't heard anything back from them.  who should I send it to?
18:03:27 <TabAtkins> bert: Send it to me.
18:03:41 <Skaterband1> Skaterband1 has left #CSS
18:03:48 <Skaterband1> Skaterband1 has joined #CSS
18:03:53 <Skaterband1> hi
18:03:55 <Zakim> -TabAtkins
18:03:56 <Zakim> -SteveZ
18:03:58 <Zakim> -sylvaing
18:04:00 <Zakim> -[Microsoft]
18:04:00 <Zakim> -smfr
18:04:01 <Zakim> -David_Baron
18:04:02 <Zakim> -CesarAcebal
18:04:04 <Skaterband1> Skaterband1 has left #CSS
18:04:05 <Zakim> -Bert
18:04:29 <Zakim> -[Apple]
18:04:30 <Zakim> Style_CSS FP()12:00PM has ended
18:04:31 <Zakim> Attendees were dsinger_, Bert, David_Baron, sylvaing, CesarAcebal, arronei, SteveZ, TabAtkins, anne, fantasai, dsinger, smfr
18:16:18 <CesarAcebal> CesarAcebal has joined #css
18:51:06 <sylvaing> sylvaing has joined #css
19:45:08 <Zakim> Zakim has left #CSS
20:05:16 <CesarAcebal> CesarAcebal has left #css
20:11:14 <Lachy> Lachy has joined #css
20:39:21 <Lachy> Lachy has joined #css
20:41:10 <Lachy> Lachy has joined #css
22:23:28 <fantasai> Bert: is the www-style moderation queue clear? someone mentioned emails being stuck in the queue
22:25:39 <Bert> I'll take a look...
22:28:40 <Bert> There is Leif Arne Storset's message, but he already quoted it in his mail from yesterday.
22:31:17 <Bert> Some other messages that look more like the senders forgot to subscribe...
23:18:24 <Lachy> Lachy has joined #css