Options:
- # Session Start: Tue Jul 30 00:00:00 2013
- # Session Ident: #css
- # [00:00] <fantasai> I wasn't there. Don't know if there's other info that's relevant
- # [00:00] <fantasai> other than "it was approved"
- # [00:00] <fantasai> etc.
- # [00:00] <plinss> there wasn't, fwiw
- # [00:00] <fantasai> Besides which, I don't want to be in the business of transcribing decisions recorded on Twitter to w3c-css-wg
- # [00:01] <fantasai> That just seems like not a good idea.
- # [00:01] <fantasai> :)
- # [00:01] <plinss> that's a good policy
- # [00:02] <fantasai> So, I'd prefer if you guys would send the announcement to wherever you want to send it (www-style or w3c-css-wg)
- # [00:02] <fantasai> I'm happy to coordinate with Bert on publishing
- # [00:03] <plinss> there is generally a formal announcement by w3c for CR transitions (being a call for implementations and all)
- # [00:03] <fantasai> usually that's posted with the publication, right?
- # [00:04] <plinss> yes
- # [00:04] <fantasai> yeah
- # [00:04] <fantasai> So are you saying that, you'll post a transition call result to Twitter, but to tell the WG members directly, you want to wait until W3C posts about the publication???
- # [00:05] <plinss> no, I said I was going to send an email today, I just didn't get to it yet
- # [00:06] <fantasai> ok
- # [00:06] <fantasai> yeah
- # [00:15] <TabAtkins> plinss: So, thoughts on just using a data-for attribute to associate values with types/properties/descriptors/at-rules and attributes/methods with interfaces?
- # [00:15] <TabAtkins> plinss: Rather than the previously suggested method of parsing out titles in the form "prop!!value".
- # [00:21] <TabAtkins> plinss: Handled in the obvious way - parse the data-for value. If it looks like @foo, it's a value for that at-rule. Looks like <foo>, it's a value for that type. Looks like [something I haven't decided yet that specifies both at-rule and descriptor], it's a value for that descriptor. Otherwise, it's a value for that property.
- # [00:22] <TabAtkins> And for the IDL dfn types, it's assumed that the data-for value is an interface.
- # [00:23] <TabAtkins> For the descriptor value, maybe just <dfn data-for="@foo bar-baz">qux</dfn> to define a "qux" value for the bar-baz descriptor for the @foo rule.
- # [00:24] <TabAtkins> And then I can make it a fatal error to have a value dfn without a valid for.
- # [01:17] * leaverou is now known as leaverou_away
- # [01:22] <plinss> TabAtkins: yeah, I think that'll work
- # [01:31] <fantasai> TabAtkins: Aren't we putting that in the descdef table?
- # [01:32] <TabAtkins> fantasai: For descriptors, yes.
- # [01:32] <TabAtkins> But that doesn't help you when you say "this value belongs to this descriptor", and there's >1 descriptor of that name among all our at-rules.
- # [01:32] <fantasai> TabAtkins: I don't think it makes sense to ask editors to type all that out
- # [01:33] <fantasai> TabAtkins: When it's typically already in the descdef table right above the <dfn>
- # [01:33] <TabAtkins> ...what?
- # [01:33] <TabAtkins> Oh, that.
- # [01:34] <TabAtkins> Sorry, but it's still not generally associatable. We *need* this to be easily and correctly machine-parseable.
- # [01:34] <fantasai> That's great, don't make me type it 15 times per property
- # [01:34] <TabAtkins> Though, we *could* let data-for apply to a container, like data-dfn-type.
- # [01:34] <TabAtkins> So you just put it once on your <dl> and it applies to all the dfns inside.
- # [01:34] * fantasai also generally not in favor of invisible metadata
- # [01:34] * fantasai if it can be usably visible instead
- # [01:35] <fantasai> TabAtkins: That's easier to deal with, for sure
- # [01:35] <TabAtkins> Generally, you'd write <dl data-for="property" data-dfn-type="value"><dt><dfn>auto</dfn><dd>...</dl>
- # [01:35] <TabAtkins> Or in my preprocessor, <dl for="property" dfn-type="value">
- # [01:35] <fantasai> TabAtkins: Sure, can we make it even easier by assuming an <dl> applies to all propdefs/descdefs in the section?
- # [01:36] <TabAtkins> fantasai: I'm not sure that's true.
- # [01:36] <fantasai> TabAtkins: Hm, fair point. It's not true
- # [01:36] <fantasai> TabAtkins: You'd have to check against the values field first
- # [01:36] <fantasai> TabAtkins: e.g. break-before/after/inside was at one point all in one section
- # [01:36] <fantasai> TabAtkins: and inside only takes a subset of the values
- # [01:36] <fantasai> TabAtkins: But the information *is* there and machine-parseable
- # [01:37] <fantasai> TabAtkins: It just might not be super easy to parse
- # [01:37] <TabAtkins> Yeah, and even if we parsed the grammar, we still might fail - two properties might be defined in the same section, and take the same keyword, but interpret it differently.
- # [01:37] <fantasai> TabAtkins: Since you want to cross-check the <dl> against the grammar
- # [01:37] <fantasai> TabAtkins: If they do, they should be in different subsections imho ^_^
- # [01:37] <fantasai> TabAtkins: Subsections are great. Specs should use them liberally.
- # [01:37] <TabAtkins> Maybe, but that's still asking for quite a bit.
- # [01:37] <fantasai> TabAtkins: Makes it easier for people to cross-reference things.
- # [01:38] <TabAtkins> I dont' disagree. ^_^
- # [01:38] <fantasai> TabAtkins: I think it's asking for a lot less than tagging everything with machine-only junk!!
- # [01:38] <TabAtkins> Anyway, starting from a known-correct metadata tagging and then expanding into grammar parsing works.
- # [01:38] <fantasai> sure, once you tag *everything*
- # [01:38] <fantasai> which aint happening
- # [01:39] <TabAtkins> Sure it is. It's easy!
- # [01:39] <TabAtkins> Particularly when I do it myself, to everybody's specs.
- # [01:39] <fantasai> ~_~
- # [01:39] <fantasai> I am not convinced this is a good idea.
- # [01:40] <TabAtkins> Regardless of how smart we are, we can't auto-detect everything, so some metadata tagging is required in the end.
- # [01:40] <fantasai> sure, but only in really weird cases
- # [01:40] <fantasai> I don't think you should junk up everyone's specs if it's not required
- # [01:40] <TabAtkins> I definitely prefer making my processor smarter as we go along, but I also prefer not holding back a feature until I implement section-tracking and grammar-parsing.
- # [01:43] <fantasai> what are you trying to implement anyway?
- # [01:43] * fantasai only knows you want us to put lots of metadata for it, whatever it is
- # [01:44] <TabAtkins> https://twitter.com/tabatkins/status/361942823748108288
- # [01:45] <TabAtkins> Except better, with all the individual keyword values linking to their definitions when possible, etc.
- # [01:45] <fantasai> I think it's perfectly usable to link to just the propdef and the value types to their defs
- # [01:46] <TabAtkins> That's cool, but we can do better.
- # [01:46] <fantasai> I don't see really much additional value in linking e.g. ''auto'' to its particular <dfn> inside the section with the propdef.
- # [01:46] <TabAtkins> Including doing things like listing all the values for a <type>.
- # [01:46] <fantasai> And I certainly don't think that additional value is worth the effort you want us to put into maintaining your metadata.
- # [01:46] <TabAtkins> You're making this out to be way more difficult than it is.
- # [01:47] <TabAtkins> It's the difference between <dfn>auto</dfn> and <dfn for=my-prop>auto</dfn>
- # [01:48] <fantasai> Maybe I'm just not seeing the utility of linking to that <dfn> from this property table.
- # [01:48] <fantasai> so asking me to put any effort into it seems useless :)
- # [01:48] <plinss> fantasai, it also allows generated xrefs to be correct, if some text in the spec links to the 'auto' property, the pre-processors can link to the correct one...
- # [01:48] <TabAtkins> If properties don't float your boat, types might. Being able to machine-generate a table telling you all of the possible <image> values, for example.
- # [01:49] <fantasai> plinss: How can they link to the correct one, unless I tag the xref, too?
- # [01:49] <fantasai> plinss: at which point, I might as well just use <a href="
- # [01:49] <TabAtkins> Uh, no?
- # [01:49] <fantasai> plinss: I refer to e.g. ''auto'' margins in a section defining something else that takes an ''auto'' value frequently enough
- # [01:49] <TabAtkins> <a for=my-prop>foo</a> is way easier than an href.
- # [01:49] <fantasai> plinss: that I wouldn't want you interpreting things
- # [01:50] <fantasai> plinss: out of context
- # [01:51] <fantasai> TabAtkins: How are you proposing to create a list of all possible <image> values?
- # [01:51] <plinss> not only is <a for=my-prop>foo</a> easier than an href, it'll always point to the right place even if the definition of the value moves, say to a different spec
- # [01:51] <TabAtkins> fantasai: All the <dfns> for things that are part of <image> have a for=<image> on them.
- # [01:52] <fantasai> TabAtkins: Okay, I can see that being useful.
- # [01:52] <fantasai> plinss: Usually I mark values as ''foo''.
- # [01:53] <fantasai> plinss: and that has different output than just <a>foo</a>
- # [01:53] <fantasai> plinss: so... what are you expecting us to use?
- # [01:53] <TabAtkins> fantasai: It has the same output as <a data-dfn-type=value>foo</a>, which is what it desugars to.
- # [01:53] <fantasai> plinss: for consistency, a value should always be typeset the same way no matter what the linking behavior
- # [01:53] <TabAtkins> Agreed, which is why that's true. ^_^
- # [01:54] <plinss> right, I don't care what the input to the pre-processor is, you and Tab can make up any microsyntax you want to make it easy for the spec authors
- # [01:55] <plinss> I'm just looking at the output of the pre-processor so that I have enough metadata to find all the constructs and link them together appropriately
- # [02:00] <plinss> fantasai, also note that my spec parser can and will make assumptions if the metadata is missing, like a bare <dfn>'value'</dfn> (with an id) will get interpreted as a value and linked to the previously defined property
- # [02:00] <plinss> we just need a mechanism to be explicit when those kinds of assumptions are wrong
- # [02:00] <fantasai> I think you want <dfn>''value''</dfn>
- # [02:00] <fantasai> actually
- # [02:00] <plinss> (I take either)
- # [02:01] <fantasai> Ok, yeah, that's fine
- # [02:01] <fantasai> I think we need to document this stuff, fwiw...
- # [02:01] <TabAtkins> (Note that those are the same assumptions that my preprocessor makes - when I detect them, I tag the dfn explicitly just to prevent any confusion.)
- # [02:01] <plinss> the specs actually use ‘’, fwiw
- # [02:01] <TabAtkins> And yes, I'm documenting it.
- # [02:01] <TabAtkins> plinss: Yes, that's the output. fantasai is talking about the input document.
- # [02:02] <plinss> ok
- # [02:02] <fantasai> TabAtkins: Can you get it linked up from http://wiki.csswg.org/tools
- # [02:02] <fantasai> ?
- # [02:02] <fantasai> Because documentation isn't very useful if people don't find it
- # [02:02] <TabAtkins> fantasai: Yeah, as soon as I get it reasonably finished.
- # [02:02] <fantasai> plinss: oh, yeah. ''value'' is the src shorthand for value :)
- # [02:02] * fantasai forgot you're parsing the output
- # [02:09] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
- # [02:14] * Joins: liam (liam@public.cloak)
- # [02:16] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
- # [02:20] <TabAtkins> plinss: So, interesting issue. I clearly messed up the markup for "flex" in the TR version, but now I have two property anchors with the same linking text in the same spec.
- # [02:21] <TabAtkins> So... I have no way to instruct the preprocessor which one I want.
- # [02:21] <TabAtkins> Had I run flexbox through my preprocessor, this wouldn't have happened, but that's neither here nor there.
- # [02:22] <plinss> I presume the actual anchor are unique...
- # [02:23] <TabAtkins> Yes.
- # [02:23] <TabAtkins> So I can do a manual href, but I can't auto-link.
- # [02:24] <plinss> hopefully we can update /tr specs with only metadata fixes easily...
- # [02:24] <TabAtkins> Yes, hopefully.
- # [02:24] <TabAtkins> Well, once we publish a new LC of flexbox, it'll fix itself.
- # [02:25] <TabAtkins> For now I'll mark this as an ignore.
- # [02:25] <TabAtkins> And I should probably go through and find all the conflicts here.
- # [02:27] <plinss> heh, if my algorithm is correct, the html5 spec defines 411 html attributes
- # [02:29] <plinss> actually, make that 438
- # [02:31] <fantasai> I think there is a policy for in-place edits of a /TR spec, and fixing links is ok. IIRC.
- # [02:31] <fantasai> But, doing it is usually not worth it unless you're W3C Staff and have write access...
- # [02:31] <fantasai> :/
- # [02:35] * Joins: rhauck1 (~Adium@public.cloak)
- # [02:40] * Joins: cabanier (~cabanier@public.cloak)
- # [02:41] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
- # [02:42] * Quits: rhauck1 (~Adium@public.cloak) (Ping timeout: 180 seconds)
- # [02:47] * Quits: lmclister (~lmclister@public.cloak) (lmclister)
- # [02:57] <TabAtkins> plinss, fantasai: We auto-export all of the types except for basic dfns. Should we allow you to link to a basic dfn, even if it's unexported, if you specify the spec? Or should we just treat this as a nudge to fix the spec and export that term?
- # [02:57] <plinss> I don't have any opinion on that one...
- # [03:00] <plinss> TabAtkins: ok, the api changes and last phase of the spec parser have landed
- # [03:00] <TabAtkins> Woo, I can remove my type translator now.
- # [03:01] <plinss> I just sent you an email with all the magic dfn code so we can sync up
- # [03:01] <TabAtkins> kk
- # [03:03] <plinss> and here's the current list of dfn types and *def prefixes:
- # [03:03] <plinss> { 'propdef' : 'property', 'valuedef': 'value', 'at-ruledef': 'at-rule', 'descdef': 'descriptor', 'typdef': 'type', 'funcdef': 'function',
- # [03:03] <plinss> 'selectordef': 'selector', 'html-elemdef': 'html-element', 'html-attrdef': 'html-attribute', 'interfacedef': 'interface', 'methoddef': 'method',
- # [03:03] <plinss> 'attrdef': 'attribute', 'dictdef': 'dictionary', 'enumdef': 'enum', 'constdef': 'const' }
- # [03:04] <TabAtkins> Yes, this matches me.
- # [03:04] <plinss> cool
- # [03:09] * Joins: teoli (~teoli@public.cloak)
- # [03:13] * Joins: sgalineau (~sgalineau@public.cloak)
- # [03:16] * Quits: teoli (~teoli@public.cloak) (Ping timeout: 180 seconds)
- # [03:18] * Joins: jdaggett (~jdaggett@public.cloak)
- # [03:35] <plinss> TabAtkins: I just set up http(s)://api.csswg.org/ so when your pre-processor is ready, we can put it there
- # [03:35] <TabAtkins> Cool.
- # [03:35] <plinss> I also mirrored Shepherd's API at api.csswg.org/shepherd/ (equivalent to test.csswg.org/shepherd/api/ )
- # [03:40] * Quits: sgalineau (~sgalineau@public.cloak) ("Computer has gone to sleep.")
- # [04:10] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
- # [05:38] * RRSAgent excuses himself; his presence no longer seems to be needed
- # [05:38] * Parts: RRSAgent (rrsagent@public.cloak) (RRSAgent)
- # [06:53] * Joins: dbaron (~dbaron@public.cloak)
- # [07:17] * Joins: lmclister (~lmclister@public.cloak)
- # [07:19] * Joins: krit (~krit@public.cloak)
- # [07:38] * Quits: lmclister (~lmclister@public.cloak) (lmclister)
- # [07:56] * Joins: zcorpan (~zcorpan@public.cloak)
- # [08:01] * Quits: krit (~krit@public.cloak) ("Leaving.")
- # [08:06] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
- # [08:16] * Joins: krit (~krit@public.cloak)
- # [08:27] * Joins: krit1 (~krit@public.cloak)
- # [08:27] * Quits: krit (~krit@public.cloak) (Client closed connection)
- # [08:30] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
- # [08:48] * Joins: glenn (~gadams@public.cloak)
- # [08:53] * Joins: michou (~mibalan@public.cloak)
- # [08:56] * Joins: zcorpan (~zcorpan@public.cloak)
- # [09:04] * Joins: teoli (~teoli@public.cloak)
- # [09:11] * Quits: teoli (~teoli@public.cloak) (Ping timeout: 180 seconds)
- # [09:15] * Quits: krit1 (~krit@public.cloak) (Ping timeout: 180 seconds)
- # [09:18] * Joins: krit (~krit@public.cloak)
- # [09:21] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
- # [09:46] * Joins: teoli (~teoli@public.cloak)
- # [09:48] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
- # [09:50] * Joins: tobie (tobie@public.cloak)
- # [09:55] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
- # [10:06] * Joins: Ms2ger (~Ms2ger@public.cloak)
- # [10:07] * Joins: zcorpan (~zcorpan@public.cloak)
- # [10:08] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
- # [10:55] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
- # [10:58] * Joins: glenn (~gadams@public.cloak)
- # [11:02] * Quits: michou (~mibalan@public.cloak) ("Leaving.")
- # [11:04] * Joins: abucur (~abucur@public.cloak)
- # [11:05] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
- # [11:27] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
- # [11:29] * Joins: teoli (~teoli@public.cloak)
- # [13:30] * Joins: michou (~mibalan@public.cloak)
- # [13:35] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
- # [13:42] * Joins: darktears (~darktears@public.cloak)
- # [14:01] * Joins: plh (plehegar@public.cloak)
- # [14:02] * Joins: florian (~yaaic@public.cloak)
- # [14:04] * Quits: florian (~yaaic@public.cloak) ("")
- # [14:06] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
- # [14:19] * Joins: zcorpan (~zcorpan@public.cloak)
- # [14:59] * Joins: liam (liam@public.cloak)
- # [15:06] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
- # [15:06] * Joins: zcorpan (~zcorpan@public.cloak)
- # [15:48] * Joins: sgalineau (~sgalineau@public.cloak)
- # [15:55] * Quits: sgalineau (~sgalineau@public.cloak) (Ping timeout: 180 seconds)
- # [16:00] * Quits: krit (~krit@public.cloak) (Ping timeout: 180 seconds)
- # [16:00] * Joins: krit (~krit@public.cloak)
- # [16:01] * Quits: krit (~krit@public.cloak) ("Leaving.")
- # [16:20] * Quits: michou (~mibalan@public.cloak) ("Leaving.")
- # [16:21] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
- # [16:43] * Joins: glenn (~gadams@public.cloak)
- # [16:51] * Joins: zcorpan (~zcorpan@public.cloak)
- # [16:59] * Joins: michou (~mibalan@public.cloak)
- # [17:11] * Joins: dbaron (~dbaron@public.cloak)
- # [17:29] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
- # [17:32] * Quits: michou (~mibalan@public.cloak) ("Leaving.")
- # [17:45] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
- # [17:52] * Quits: decadance (~decadance@public.cloak) (Client closed connection)
- # [17:58] * Joins: krit (~krit@public.cloak)
- # [18:00] * Joins: krit1 (~krit@public.cloak)
- # [18:05] * Quits: krit (~krit@public.cloak) (Ping timeout: 180 seconds)
- # [18:15] * Joins: cabanier (~cabanier@public.cloak)
- # [18:17] * Joins: rhauck (~Adium@public.cloak)
- # [18:28] * Joins: decadance (~decadance@public.cloak)
- # [18:28] * Joins: lmclister (~lmclister@public.cloak)
- # [19:00] * leaverou_away is now known as leaverou
- # [19:00] <leaverou> TabAtkins: what replaced box-align? Can't find it. Thx!
- # [19:05] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
- # [20:03] * Joins: dbaron (~dbaron@public.cloak)
- # [20:24] * leaverou is now known as leaverou_away
- # [20:27] * leaverou_away is now known as leaverou
- # [20:37] <teoli> leaverou: align-items / justify-content ?
- # [20:38] * Joins: zcorpan (~zcorpan@public.cloak)
- # [20:39] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
- # [20:59] <fantasai> leaverou: http://www.w3.org/TR/css3-flexbox/#alignment
- # [21:01] * Quits: abucur (~abucur@public.cloak) (Client closed connection)
- # [21:15] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
- # [21:16] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
- # [21:26] * Joins: dbaron (~dbaron@public.cloak)
- # [21:31] <leaverou> fantasai: this doesn't help :(
- # [21:31] <leaverou> so box-align was split into 2 properties? I wasn't really following flexbox back then
- # [21:34] <fantasai> No, I think it was replaced with one or the other. Can't remember which one 'box-align' was.
- # [21:35] <fantasai> leaverou: If you want pictures, http://www.w3.org/TR/css3-align/#overview
- # [21:35] <fantasai> inline = main axis
- # [21:35] <fantasai> My best guess is that box-align -> align-self
- # [21:37] * fantasai somewhat tempted to write a Flexbox Mapping document, explaining how all the variants of flexbox relate to each other
- # [21:37] <leaverou> fantasai: there was an index that in the changes section of a flexbox draft
- # [21:37] <leaverou> but I can't find it to save my life right now
- # [21:38] <fantasai> leaverou: maybe in an older WD?
- # [21:38] <leaverou> fantasai: yes, but I looked in the previous versions
- # [21:38] <leaverou> and couldn't find it
- # [21:38] <leaverou> which was weird, cause I was looking at it like a few days ago
- # [21:39] <fantasai> leaverou: if you describe what it does, I can tell you which one it became :)
- # [21:39] <leaverou> fantasai: I have no idea, I've barely looked at flexbox *blush*
- # [21:41] <fantasai> http://dev.opera.com/articles/view/advanced-cross-browser-flexbox/
- # [21:48] <fantasai> leaverou: ^
- # [21:49] <leaverou> thanks!
- # [21:59] * Joins: jdaggett (~jdaggett@public.cloak)
- # [22:06] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
- # [22:16] * Joins: dbaron (~dbaron@public.cloak)
- # [23:02] <leaverou> fantasai: what about grid-column-align in Grid Layout?
- # [23:05] <fantasai> align-self or justify-self, depending on the axis
- # [23:05] <fantasai> align is "vertical" (block), justify is "horizonal" (inline)
- # [23:08] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
- # [23:13] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
- # [23:13] <leaverou> fantasai: what axis was grid-column-align for?
- # [23:13] * Quits: tobie (tobie@public.cloak)
- # [23:24] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
- # [23:24] * Quits: krit1 (~krit@public.cloak) (Client closed connection)
- # [23:27] * Joins: dbaron (~dbaron@public.cloak)
- # [23:27] * Joins: rhauck (~Adium@public.cloak)
- # [23:34] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
- # [23:45] * Quits: plh (plehegar@public.cloak) ("Leaving")
- # [23:57] * Joins: tobie (tobie@public.cloak)
- # Session Close: Wed Jul 31 00:00:01 2013
The end :)