/irc-logs / w3c / #webapps / 2013-08-21 / end

Options:

  1. # Session Start: Wed Aug 21 00:00:00 2013
  2. # Session Ident: #webapps
  3. # [00:03] * Joins: divya (~Adium@public.cloak)
  4. # [00:39] * Joins: jeffh (~d871a880@public.cloak)
  5. # [00:51] * Quits: divya (~Adium@public.cloak) ("Leaving.")
  6. # [00:51] * Quits: Rob (~Rob@public.cloak) (Rob)
  7. # [00:52] * Quits: sicking (~sicking@public.cloak) (sicking)
  8. # [00:59] * Joins: glenn (~gadams@public.cloak)
  9. # [01:22] * heycam|away is now known as heycam
  10. # [01:34] * Joins: sicking (~sicking@public.cloak)
  11. # [01:34] * Quits: sicking (~sicking@public.cloak) (sicking)
  12. # [01:41] * Quits: smaug (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
  13. # [01:48] * Joins: masayuki (~masayuki@public.cloak)
  14. # [01:52] * Joins: skddc (~anonymous@public.cloak)
  15. # [01:53] * Joins: skddc_ (~anonymous@public.cloak)
  16. # [01:56] * Joins: Travis (~Travis@public.cloak)
  17. # [01:57] * Joins: Zakim (zakim@public.cloak)
  18. # [01:57] * Joins: RRSAgent (rrsagent@public.cloak)
  19. # [01:57] <RRSAgent> logging to http://www.w3.org/2013/08/21-webapps-irc
  20. # [01:57] <Travis> Zakim, this is DOM3
  21. # [01:57] <Zakim> ok, Travis; that matches RWC_WAPI(D3E)8:00PM
  22. # [01:57] * Joins: kochi_home (~kochi_home@public.cloak)
  23. # [01:58] <kochi_home> hello
  24. # [01:58] * Joins: garykac (~garykac@public.cloak)
  25. # [01:58] <Travis> Hi!
  26. # [01:58] <kochi_home> calling in soon.
  27. # [01:58] <masayuki> Hello!
  28. # [01:58] <garykac> Hallo
  29. # [01:59] * Quits: skddc (~anonymous@public.cloak) (Ping timeout: 180 seconds)
  30. # [01:59] * skddc_ is now known as skddc
  31. # [01:59] <Zakim> + +1.425.893.aaaa
  32. # [01:59] <Zakim> - +1.425.893.aaaa
  33. # [01:59] <Zakim> + +1.425.893.aaaa
  34. # [01:59] <Travis> RRSAgent, this meeting spans midnight
  35. # [01:59] <RRSAgent> ok, Travis; I will not start a new log at midnight
  36. # [01:59] <Travis> zakim, +1.425 is garykac
  37. # [01:59] <Zakim> +garykac; got it
  38. # [02:00] <Travis> Present+ Travis_Leithead
  39. # [02:00] <Zakim> +[IPcaller]
  40. # [02:00] <Travis> Present+ Gary_K
  41. # [02:00] <Travis> zakim, ipcaller is kochi_home
  42. # [02:00] <Zakim> +kochi_home; got it
  43. # [02:01] <Travis> Present+ Jianfeng_Lin
  44. # [02:02] <Travis> https://docs.google.com/document/d/1pGo9hmOXCu71lnpXbqpTQNQP70DU9E-1tNN3yEWg5ig/edit?usp=sharing
  45. # [02:03] <garykac> Item 1: Order of beforeinput and compositionupdate events
  46. # [02:04] <garykac> Discussed in the doc, but there was a previous discussion that I missed where the opposite order was proposed.
  47. # [02:05] <masayuki> Is beforeinput fired during composition?
  48. # [02:06] <Travis> First issue: it's not always possible to cancel the IME with initial keydown (we don't think we can require that). We want to have it be a "best effort".
  49. # [02:07] <Travis> Traditionally, keydown is the appropriate cancellation point.
  50. # [02:07] * Quits: karl (~karlcow@public.cloak) (":tiuQ tiuq sah woclrak")
  51. # [02:07] <Travis> Do we have concensus on this point?
  52. # [02:09] <masayuki> Firefox will be cancellable with keydown.preventDefault() on Windows and Linux. (on Mac, it's been so already)
  53. # [02:09] <garykac> Is if guaranteed that we can always cancel the IME by canceling keydown?
  54. # [02:09] <Travis> We can test with a wide variety of IME's, but some may not support it.
  55. # [02:10] <garykac> I was under the impression that it was not *always* possible.
  56. # [02:10] <masayuki> If keydown is fired *before* it's passed through IME, it's possible.
  57. # [02:11] <masayuki> But I don't know it's possible on mobile platforms.
  58. # [02:11] <Travis> Item 2: should keydown/up be fired during composition?
  59. # [02:11] <kochi_home> yeah, on Android basically all on-screen keyboards are IME
  60. # [02:12] * Quits: sgalineau (~sgalineau@public.cloak) (Client closed connection)
  61. # [02:13] <garykac> Item 2: should we send keydown/keyup events during composition
  62. # [02:13] <masayuki> Idealy: shouldn't fire keydown/keyup during composition because some IMEs, e.g., hand writing system, never cause key events. So, handling keydown/keyup makes problem on some environment.
  63. # [02:13] <masayuki> Historically, should be fired for not breaking the web.
  64. # [02:14] <garykac> Masayuki: Just because handwriting systems don't send key events, doesn't mean that keyboards should send key events.
  65. # [02:14] <garykac> compositon events are not *required* to have key events
  66. # [02:14] <Travis> Consider the example of a simple-minded search box where the Enter keyup means "search". If during composition, the user presses the enter key to confirm a partial composition, the naive enter key handling could trigger a search (at the wrong time)
  67. # [02:15] <garykac> but if they are coming from a keyboard, it's not unreasonable to include them
  68. # [02:15] <Travis> Firefox does not fire them during composition. So is there really a risk of breaking the web?
  69. # [02:15] <masayuki> garykac: I undersand it, but not all web application developers don't understand so, I guess.
  70. # [02:16] <masayuki> Travis: We have some reports of such web sites.
  71. # [02:17] <garykac> One downside of removing them, is that the initial keyup and the last keydown tend to get lost (since they occur during "composition").
  72. # [02:17] <garykac> I would be happier if every keydown had a matching keyup event.
  73. # [02:17] <garykac> masayuki: Some websites have complained about the lack of keydown/keyup events?
  74. # [02:18] <garykac> Was it a lot of sites?
  75. # [02:18] <masayuki> garykac: No so many. But I don't know the actual number.
  76. # [02:19] <masayuki> garykac: But they should use compositionupdate or input event.
  77. # [02:20] <masayuki> Anyway, such web sites are not available from handwriting system.
  78. # [02:21] <garykac> I don't think I'm concerned too much about the broken sites, because (as you say) they have accessibility issues (speech, handwriting) anyway
  79. # [02:21] <Travis> If use finishes a composition and there would be a keyup without keydown, maybe we can simply just _not_ send the keyup after composition.
  80. # [02:23] <masayuki> Travis: It's difficult because native keyup event is an independent event. So, it's difficult to know which keyup was pressed during composition.
  81. # [02:23] <Travis> In general, we're concerned about having dangling keyup or keydown events in the flow involving composition events. There may be some ways to ratinonalize this bug swallowing or artificially emitting certain pairs.
  82. # [02:23] <garykac> So, is there general agreeement that suppressing keyup/down during composition is a good idea? I don't feel strongly about it (other than the matching key down/up events)
  83. # [02:24] <Travis> I think that the browser could figure that out based on state of composition.
  84. # [02:24] <kochi_home> what about event for key presses that is not consumed by IME?
  85. # [02:24] <Travis> Example?
  86. # [02:24] <garykac> But Chrome and IE are currently sending the key events during composition, so the events are available (for common IMEs at least)
  87. # [02:24] <kochi_home> hmm, most keys are consumed, but maybe PageUp etc?
  88. # [02:25] <Travis> (Yes, and in IE's case it has caused problems with naive JS developers not realizing that they need to do filtering for languages that use IMEs.)
  89. # [02:25] <masayuki> kochi_home: keypress event isn't fired for non-printable keys except Firefox
  90. # [02:26] <Travis> Ditto.
  91. # [02:26] <kochi_home> masayuki: what about keyup/down
  92. # [02:26] <kochi_home> ?
  93. # [02:26] <kochi_home> so, during IME composition, some non-IME key may generate keydown/up events?
  94. # [02:27] <garykac> So, if the IME doesn't consume the key, it would pass it on?
  95. # [02:28] <Travis> I'm not sure that an IME can "consume" the key completely.
  96. # [02:28] <masayuki> kochi_home: Chrome does so. IE is complicated...
  97. # [02:30] <Travis> Proposal then for Item 2 is to supress keydown/up events during composition and try to ensure beginning/ending keydown/up have appropriate pairings (or drop them).
  98. # [02:32] <Travis> Item 3: if we don't adopt item 2 proposal, than some keydown/up pair during composition are not (in fact) cancellable. This problem goes away with the item 2 proposal.
  99. # [02:32] <Travis> Item 4: Recommend beforeinput instead of keypress.
  100. # [02:32] <Travis> We are all in agreement on this, I think.
  101. # [02:33] * Quits: jeffh (~d871a880@public.cloak) ("http://www.mibbit.com ajax IRC Client")
  102. # [02:33] <masayuki> Yes, but for it, beforeinput should be fired on non-editable element.
  103. # [02:33] <garykac> What Event shoudl beforeinput and input be associated with.
  104. # [02:34] <garykac> We had assumed that input would send an Event
  105. # [02:34] <Travis> Item 5: What event type should beforeinput be? It needs to have some useful content in the event itself.
  106. # [02:34] <garykac> But beforeinput needs to send more info than that
  107. # [02:34] <masayuki> And beforeinput should have all information which is included keypress event.
  108. # [02:35] <garykac> So, let's go with having a new event type: InputEvent
  109. # [02:35] <Travis> Sounds good to me.
  110. # [02:36] <garykac> That way we can add the fields we need to it.
  111. # [02:36] <masayuki> agree.
  112. # [02:37] <masayuki> I think we don't discuss about beforeinput at non-printable key combination, such as Ctrl+C.
  113. # [02:37] <masayuki> I think that on such case, beforeinput should be also fired.
  114. # [02:38] <Travis> Item 6: When does beforeinput fire in relation to composition update?
  115. # [02:38] <garykac> Do we want beforeinput + updateDOM + compositionupdate + input
  116. # [02:38] <garykac> or compositionupdate + beforeinput + updateDOM + input
  117. # [02:38] <Travis> 'input' doesn't fire very consistently either during a composition, right?
  118. # [02:39] <masayuki> IIRC, at the previous discussion, don't we agree with no dispatching beforeinput during compsoition?
  119. # [02:39] <garykac> Effectively, this comes down to whether or not the DOM should be updated before compositionupate
  120. # [02:39] <masayuki> I misunderstood?
  121. # [02:40] <garykac> masayuki: Ojan mentioned a use case where beforeinput was always needed before the DOM was updated (by anyone, including composition)
  122. # [02:40] <masayuki> garykac: Okay.
  123. # [02:40] <garykac> The example was a app that needed to record state (like the cursor position) before any change so that the Undo chain stayed consistent.
  124. # [02:41] <Travis> Seems like we all agree.
  125. # [02:41] <garykac> It would be nice to remove the beforeinput, but I think that we need to keep it around since we need one place to hook to catch all pre-DOM-updates
  126. # [02:41] <masayuki> Okay.
  127. # [02:42] * Quits: jsbell (~jsbell@public.cloak) ("There's no place like home...")
  128. # [02:43] <masayuki> At previous discussion, we agreed with that compositionupdate should be cancellable. So, compositionupdate should be fired before updating DOM.
  129. # [02:44] <kochi_home> yeah, if IE can follow the behavior.
  130. # [02:46] <kochi_home> so cancelling composition update just cancels updating the DOM?
  131. # [02:46] <masayuki> FYI: Even if browsers cancel DOM update, they need to assume that there is the latest composition string because some IME expect so. (E.g., TSF's IME)
  132. # [02:46] <Travis> So, I think we want an order of beforeinput + compositionupdate + DOM update + input
  133. # [02:46] <garykac> Next question: preference for beforeinput + compositionupdate + DOM + input vs. compositionupdate + beforeinput + DOM + input
  134. # [02:47] <garykac> either way sounds good to me
  135. # [02:47] <Travis> I prefer the former.
  136. # [02:47] <masayuki> kochi_home: AFAIK, there is no platform which can cancel compositionupdate actually.
  137. # [02:47] <garykac> I'll go with Travis' suggestion
  138. # [02:48] <Travis> So, we need to note that beforeinput events during a composition sequence may not (and probably will not) work to cancel the DOM update.
  139. # [02:48] <garykac> masayuki: Yes, we'll need to make sure the spec says that canceling isn't likely to work. Perhaps phrased as browsers should make a "best effort"
  140. # [02:48] <kochi_home> masayuki: okay, cancelling compositionupdate is not so useful or confusing (to the system) anyway.
  141. # [02:49] * heycam is now known as heycam|away
  142. # [02:49] <Travis> Item 7: Which elements do fire the beforeinput/input events ?
  143. # [02:49] <masayuki> How about compositionend vs. beforeinput? Which is important for the consistency event order.
  144. # [02:50] <garykac> masayuki: I don't think the order matters. Can you think of a case where it does matter?
  145. # [02:50] <masayuki> garykac: Simpler order is easy to understand :-)
  146. # [02:52] <masayuki> Travis: I think it should be fired on all elements because keypress behaves so.
  147. # [02:52] <masayuki> I meant beforeinput, not input.
  148. # [02:53] <masayuki> input event is fired from internal editor. So, input cannot be fired from non-editable element.
  149. # [02:54] <garykac> masayuki: If you add the "inputmode" flag to an element, then it will receive beforeinput and input events
  150. # [02:55] <garykac> masayuki: by default, they're only sent to contenteditable, but other elements can request them
  151. # [02:55] <masayuki> garykac: Sounds strange to me...
  152. # [02:56] <Travis> I'm on board with not firing beforeinput (and input) on non-editable elements. Users can add inputmode (or make them editable if they want to see beforeinput/input).
  153. # [02:56] <masayuki> garykac: And such behavior makes browser implementation complicated, I think.
  154. # [02:57] <garykac> In general, we shouldn't be sending events to every single element type (as was done in the past).
  155. # [02:59] <garykac> And it sounds like we have a mechanism ("inputmode") where elements can request to receive these events.
  156. # [02:59] <masayuki> beforeinput is an event which notifies native key or IME input. So, I believe that such event must be fired on any focused element.
  157. # [03:00] <kochi_home> yeah, if element has inputmode and is focused.
  158. # [03:00] <garykac> So someone who is catching keypress on the <body> can add inputmode to receive these events, otherwise they won't.
  159. # [03:00] <garykac> (sorry, bad edit, let me re-phrase)
  160. # [03:00] <masayuki> Hmm, if we take such behavior, keypress isn't more useful for web developers?
  161. # [03:01] <masayuki> keypress doesn't need inputmode setting which is additional work.
  162. # [03:01] <garykac> So someone who is currently catching keypress on the <body> can update their code to the spec by adding inputmode to receive these events
  163. # [03:01] <garykac> Switching to use beforeinput is already work that we're expecting people to do.
  164. # [03:02] <garykac> Browsers will support keypress as long as websites still do these horrible things.
  165. # [03:02] <masayuki> I don't feel it's reasonable. They need to set inputmode and add listener. Why do they need two setps for listening an event?
  166. # [03:03] <Travis> Because with beforeinput, they're only interested in getting the events that really do generate input.
  167. # [03:03] <garykac> But the switch to use beforeinput and adding "inputmode" on the element where they attach the listener is not unreasonable.
  168. # [03:03] <Travis> keypress did not come with that guarantee.
  169. # [03:03] <Travis> We're saying the keydown/up are the natural replacement for keypress -- in this scenario only.
  170. # [03:04] <masayuki> So, before input isn't fired for non-text-input? Like Ctrl+C?
  171. # [03:04] <Travis> (The scenario of watching for all key action on the keyboard on the body)
  172. # [03:04] <garykac> beforeinput should fire anytime the DOM is about to be updated - regardless of what is making the change
  173. # [03:05] <Travis> I don't think input is fired for a Ctrl+C either...
  174. # [03:05] <Travis> Ctrl+V should fire beforeinput
  175. # [03:05] <Travis> Undo/Paste should do it too.
  176. # [03:05] <masayuki> Travis: I don't think so, Ctrl+V shouldn't cause beforeinput if it's not fired by all key combinations.
  177. # [03:06] <masayuki> Travis: because it's difficult to know whether an edit command is kicked by key event or not.
  178. # [03:06] <Travis> Correct: if a keyboard mapping has the "paste" action using a different key pair, then it won't fire beforeinput.
  179. # [03:06] <garykac> Ctrl-V by itself won't fire the event, but if the effect of ctrl-v is to cause a Paste, then the beforeinput/input events will fire.
  180. # [03:07] <masayuki> Hmm, I don't think that before input shouldn't be fired for edit command.
  181. # [03:08] <masayuki> Because it's cancelable, so, it's necessary to be fired synchronously.
  182. # [03:08] <Travis> It sounds like we may still have some disagreement on when beforeinput will fire in relation to editing, but let's table that for now.
  183. # [03:08] <masayuki> It means it may cause event loop by attacker.
  184. # [03:08] <Travis> Next call: September 3rd, 2013
  185. # [03:09] <masayuki> Travis: no problem for me.
  186. # [03:09] <Travis> Masayuki, can you send your feedback to the mailing list so that we can continue this conversation?
  187. # [03:10] <masayuki> Travis: Okay.
  188. # [03:10] <Travis> Alright. Time's up!
  189. # [03:10] <Travis> Thanks everyone for the discussion we made great headway.
  190. # [03:10] <masayuki> Thank you.
  191. # [03:10] <garykac> I'm going to update the doc/spec with the stuff we agreed on + some of proposals that we mostly have agreement on. That way we can discuss the details in context.
  192. # [03:10] <kochi_home> Thanks!
  193. # [03:10] <garykac> Thank you.
  194. # [03:10] <Zakim> -[Microsoft]
  195. # [03:10] <Zakim> -garykac
  196. # [03:10] <Zakim> -kochi_home
  197. # [03:10] <Zakim> RWC_WAPI(D3E)8:00PM has ended
  198. # [03:10] <Zakim> Attendees were [Microsoft], +1.425.893.aaaa, garykac, kochi_home
  199. # [03:11] <Travis> Zakim, 425.89 is Travis
  200. # [03:11] <Zakim> sorry, Travis, I do not recognize a party named '425.89'
  201. # [03:12] <Travis> Zakim, +1.425.89 is Travis
  202. # [03:12] <Zakim> sorry, Travis, I do not recognize a party named '+1.425.89'
  203. # [03:12] * Travis I guess now that I'm off the call you can't find me :(
  204. # [03:12] <Travis> rrsagent, please make the minutes
  205. # [03:12] <RRSAgent> I have made the request to generate http://www.w3.org/2013/08/21-webapps-minutes.html Travis
  206. # [03:13] <Travis> rrsagent, make logs public
  207. # [03:13] <RRSAgent> I have made the request, Travis
  208. # [03:15] * Quits: masayuki (~masayuki@public.cloak) ("Page closed")
  209. # [03:16] * Quits: Travis (~Travis@public.cloak) ("Page closed")
  210. # [03:16] * Quits: kochi_home (~kochi_home@public.cloak) (Client closed connection)
  211. # [03:17] * Joins: kochi_home (~kochi_home@public.cloak)
  212. # [03:17] * Quits: garykac (~garykac@public.cloak) (Ping timeout: 180 seconds)
  213. # [03:24] * Joins: kochi_ho_ (~kochi_home@public.cloak)
  214. # [03:24] * Parts: kochi_ho_ (~kochi_home@public.cloak) (Leaving...)
  215. # [03:24] * Quits: kochi_home (~kochi_home@public.cloak) (Ping timeout: 180 seconds)
  216. # [03:24] * Joins: kochi_home (~kochi_home@public.cloak)
  217. # [03:31] * Quits: kochi_home (~kochi_home@public.cloak) (Ping timeout: 180 seconds)
  218. # [03:57] * Joins: karl (~karlcow@public.cloak)
  219. # [03:57] * Joins: Rob (~Rob@public.cloak)
  220. # [04:35] * Joins: kochi_home (~kochi_home@public.cloak)
  221. # [04:42] * Quits: kochi_home (~kochi_home@public.cloak) (Ping timeout: 180 seconds)
  222. # [04:47] * Joins: jeffh (~18047aad@public.cloak)
  223. # [04:54] * Quits: Rob (~Rob@public.cloak) (Rob)
  224. # [05:10] * Joins: kochi_home (~kochi_home@public.cloak)
  225. # [05:12] * Joins: kochi_ho_ (~kochi_home@public.cloak)
  226. # [05:12] * Quits: kochi_home (~kochi_home@public.cloak) (Client closed connection)
  227. # [05:24] * Quits: kochi_ho_ (~kochi_home@public.cloak) (Client closed connection)
  228. # [05:25] * Joins: kochi_home (~kochi_home@public.cloak)
  229. # [05:30] * Quits: skddc (~anonymous@public.cloak) (Ping timeout: 180 seconds)
  230. # [05:31] * heycam|away is now known as heycam
  231. # [05:32] * Quits: kochi_home (~kochi_home@public.cloak) (Ping timeout: 180 seconds)
  232. # [06:01] * Joins: kochi_home (~kochi_home@public.cloak)
  233. # [06:08] * Joins: Rob (~Rob@public.cloak)
  234. # [06:16] * Quits: kochi_home (~kochi_home@public.cloak) ("Leaving...")
  235. # [06:34] * Quits: Rob (~Rob@public.cloak) (Rob)
  236. # [06:37] * Quits: karl (~karlcow@public.cloak) (Client closed connection)
  237. # [07:56] * Joins: tobie (tobie@public.cloak)
  238. # [07:58] * Quits: tobie (tobie@public.cloak)
  239. # [08:36] * Quits: jeffh (~18047aad@public.cloak) ("http://www.mibbit.com ajax IRC Client")
  240. # [10:15] * Joins: yoichio (~yoichio@public.cloak)
  241. # [10:23] * Joins: tobie (tobie@public.cloak)
  242. # [10:51] * heycam is now known as heycam|away
  243. # [11:00] * Joins: Lachy (~Lachy@public.cloak)
  244. # [11:04] * Joins: smaug (~chatzilla@public.cloak)
  245. # [11:35] * Joins: skddc (~anonymous@public.cloak)
  246. # [11:52] * Quits: skddc (~anonymous@public.cloak) (skddc)
  247. # [11:52] * Joins: skddc (~anonymous@public.cloak)
  248. # [12:28] * Quits: Lachy (~Lachy@public.cloak) ("Computer has gone to sleep.")
  249. # [12:29] * Joins: karl (~karlcow@public.cloak)
  250. # [12:38] * Joins: Lachy (~Lachy@public.cloak)
  251. # [12:49] * Joins: chaals (~Adium@public.cloak)
  252. # [13:08] * Quits: yoichio (~yoichio@public.cloak) ("Leaving...")
  253. # [13:13] * Quits: chaals (~Adium@public.cloak) ("Leaving.")
  254. # [13:14] * Joins: yoichio (~yoichio@public.cloak)
  255. # [13:35] * Quits: Lachy (~Lachy@public.cloak) ("Computer has gone to sleep.")
  256. # [13:50] * Joins: Lachy (~Lachy@public.cloak)
  257. # [14:14] * Quits: karl (~karlcow@public.cloak) (":tiuQ tiuq sah woclrak")
  258. # [14:14] * Joins: karl (~karlcow@public.cloak)
  259. # [14:21] * Zakim excuses himself; his presence no longer seems to be needed
  260. # [14:21] * Parts: Zakim (zakim@public.cloak) (Zakim)
  261. # [14:45] * Quits: skddc (~anonymous@public.cloak) (skddc)
  262. # [15:15] * Joins: davidb (~davidb@public.cloak)
  263. # [15:25] * Joins: fjh (~fhirsch3@public.cloak)
  264. # [15:29] * Joins: Rob (~Rob@public.cloak)
  265. # [15:57] * Joins: skddc (~anonymous@public.cloak)
  266. # [17:33] * Joins: divya (~Adium@public.cloak)
  267. # [17:34] * Joins: jeffh (~d871a880@public.cloak)
  268. # [17:38] * Joins: chaals (~Adium@public.cloak)
  269. # [17:55] * Quits: Rob (~Rob@public.cloak) (Rob)
  270. # [18:00] * Joins: tantek (~tpod@public.cloak)
  271. # [18:03] * Joins: sgalineau (~sgalineau@public.cloak)
  272. # [18:10] * Quits: divya (~Adium@public.cloak) ("Leaving.")
  273. # [18:13] * Quits: fjh (~fhirsch3@public.cloak) (fjh)
  274. # [18:13] * Quits: tantek (~tpod@public.cloak) ("Colloquy for iPod touch - http://colloquy.mobi")
  275. # [18:21] * Joins: Rob (~Rob@public.cloak)
  276. # [18:21] * Joins: tantek (~tpod@public.cloak)
  277. # [18:32] * Quits: tantek (~tpod@public.cloak) ("Colloquy for iPod touch - http://colloquy.mobi")
  278. # [18:43] * Quits: Lachy (~Lachy@public.cloak) ("Computer has gone to sleep.")
  279. # [18:46] * Quits: chaals (~Adium@public.cloak) ("Leaving.")
  280. # [18:47] * Quits: smaug (~chatzilla@public.cloak) ("ChatZilla 0.9.90.1 [Firefox 26.0a1/20130815030203]")
  281. # [18:47] * Joins: smaug (~chatzilla@public.cloak)
  282. # [18:52] * Joins: tantek (~tpod@public.cloak)
  283. # [18:56] * Quits: davidb (~davidb@public.cloak) (davidb)
  284. # [18:57] * Joins: davidb (~davidb@public.cloak)
  285. # [19:06] * Quits: tantek (~tpod@public.cloak) ("Colloquy for iPod touch - http://colloquy.mobi")
  286. # [19:07] * Joins: divya (~Adium@public.cloak)
  287. # [19:08] * Quits: divya (~Adium@public.cloak) ("Leaving.")
  288. # [19:08] * Joins: divya (~Adium@public.cloak)
  289. # [19:08] * Joins: divya1 (~Adium@public.cloak)
  290. # [19:08] * Quits: divya (~Adium@public.cloak) (Client closed connection)
  291. # [19:17] * Quits: divya1 (~Adium@public.cloak) ("Leaving.")
  292. # [19:20] * Joins: jsbell (~jsbell@public.cloak)
  293. # [19:33] * Joins: Lachy (~Lachy@public.cloak)
  294. # [19:49] * Joins: divya (~Adium@public.cloak)
  295. # [19:56] * Quits: divya (~Adium@public.cloak) (Ping timeout: 180 seconds)
  296. # [20:06] * Joins: chaals (~Adium@public.cloak)
  297. # [20:27] * Quits: chaals (~Adium@public.cloak) ("Leaving.")
  298. # [20:28] * Quits: sgalineau (~sgalineau@public.cloak) (Client closed connection)
  299. # [21:01] * Quits: Lachy (~Lachy@public.cloak) ("Computer has gone to sleep.")
  300. # [21:15] * Quits: skddc (~anonymous@public.cloak) (skddc)
  301. # [21:21] * Joins: divya (~Adium@public.cloak)
  302. # [21:25] * Joins: divya1 (~Adium@public.cloak)
  303. # [21:27] * Joins: Lachy (~Lachy@public.cloak)
  304. # [21:30] * Quits: divya (~Adium@public.cloak) (Ping timeout: 180 seconds)
  305. # [21:59] * Quits: Rob (~Rob@public.cloak) (Rob)
  306. # [22:09] * Quits: davidb (~davidb@public.cloak) (davidb)
  307. # [22:10] * Joins: Rob (~Rob@public.cloak)
  308. # [22:13] * Joins: tantek (~tpod@public.cloak)
  309. # [22:14] * Quits: tantek (~tpod@public.cloak) ("Colloquy for iPod touch - http://colloquy.mobi")
  310. # [23:08] * Quits: karl (~karlcow@public.cloak) (":tiuQ tiuq sah woclrak")
  311. # Session Close: Thu Aug 22 00:00:00 2013

The end :)