/irc-logs / w3c / #fx / 2012-01-23 / end

Options:

  1. # Session Start: Mon Jan 23 00:00:00 2012
  2. # Session Ident: #fx
  3. # [00:02] * Joins: cyril (chatzilla@203.12.172.254)
  4. # [00:29] <hober> heycam: yes
  5. # [00:30] <heycam> hober, thanks. (also wanted confirmation to remind people in the channel given the agenda email was sent out more than a week ago. :))
  6. # [00:30] <hober> *nod*
  7. # [00:44] * Quits: cyril (chatzilla@203.12.172.254) (Quit: ChatZilla 0.9.88 [Firefox 9.0.1/20111220165912])
  8. # [02:32] * heycam is now known as heycam|away
  9. # [02:34] * heycam|away is now known as heycam
  10. # [03:20] * heycam is now known as heycam|away
  11. # [04:19] * heycam|away is now known as heycam
  12. # [11:07] * heycam is now known as heycam|away
  13. # [17:18] * Joins: krit (Adium@192.150.10.201)
  14. # [18:07] * Quits: krit (Adium@192.150.10.201) (Quit: Leaving.)
  15. # [18:08] * Joins: shepazu (shepazu@128.30.52.169)
  16. # [18:09] * Joins: krit (Adium@192.150.10.201)
  17. # [18:46] * Quits: shepazu (shepazu@128.30.52.169) (Quit: shepazu)
  18. # [19:15] * Joins: shepazu (shepazu@128.30.52.169)
  19. # [19:16] * Quits: krit (Adium@192.150.10.201) (Quit: Leaving.)
  20. # [19:24] * Quits: shepazu (shepazu@128.30.52.169) (Quit: shepazu)
  21. # [19:31] * Joins: shepazu (shepazu@128.30.52.169)
  22. # [19:48] * Joins: krit (Adium@192.150.10.201)
  23. # [20:04] * Joins: dbaron (dbaron@159.63.23.38)
  24. # [20:24] * Quits: krit (Adium@192.150.10.201) (Ping timeout)
  25. # [20:37] * Joins: krit (Adium@192.150.10.201)
  26. # [21:25] * Joins: tpod (tpod@66.87.2.94)
  27. # [21:25] * Quits: krit (Adium@192.150.10.201) (Quit: Leaving.)
  28. # [21:27] * Joins: tpod_ (tpod@66.87.0.185)
  29. # [21:28] * Quits: tpod (tpod@66.87.2.94) (Ping timeout)
  30. # [21:28] * tpod_ is now known as tpod
  31. # [21:31] * Joins: krit (Adium@192.150.10.201)
  32. # [21:42] * Quits: tpod (tpod@66.87.0.185) (Quit: Colloquy for iPod touch - http://colloquy.mobi)
  33. # [22:02] * heycam|away is now known as heycam
  34. # [22:03] * Joins: smfr (smfr@17.212.152.232)
  35. # [22:07] <ed> trackbot, start telcon
  36. # [22:07] * trackbot is preparing a teleconference
  37. # [22:07] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
  38. # [22:07] <RRSAgent> logging to http://www.w3.org/2012/01/23-fx-irc
  39. # [22:07] <trackbot> RRSAgent, make logs world
  40. # [22:07] <RRSAgent> I have made the request, trackbot
  41. # [22:07] * Joins: Zakim (rrs-bridgg@128.30.52.169)
  42. # [22:07] <trackbot> Zakim, this will be 3983
  43. # [22:07] <Zakim> ok, trackbot; I see GA_FXTF()4:00PM scheduled to start now
  44. # [22:07] <trackbot> Meeting: CSS-SVG Task Force Teleconference
  45. # [22:07] <trackbot> Date: 23 January 2012
  46. # [22:08] * ed zakim, who's here?
  47. # [22:08] * Zakim GA_FXTF()4:00PM has not yet started, ed
  48. # [22:08] * Zakim sees on irc: RRSAgent, smfr, krit, dbaron, shepazu, krijnh, stearns, plinss, ed, heycam, fantasai, CSSWG_LogBot, hober, paul___irish, trackbot
  49. # [22:08] * ed zakim, code?
  50. # [22:09] * Zakim the conference code is 3983 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), ed
  51. # [22:09] * Joins: vhardy (vhardy@192.150.10.200)
  52. # [22:10] * heycam joined, wonders why zakim doesn't announce it
  53. # [22:10] * ed hey zakim, keep better track of the who's on the call please ;)
  54. # [22:10] <hober> Zakim, who is on the call?
  55. # [22:10] <Zakim> GA_FXTF()4:00PM has not yet started, hober
  56. # [22:10] <Zakim> On IRC I see vhardy, Zakim, RRSAgent, smfr, krit, dbaron, shepazu, krijnh, stearns, plinss, ed, heycam, fantasai, CSSWG_LogBot, hober, paul___irish, trackbot
  57. # [22:10] * Joins: dino (dino@121.45.218.218)
  58. # [22:10] <hober> Zakim, start GA_FXTF
  59. # [22:10] <Zakim> I don't understand 'start GA_FXTF', hober
  60. # [22:10] * paul___irish is now known as paul_irish
  61. # [22:11] * dino zakim, passcode?
  62. # [22:11] * Zakim the conference code is 3983 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), dino
  63. # [22:11] <ed> present+ VH, ED, CM, SF
  64. # [22:11] * ed please fill in who I missed :)
  65. # [22:12] <dino> zakim, who is here?
  66. # [22:12] <Zakim> GA_FXTF()4:00PM has not yet started, dino
  67. # [22:12] <Zakim> On IRC I see dino, vhardy, Zakim, RRSAgent, smfr, krit, dbaron, shepazu, krijnh, stearns, plinss, ed, heycam, fantasai, CSSWG_LogBot, hober, paul_irish, trackbot
  68. # [22:12] <hober> present+
  69. # [22:12] <vhardy> ScribeNick: vhardy
  70. # [22:12] <ed> Agenda: http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0014.html
  71. # [22:12] <vhardy> Topic: Proposition for CSS Animations and Transitions on SVG attributes
  72. # [22:13] <ed> http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0168.html
  73. # [22:13] <vhardy> ed: this was discussed at the SVG F2F two weeks ago. We have a proposal from Microsoft.
  74. # [22:13] <vhardy> ... the outcome of the discussion is that the group believes the proposal is the best one so far and we would like to know if anybody has objections to the proposal.
  75. # [22:13] * shepazu regrets, attending the Audio WG F2F
  76. # [22:14] <vhardy> smfr: do we have a list of the property names?
  77. # [22:14] <vhardy> ... are we adding a list of properties to CSS through this promotion. I am concerned about properties like 'r', 'tx' or 'cx'.
  78. # [22:14] <vhardy> ... another concern is that we may be using names that CSS might want to use for other things in the future.
  79. # [22:15] <vhardy> vhardy: the list of property names is in the proposal.
  80. # [22:17] <vhardy> dino: I think the next step is to talk to the CSS wg. There are two options. Here are the properties we want to add to the CSS namespace. Do we need to prefix the properties or not. I do not think we can make much decision here.
  81. # [22:18] <vhardy> smfr: I agree.
  82. # [22:18] <vhardy> vhardy: I agree.
  83. # [22:18] <vhardy> dino: I agree too :-)
  84. # [22:18] <vhardy> ed: in that case, we need to summarize the properties that we plan to add and send it to the CSS WG.
  85. # [22:20] <vhardy> ACTION: Patrick Dengler to send an email to the CSS WG asking for feedback on proposed list of additional properties to be added when promoting SVG attributes to properties. Ask if properties should be prefixed or not to deal with possible collisions.
  86. # [22:20] * trackbot noticed an ACTION. Trying to create it.
  87. # [22:20] * RRSAgent records action 1
  88. # [22:20] <trackbot> Sorry, couldn't find user - Patrick
  89. # [22:21] <vhardy> ACTION: Erik Dahlstrohm (with Patrick Dengler) to send an email to the CSS WG asking for feedback on proposed list of additional properties to be added when promoting SVG attributes to properties. Ask if properties should be prefixed or not to deal with possible collisions.
  90. # [22:21] * trackbot noticed an ACTION. Trying to create it.
  91. # [22:21] * RRSAgent records action 2
  92. # [22:21] <trackbot> Created ACTION-65 - Dahlstrohm (with Patrick Dengler) to send an email to the CSS WG asking for feedback on proposed list of additional properties to be added when promoting SVG attributes to properties. Ask if properties should be prefixed or not to deal with possible collisions. [on Erik Dahlström - due 2012-01-30].
  93. # [22:22] <smfr> vhardy: don't forget to minute yourself!
  94. # [22:22] <vhardy> vhardy: how would we publish this new behavior for SVG presentation attributes? Will that be a stand-alone addendum to SVG 1.1 2nd edition, or will it be a 3rd edition of SVG 1.1
  95. # [22:22] <vhardy> dino: it sounds it should be a separate spec. if we want to have it alive in a reasonnable amount of time.
  96. # [22:23] <dino> s/vhardy: don/vhardy, don/
  97. # [22:23] * shepazu is adding Patrick to the FX TF… any other people from SVG or CSS WGs I should add?
  98. # [22:23] <vhardy> vhardy: if a separate spec., that would be an addendum to SVG 1.1, right?
  99. # [22:23] * vhardy may be Dirk?
  100. # [22:23] * dino shepazu dirk schulze
  101. # [22:23] <vhardy> ed: yes, this is adding properties for SVG 1.1, so the best would be to do an addendum to the SVG 1.1 spec. It should also be folded in SVG 2. It depends on what people feel is appropriate.
  102. # [22:25] <smfr> who's ichatting?
  103. # [22:25] <vhardy> heycam: normally, separate specs. add to the functionality instead of changing behavior, like here. I agree with Erik that it should be folded in SVG 2 anyway.
  104. # [22:25] <vhardy> ... I do not have a problem leaving it initially in a separate spec.
  105. # [22:25] * shepazu added Patrick and Dirk
  106. # [22:26] <vhardy> vhardy: sounds good to me too: have a separate spec. for 1.1 and fold into SVG 2.
  107. # [22:27] <vhardy> ACTION: Patrick to create an initial editor draft of the document that can be pointed to and discussed with the CSS WG.
  108. # [22:27] * RRSAgent records action 3
  109. # [22:27] * trackbot noticed an ACTION. Trying to create it.
  110. # [22:27] <trackbot> Sorry, couldn't find user - Patrick
  111. # [22:27] <dino> trackbot, reload
  112. # [22:27] <vhardy> ACTION: Patrick to create an initial editor draft of the document that can be pointed to and discussed with the CSS WG.
  113. # [22:27] * trackbot noticed an ACTION. Trying to create it.
  114. # [22:27] * RRSAgent records action 4
  115. # [22:27] <trackbot> Sorry, couldn't find user - Patrick
  116. # [22:27] * dino piece of shit
  117. # [22:27] * heycam afk a bit
  118. # [22:27] <vhardy> ACTION: Erik to create an initial editor draft of the SVG with CSS Animations/Transitions document that can be pointed to and discussed with the CSS WG.
  119. # [22:28] * trackbot noticed an ACTION. Trying to create it.
  120. # [22:28] * RRSAgent records action 5
  121. # [22:28] <trackbot> Created ACTION-66 - Create an initial editor draft of the SVG with CSS Animations/Transitions document that can be pointed to and discussed with the CSS WG. [on Erik Dahlström - due 2012-01-30].
  122. # [22:28] * heycam returns
  123. # [22:28] <vhardy> ed: any other feedback on the proposal?
  124. # [22:28] <vhardy> (silence)
  125. # [22:28] <vhardy> Topic: CSS Transforms specification.
  126. # [22:28] <dino> ScribeNick: dino
  127. # [22:29] <dino> vhardy: DirkS has joined Adobe and will be focusing on the merged transforms specification. He's captured the issues in bugzilla. He's started on a wiki page with the difficulties of the merge
  128. # [22:30] <dino> vhardy: it would be better if he was an editor. I suggest we add Dirk as an editor.
  129. # [22:30] <dino> dino: I support this.
  130. # [22:30] <dino> smfr: me too
  131. # [22:30] <dino> ed: me too
  132. # [22:30] <dino> RESOLVED: Dirk becomes an editor of the SVG+CSS Transforms specification
  133. # [22:31] <dino> RESOLVED: Vincent also is an editor of the SVG+CSS Transforms specification
  134. # [22:31] <dino> vhardy: Dirk will bring some of the CSS OM issues to a telcon. After that he'll bring up the parsing issues (units, etc).
  135. # [22:32] <dino> vhardy: do we think that should come here first? or go straight to CSS WG?
  136. # [22:32] <dino> vhardy: risk is that people won't be at an FX call
  137. # [22:33] <dino> dino: I think we should go straight to CSS
  138. # [22:33] <dino> vhardy: ok
  139. # [22:34] <dino> vhardy: I notice that the CSS 2D transform spec is now pointing at the merged spec. The CSS 3D spec hasn't. Should we do it?
  140. # [22:34] <dino> dino: I think so.
  141. # [22:34] <dino> (I didn't minute that because I think we just repeated the question)
  142. # [22:35] <dino> smfr: I think there are some outstanding edits that need to be included in the spec.
  143. # [22:35] <dino> smfr: I'm not sure if we want to update the 3d spec and publish, THEN move it to the combined spec.
  144. # [22:36] <dino> vhardy: when was the last major update to transforms?
  145. # [22:36] <dino> dino: Sept 11 I believe
  146. # [22:36] <dino> vhardy: in which case the merged spec has all the updates to 2d
  147. # [22:36] <dino> vhardy: our resolution at the TPAC was to publish 3d, noting that it is now replaced by the merge spec
  148. # [22:37] <dino> ACTION: Vincent to edit the CSS 3D spec to point to the merged spec
  149. # [22:37] * trackbot noticed an ACTION. Trying to create it.
  150. # [22:37] * RRSAgent records action 6
  151. # [22:37] <trackbot> Created ACTION-67 - Edit the CSS 3D spec to point to the merged spec [on Vincent Hardy - due 2012-01-30].
  152. # [22:37] <dino> smfr: so no changes other than the notification that this spec is now elsewhere?
  153. # [22:37] <dino> vhardy: correct
  154. # [22:38] <vhardy> ScribeNick: vhardy
  155. # [22:38] <vhardy> ed: there was more discussion on drop-shadow on the list.
  156. # [22:38] <ed> http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0027.html
  157. # [22:38] <vhardy> dino: Apple's position is that drop-shadow would be better as a separate property. We are talking about the shorthand functions. There would still be a way to do a drop shadow with an SVG filter.
  158. # [22:39] <ed> topic: drop-shadow filter vs. a separate property
  159. # [22:39] <vhardy> smfr: the CSS wg has talked about it multiple times in the past. It got some pushback because there were people who wanted to apply the drop shadow to some parts (e.g., just background or just border). I am not arguing against or for it, just relating what discussions happened in the past.
  160. # [22:40] <vhardy> ed: I am not sure I understand the advantage to keep it as a separate property. May be because it is somewhat easy to implement.
  161. # [22:41] <vhardy> dino: performance. It is a fairly complex filter. And, when it comes down to it, people will not put a drop shadow in the middle of their filter operation. They will likely apply a drop shadow and then filter the result.
  162. # [22:41] <vhardy> heycam: you still have to support the feDropShadow, so you'll have to worry about having it in the middle of the filter chain.
  163. # [22:41] <vhardy> dino: yes, but the shorthand will be easier and faster to implement.
  164. # [22:42] <vhardy> ... arbitrary filter chains could be very complex anyway. Authors will have to be aware of the complexity and that they might possibly be slow.
  165. # [22:42] <vhardy> heycam: it does not seem that it would be that hard to detect the position of the drop-shadow in the chain and optimize if in last/first position.
  166. # [22:42] <vhardy> dino: it is going to be slow in the filter chain.
  167. # [22:43] <vhardy> smfr: on the Mac we are relying on system framework for the shorthand filters which is faster than going through the whole filter chain. The method is super fast, they apply to everything. If we have to fall out of that to the filter chain, the performance impact is huge. There will be a lot of read-back from the GPU which is innefficient.
  168. # [22:44] <vhardy> ... drop-shadow does not fit nicely in our implementation constraints. In the way people use it, it makes sense to make it a separate property.
  169. # [22:44] <vhardy> ... people do not use it like a regular filer.
  170. # [22:44] <vhardy> s/filer/filter
  171. # [22:45] <vhardy> dino: it would be interesting to see why people would use the drop shadow in a filter chain and why having it as a separate property would not work fine.
  172. # [22:45] <vhardy> smfr: we may get push back from the CSS working group like there was in the past. We can try again.
  173. # [22:45] <vhardy> ... there is text-shadow. May be this could extend text-shadow.
  174. # [22:47] <dino> vhardy: you probably want it to knock-out the content too
  175. # [22:47] <dino> vhardy: so you don't see through translucent pixels
  176. # [22:47] <vhardy> smfr: I think you may want to have both behaviors.
  177. # [22:47] <vhardy> dino: I think this is such a common request (drop-shadow) that it makes sense to make is a separate property.
  178. # [22:48] <vhardy> vhardy: why not optimize when detecting filter: drop-shadow(....)?
  179. # [22:48] <vhardy> smfr: we can do that. The tricky thing is that when we fall off the fast past, it is difficult to have a filter correctly applied to children elements like video or WebGL.
  180. # [22:49] <vhardy> s/past/path
  181. # [22:49] <vhardy> dino: it would be good to know where people are with the implementation of this spec.
  182. # [22:49] <vhardy> ... the implementation is tricky when the content of the page is more complex.
  183. # [22:49] <vhardy> ed: I don't see how it is much harder to do it with the filter shorthand. I guess we can wait and see.
  184. # [22:50] <vhardy> heycam: it seems that you want to avoid any value on the shorthand property to go to the slow path.
  185. # [22:50] <vhardy> smfr: yes.
  186. # [22:50] <vhardy> dino: we can never guarantee that things will be fast, but we are trying to design this so that we can be fast in as many situations as possible. Right now, it is slow in too many cases. We are just talking about the shorthands.
  187. # [22:51] <vhardy> heycam: do you plan to make the markup filters fast in the future?
  188. # [22:51] <vhardy> dino: yes, we want to make everything fast. The issue of performance becomes complicated depending on the hw config.
  189. # [22:51] <vhardy> ... mobile, powerful hw...
  190. # [22:52] <vhardy> smfr: with markup filters, people can write their own custom filters. With the shorthand properties, we can do a lot of optimization. It is difficult with markup filters.
  191. # [22:52] <vhardy> dino: for the short term, custom filters may be faster than markup filters, even if our goal is to make everything fast.
  192. # [22:53] <vhardy> ed: it does not seem there is total agreement on what to do (keeping a separate property or not). I guess we can keep discussing it on the list.
  193. # [22:53] <vhardy> smfr: does anyone object to having a separate property.
  194. # [22:53] <vhardy> heycam: I do not object. It feels we are making decisions on current implementation performance.
  195. # [22:54] <vhardy> dino: that is true, but we could always add it back in.
  196. # [22:54] <vhardy> ... part of the spec. work is to get implementation feedback.
  197. # [22:54] <vhardy> .. this is the first release of the technology, we do not have to address everything upfront.
  198. # [22:55] <vhardy> vhardy: could we have both the drop-shadow property and the filter shorthand as well?
  199. # [22:55] <vhardy> dino: I would prefer to have the property. If it is a property, I do no see the use cases for having it in the middle of shorthand filters.
  200. # [22:56] <vhardy> ed: do you have any pointers for prior discussions on this.
  201. # [22:57] <smfr> http://lists.w3.org/Archives/Public/www-style/2009Sep/0131.html
  202. # [22:57] <vhardy> dino: We had previous discussions in the Seattle meeting. We were pointing these problems out and reluctantly agreed to adding drop-shadow filter shorthand
  203. # [22:57] * Zakim vhardy, you typed too many words without commas; I suspect you forgot to start with 'to ...'
  204. # [22:57] <ed> s/discussions on this./discussions on the css mailinglist(s) about this topic?/
  205. # [22:58] <vhardy> smfr: the discussion is about drop-shadow interacts with border-image in CSS.
  206. # [22:59] <vhardy> ed: we should ask the CSS wg about splitting the drop-shadow filter in a separate property to get their feedback on that. I personally think it would be interesting to mix the drop-shadow in the middle of a chain.
  207. # [23:00] <vhardy> .. but if there are performance issues with doing that, then having a separate property may be the best way to deal with it.
  208. # [23:00] <vhardy> .. I don't want it to be difficult or to become a problem. I think having a filter keyword should still be an option.
  209. # [23:01] <vhardy> ... I think it is possible to keep it both ways. It depends on what other people think.
  210. # [23:02] <vhardy> vhardy: I think that if there are use cases where having the drop shadow in the middle of a filter chain is useful, I think we should keep it. Otherwise, I'd be ok keeping it.
  211. # [23:02] <vhardy> ACTION: Dean to ask the CSS working group if we could add a drop-shadow property to CSS.
  212. # [23:02] * trackbot noticed an ACTION. Trying to create it.
  213. # [23:02] * RRSAgent records action 7
  214. # [23:02] <trackbot> Created ACTION-68 - Ask the CSS working group if we could add a drop-shadow property to CSS. [on Dean Jackson - due 2012-01-30].
  215. # [23:03] <vhardy> ed: we are almost out of time. Anything else?
  216. # [23:03] <vhardy> (silence).
  217. # [23:03] <vhardy> ed: adjouned.
  218. # [23:03] <vhardy> s/adjouned/adjourned
  219. # [23:04] <ed> trackbot, end telcon
  220. # [23:04] * trackbot is ending a teleconference
  221. # [23:04] <trackbot> Zakim, list attendees
  222. # [23:04] <Zakim> sorry, trackbot, I don't know what conference this is
  223. # [23:04] <trackbot> RRSAgent, please draft minutes
  224. # [23:04] <RRSAgent> I have made the request to generate http://www.w3.org/2012/01/23-fx-minutes.html trackbot
  225. # [23:04] <trackbot> RRSAgent, bye
  226. # [23:04] <RRSAgent> I see 7 open action items saved in http://www.w3.org/2012/01/23-fx-actions.rdf :
  227. # [23:04] <RRSAgent> ACTION: Patrick Dengler to send an email to the CSS WG asking for feedback on proposed list of additional properties to be added when promoting SVG attributes to properties. Ask if properties should be prefixed or not to deal with possible collisions. [1]
  228. # [23:04] <RRSAgent> recorded in http://www.w3.org/2012/01/23-fx-irc#T21-13-22
  229. # [23:04] <RRSAgent> ACTION: Erik Dahlstrohm (with Patrick Dengler) to send an email to the CSS WG asking for feedback on proposed list of additional properties to be added when promoting SVG attributes to properties. Ask if properties should be prefixed or not to deal with possible collisions. [2]
  230. # [23:04] <RRSAgent> recorded in http://www.w3.org/2012/01/23-fx-irc#T21-13-53
  231. # [23:04] <RRSAgent> ACTION: Patrick to create an initial editor draft of the document that can be pointed to and discussed with the CSS WG. [3]
  232. # [23:04] <RRSAgent> recorded in http://www.w3.org/2012/01/23-fx-irc#T21-19-51
  233. # [23:05] <RRSAgent> ACTION: Patrick to create an initial editor draft of the document that can be pointed to and discussed with the CSS WG. [4]
  234. # [23:05] <RRSAgent> recorded in http://www.w3.org/2012/01/23-fx-irc#T21-20-25
  235. # [23:05] <RRSAgent> ACTION: Erik to create an initial editor draft of the SVG with CSS Animations/Transitions document that can be pointed to and discussed with the CSS WG. [5]
  236. # [23:05] <RRSAgent> recorded in http://www.w3.org/2012/01/23-fx-irc#T21-20-49
  237. # [23:05] <RRSAgent> ACTION: Vincent to edit the CSS 3D spec to point to the merged spec [6]
  238. # [23:05] <RRSAgent> recorded in http://www.w3.org/2012/01/23-fx-irc#T21-30-03
  239. # [23:05] <RRSAgent> ACTION: Dean to ask the CSS working group if we could add a drop-shadow property to CSS. [7]
  240. # [23:05] <RRSAgent> recorded in http://www.w3.org/2012/01/23-fx-irc#T21-55-29
  241. # [23:05] * Parts: RRSAgent (rrs-loggee@128.30.52.169)
  242. # [23:05] * Parts: dino (dino@121.45.218.218)
  243. # [23:12] <ed> chair: ed
  244. # [23:13] <ed> ah, too late
  245. # [23:15] * Quits: smfr (smfr@17.212.152.232) (Quit: smfr)
  246. # [23:27] * heycam is now known as heycam|away
  247. # [23:58] * heycam|away is now known as heycam
  248. # Session Close: Tue Jan 24 00:00:00 2012

The end :)