IRC log of webapps on 2013-08-21

Timestamps are in UTC.

00:01:20 [RRSAgent]
RRSAgent has joined #webapps
00:01:20 [RRSAgent]
logging to http://www.w3.org/2013/08/21-webapps-irc
00:01:31 [Travis]
Zakim, this is DOM3
00:01:31 [Zakim]
ok, Travis; that matches RWC_WAPI(D3E)8:00PM
00:01:53 [kochi_home]
kochi_home has joined #webapps
00:02:07 [kochi_home]
hello
00:02:18 [garykac]
garykac has joined #webapps
00:02:18 [Travis]
Hi!
00:02:28 [kochi_home]
calling in soon.
00:02:31 [masayuki]
Hello!
00:02:33 [garykac]
Hallo
00:03:11 [Zakim]
+ +1.425.893.aaaa
00:03:13 [Zakim]
- +1.425.893.aaaa
00:03:13 [Zakim]
+ +1.425.893.aaaa
00:03:25 [Travis]
RRSAgent, this meeting spans midnight
00:03:44 [Travis]
zakim, +1.425 is garykac
00:03:45 [Zakim]
+garykac; got it
00:04:25 [Travis]
Present+ Travis_Leithead
00:04:27 [Zakim]
+[IPcaller]
00:04:30 [Travis]
Present+ Gary_K
00:04:50 [Travis]
zakim, ipcaller is kochi_home
00:04:50 [Zakim]
+kochi_home; got it
00:05:46 [Travis]
Present+ Jianfeng_Lin
00:06:58 [Travis]
https://docs.google.com/document/d/1pGo9hmOXCu71lnpXbqpTQNQP70DU9E-1tNN3yEWg5ig/edit?usp=sharing
00:07:53 [garykac]
Item 1: Order of beforeinput and compositionupdate events
00:08:35 [garykac]
Discussed in the doc, but there was a previous discussion that I missed where the opposite order was proposed.
00:09:27 [masayuki]
Is beforeinput fired during composition?
00:10:54 [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".
00:11:13 [Travis]
Traditionally, keydown is the appropriate cancellation point.
00:11:45 [Travis]
Do we have concensus on this point?
00:13:32 [masayuki]
Firefox will be cancellable with keydown.preventDefault() on Windows and Linux. (on Mac, it's been so already)
00:13:56 [garykac]
Is if guaranteed that we can always cancel the IME by canceling keydown?
00:13:57 [Travis]
We can test with a wide variety of IME's, but some may not support it.
00:14:05 [garykac]
I was under the impression that it was not *always* possible.
00:14:52 [masayuki]
If keydown is fired *before* it's passed through IME, it's possible.
00:15:14 [masayuki]
But I don't know it's possible on mobile platforms.
00:15:42 [Travis]
Item 2: should keydown/up be fired during composition?
00:15:46 [kochi_home]
yeah, on Android basically all on-screen keyboards are IME
00:17:07 [garykac]
Item 2: should we send keydown/keyup events during composition
00:17:25 [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.
00:17:45 [masayuki]
Historically, should be fired for not breaking the web.
00:18:10 [garykac]
Masayuki: Just because handwriting systems don't send key events, doesn't mean that keyboards should send key events.
00:18:35 [garykac]
compositon events are not *required* to have key events
00:18:53 [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)
00:19:03 [garykac]
but if they are coming from a keyboard, it's not unreasonable to include them
00:19:36 [Travis]
Firefox does not fire them during composition. So is there really a risk of breaking the web?
00:19:37 [masayuki]
garykac: I undersand it, but not all web application developers don't understand so, I guess.
00:20:48 [masayuki]
Travis: We have some reports of such web sites.
00:21:11 [garykac]
One downside of removing them, is that the initial keyup and the last keydown tend to get lost (since they occur during "composition").
00:21:26 [garykac]
I would be happier if every keydown had a matching keyup event.
00:21:56 [garykac]
masayuki: Some websites have complained about the lack of keydown/keyup events?
00:22:05 [garykac]
Was it a lot of sites?
00:22:55 [masayuki]
garykac: No so many. But I don't know the actual number.
00:23:15 [masayuki]
garykac: But they should use compositionupdate or input event.
00:24:35 [masayuki]
Anyway, such web sites are not available from handwriting system.
00:25:15 [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
00:25:19 [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.
00:27:03 [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.
00:27:05 [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.
00:27:11 [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)
00:28:00 [Travis]
I think that the browser could figure that out based on state of composition.
00:28:00 [kochi_home]
what about event for key presses that is not consumed by IME?
00:28:21 [Travis]
Example?
00:28:29 [garykac]
But Chrome and IE are currently sending the key events during composition, so the events are available (for common IMEs at least)
00:28:41 [kochi_home]
hmm, most keys are consumed, but maybe PageUp etc?
00:29:22 [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.)
00:29:43 [masayuki]
kochi_home: keypress event isn't fired for non-printable keys except Firefox
00:30:00 [Travis]
Ditto.
00:30:08 [kochi_home]
masayuki: what about keyup/down
00:30:10 [kochi_home]
?
00:30:35 [kochi_home]
so, during IME composition, some non-IME key may generate keydown/up events?
00:31:57 [garykac]
So, if the IME doesn't consume the key, it would pass it on?
00:32:28 [Travis]
I'm not sure that an IME can "consume" the key completely.
00:32:45 [masayuki]
kochi_home: Chrome does so. IE is complicated...
00:34:28 [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).
00:36:06 [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.
00:36:48 [Travis]
Item 4: Recommend beforeinput instead of keypress.
00:36:57 [Travis]
We are all in agreement on this, I think.
00:37:38 [masayuki]
Yes, but for it, beforeinput should be fired on non-editable element.
00:37:46 [garykac]
What Event shoudl beforeinput and input be associated with.
00:38:11 [garykac]
We had assumed that input would send an Event
00:38:13 [Travis]
Item 5: What event type should beforeinput be? It needs to have some useful content in the event itself.
00:38:21 [garykac]
But beforeinput needs to send more info than that
00:38:22 [masayuki]
And beforeinput should have all information which is included keypress event.
00:39:50 [garykac]
So, let's go with having a new event type: InputEvent
00:39:57 [Travis]
Sounds good to me.
00:39:59 [garykac]
That way we can add the fields we need to it.
00:40:09 [masayuki]
agree.
00:41:06 [masayuki]
I think we don't discuss about beforeinput at non-printable key combination, such as Ctrl+C.
00:41:28 [masayuki]
I think that on such case, beforeinput should be also fired.
00:42:03 [Travis]
Item 6: When does beforeinput fire in relation to composition update?
00:42:21 [garykac]
Do we want beforeinput + updateDOM + compositionupdate + input
00:42:41 [garykac]
or compositionupdate + beforeinput + updateDOM + input
00:42:55 [Travis]
'input' doesn't fire very consistently either during a composition, right?
00:43:08 [masayuki]
IIRC, at the previous discussion, don't we agree with no dispatching beforeinput during compsoition?
00:43:09 [garykac]
Effectively, this comes down to whether or not the DOM should be updated before compositionupate
00:43:43 [masayuki]
I misunderstood?
00:44:21 [garykac]
masayuki: Ojan mentioned a use case where beforeinput was always needed before the DOM was updated (by anyone, including composition)
00:44:44 [masayuki]
garykac: Okay.
00:44:50 [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.
00:45:25 [Travis]
Seems like we all agree.
00:45:29 [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
00:45:49 [masayuki]
Okay.
00:47:34 [masayuki]
At previous discussion, we agreed with that compositionupdate should be cancellable. So, compositionupdate should be fired before updating DOM.
00:48:48 [kochi_home]
yeah, if IE can follow the behavior.
00:50:19 [kochi_home]
so cancelling composition update just cancels updating the DOM?
00:50:24 [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)
00:50:26 [Travis]
So, I think we want an order of beforeinput + compositionupdate + DOM update + input
00:50:52 [garykac]
Next question: preference for beforeinput + compositionupdate + DOM + input vs. compositionupdate + beforeinput + DOM + input
00:51:04 [garykac]
either way sounds good to me
00:51:19 [Travis]
I prefer the former.
00:51:21 [masayuki]
kochi_home: AFAIK, there is no platform which can cancel compositionupdate actually.
00:51:25 [garykac]
I'll go with Travis' suggestion
00:52:03 [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.
00:52:05 [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"
00:52:12 [kochi_home]
masayuki: okay, cancelling compositionupdate is not so useful or confusing (to the system) anyway.
00:53:14 [Travis]
Item 7: Which elements do fire the beforeinput/input events ?
00:53:39 [masayuki]
How about compositionend vs. beforeinput? Which is important for the consistency event order.
00:54:03 [garykac]
masayuki: I don't think the order matters. Can you think of a case where it does matter?
00:54:50 [masayuki]
garykac: Simpler order is easy to understand :-)
00:56:26 [masayuki]
Travis: I think it should be fired on all elements because keypress behaves so.
00:56:47 [masayuki]
I meant beforeinput, not input.
00:57:44 [masayuki]
input event is fired from internal editor. So, input cannot be fired from non-editable element.
00:58:47 [garykac]
masayuki: If you add the "inputmode" flag to an element, then it will receive beforeinput and input events
00:59:19 [garykac]
masayuki: by default, they're only sent to contenteditable, but other elements can request them
00:59:58 [masayuki]
garykac: Sounds strange to me...
01:00:24 [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).
01:00:49 [masayuki]
garykac: And such behavior makes browser implementation complicated, I think.
01:01:55 [garykac]
In general, we shouldn't be sending events to every single element type (as was done in the past).
01:03:09 [garykac]
And it sounds like we have a mechanism ("inputmode") where elements can request to receive these events.
01:03:21 [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.
01:03:59 [kochi_home]
yeah, if element has inputmode and is focused.
01:04:16 [garykac]
So someone who is catching keypress on the <body> can add inputmode to receive these events, otherwise they won't.
01:04:29 [garykac]
(sorry, bad edit, let me re-phrase)
01:04:38 [masayuki]
Hmm, if we take such behavior, keypress isn't more useful for web developers?
01:05:22 [masayuki]
keypress doesn't need inputmode setting which is additional work.
01:05:29 [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
01:05:51 [garykac]
Switching to use beforeinput is already work that we're expecting people to do.
01:06:09 [garykac]
Browsers will support keypress as long as websites still do these horrible things.
01:06:34 [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?
01:07:02 [Travis]
Because with beforeinput, they're only interested in getting the events that really do generate input.
01:07:18 [garykac]
But the switch to use beforeinput and adding "inputmode" on the element where they attach the listener is not unreasonable.
01:07:18 [Travis]
keypress did not come with that guarantee.
01:07:57 [Travis]
We're saying the keydown/up are the natural replacement for keypress -- in this scenario only.
01:08:04 [masayuki]
So, before input isn't fired for non-text-input? Like Ctrl+C?
01:08:19 [Travis]
(The scenario of watching for all key action on the keyboard on the body)
01:08:45 [garykac]
beforeinput should fire anytime the DOM is about to be updated - regardless of what is making the change
01:09:06 [Travis]
I don't think input is fired for a Ctrl+C either...
01:09:23 [Travis]
Ctrl+V should fire beforeinput
01:09:32 [Travis]
Undo/Paste should do it too.
01:09:57 [masayuki]
Travis: I don't think so, Ctrl+V shouldn't cause beforeinput if it's not fired by all key combinations.
01:10:48 [masayuki]
Travis: because it's difficult to know whether an edit command is kicked by key event or not.
01:10:48 [Travis]
Correct: if a keyboard mapping has the "paste" action using a different key pair, then it won't fire beforeinput.
01:10:54 [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.
01:11:55 [masayuki]
Hmm, I don't think that before input shouldn't be fired for edit command.
01:12:26 [masayuki]
Because it's cancelable, so, it's necessary to be fired synchronously.
01:12:33 [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.
01:12:51 [masayuki]
It means it may cause event loop by attacker.
01:12:58 [Travis]
Next call: September 3rd, 2013
01:13:38 [masayuki]
Travis: no problem for me.
01:13:38 [Travis]
Masayuki, can you send your feedback to the mailing list so that we can continue this conversation?
01:14:06 [masayuki]
Travis: Okay.
01:14:15 [Travis]
Alright. Time's up!
01:14:23 [Travis]
Thanks everyone for the discussion we made great headway.
01:14:29 [masayuki]
Thank you.
01:14:30 [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.
01:14:30 [kochi_home]
Thanks!
01:14:34 [garykac]
Thank you.
01:14:46 [Zakim]
-[Microsoft]
01:14:48 [Zakim]
-garykac
01:14:49 [Zakim]
-kochi_home
01:14:49 [Zakim]
RWC_WAPI(D3E)8:00PM has ended
01:14:49 [Zakim]
Attendees were [Microsoft], +1.425.893.aaaa, garykac, kochi_home
01:15:49 [Travis]
Zakim, 425.89 is Travis
01:15:49 [Zakim]
sorry, Travis, I do not recognize a party named '425.89'
01:16:00 [Travis]
Zakim, +1.425.89 is Travis
01:16:00 [Zakim]
sorry, Travis, I do not recognize a party named '+1.425.89'
01:16:26 [Travis]
rrsagent, please make the minutes
01:16:26 [RRSAgent]
I have made the request to generate http://www.w3.org/2013/08/21-webapps-minutes.html Travis
01:17:00 [Travis]
rrsagent, make logs public
01:21:18 [kochi_home]
kochi_home has joined #webapps
01:28:07 [kochi_ho_]
kochi_ho_ has joined #webapps
01:28:18 [kochi_ho_]
kochi_ho_ has left #webapps
01:28:55 [kochi_home]
kochi_home has joined #webapps
02:01:01 [karl]
karl has joined #webapps
02:01:19 [Rob]
Rob has joined #webapps
02:39:28 [kochi_home]
kochi_home has joined #webapps
02:51:10 [jeffh]
jeffh has joined #webapps
03:14:50 [kochi_home]
kochi_home has joined #webapps
03:16:48 [kochi_ho_]
kochi_ho_ has joined #webapps
03:29:13 [kochi_home]
kochi_home has joined #webapps
04:05:51 [kochi_home]
kochi_home has joined #webapps
04:11:35 [Rob]
Rob has joined #webapps
06:00:10 [tobie]
tobie has joined #webapps
08:19:54 [yoichio]
yoichio has joined #webapps
08:27:20 [tobie]
tobie has joined #webapps
09:04:36 [Lachy]
Lachy has joined #webapps
09:08:24 [smaug]
smaug has joined #webapps
09:39:52 [skddc]
skddc has joined #webapps
09:56:37 [skddc]
skddc has joined #webapps
10:33:02 [karl]
karl has joined #webapps
10:42:38 [Lachy]
Lachy has joined #webapps
10:53:42 [chaals]
chaals has joined #webapps
11:18:41 [yoichio]
yoichio has joined #webapps
11:54:57 [Lachy]
Lachy has joined #webapps
12:18:43 [karl]
karl has joined #webapps
12:25:20 [Zakim]
Zakim has left #webapps
13:19:27 [davidb]
davidb has joined #webapps
13:29:54 [fjh]
fjh has joined #webapps
13:33:18 [Rob]
Rob has joined #webapps
14:01:38 [skddc]
skddc has joined #webapps
15:37:27 [divya]
divya has joined #webapps
15:38:51 [jeffh]
jeffh has joined #webapps
15:42:14 [chaals]
chaals has joined #webapps
16:04:22 [tantek]
tantek has joined #webapps
16:07:41 [sgalineau]
sgalineau has joined #webapps
16:25:02 [Rob]
Rob has joined #webapps
16:25:06 [tantek]
tantek has joined #webapps
16:51:22 [smaug]
smaug has joined #webapps
16:56:39 [tantek]
tantek has joined #webapps
17:01:11 [davidb]
davidb has joined #webapps
17:12:00 [divya]
divya has joined #webapps
17:12:11 [divya]
divya has joined #webapps
17:12:33 [divya1]
divya1 has joined #webapps
17:24:44 [jsbell]
jsbell has joined #webapps
17:37:39 [Lachy]
Lachy has joined #webapps
17:53:54 [divya]
divya has joined #webapps
18:10:59 [chaals]
chaals has joined #webapps
19:25:58 [divya]
divya has joined #webapps
19:29:04 [divya1]
divya1 has joined #webapps
19:31:41 [Lachy]
Lachy has joined #webapps
20:14:52 [Rob]
Rob has joined #webapps
20:17:30 [tantek]
tantek has joined #webapps
22:04:18 [chaals]
chaals has joined #webapps
22:31:16 [tobie]
tobie has joined #webapps
22:46:31 [karl]
karl has joined #webapps
22:51:01 [skddc]
skddc has joined #webapps
23:24:36 [divya]
divya has joined #webapps
23:55:22 [sgalineau]
sgalineau has joined #webapps
01:21:05 [jeffh]
jeffh has joined #webapps
01:42:45 [Rob]
Rob has joined #webapps
01:46:22 [Rob]
Rob has joined #webapps
01:46:38 [Rob]
Rob has left #webapps
02:25:08 [skddc_]
skddc_ has joined #webapps
02:41:16 [karl]
karl has joined #webapps
03:33:47 [MikeSmith_]
MikeSmith_ has joined #webapps
06:27:20 [tobie]
tobie has joined #webapps
06:50:22 [skddc]
skddc has joined #webapps
07:08:44 [yoichio]
yoichio has joined #webapps
07:17:14 [yoichio]
yoichio has joined #webapps
07:56:23 [Lachy]
Lachy has joined #webapps
08:22:13 [skddc_]
skddc_ has joined #webapps
08:26:29 [Lachy]
Lachy has joined #webapps
08:45:50 [smaug]
smaug has joined #webapps
12:04:42 [darobin]
darobin has joined #webapps
12:18:55 [skddc]
skddc has joined #webapps
12:27:55 [smaug]
smaug has joined #webapps
12:32:11 [chaals]
chaals has joined #webapps
12:37:24 [davidb]
davidb has joined #webapps
12:44:15 [dom]
dom has joined #webapps
12:44:40 [smaug]
smaug has joined #webapps
12:59:27 [karl]
karl has joined #webapps
13:14:38 [smaug]
smaug has joined #webapps
13:37:35 [marcosc]
marcosc has joined #webapps
15:35:36 [fjh]
fjh has joined #webapps
16:05:22 [Lachy]
Lachy has joined #webapps
16:05:56 [jsbell]
jsbell has joined #webapps
16:18:42 [divya]
divya has joined #webapps
16:22:49 [tantek]
tantek has joined #webapps
16:33:38 [skddc]
skddc has joined #webapps
16:56:46 [jeffh]
jeffh has joined #webapps
17:08:56 [fjh]
fjh has left #webapps
17:28:58 [smaug]
smaug has joined #webapps
17:30:39 [divya]
divya has joined #webapps
17:31:06 [divya1]
divya1 has joined #webapps
17:55:44 [tantek]
tantek has joined #webapps
18:24:48 [fjh]
fjh has joined #webapps
18:25:25 [fjh]
fjh has left #webapps
18:49:27 [divya]
divya has joined #webapps
19:00:45 [chaals]
chaals has joined #webapps
19:21:59 [divya]
divya has joined #webapps
19:37:44 [sicking]
sicking has joined #webapps
19:52:54 [marcosc]
marcosc has joined #webapps
20:03:29 [jeffh]
jeffh has joined #webapps
20:04:04 [divya]
divya has joined #webapps
21:04:17 [divya1]
divya1 has joined #webapps
21:17:46 [marcosc]
marcosc has joined #webapps
21:31:43 [divya]
divya has joined #webapps
22:00:42 [smaug]
smaug has joined #webapps
22:04:34 [divya]
divya has joined #webapps
22:11:55 [marcosc]
marcosc has joined #webapps
22:52:58 [glenn_]
glenn_ has joined #webapps
22:53:34 [divya]
divya has joined #webapps
23:06:04 [marcosc]
marcosc has joined #webapps
23:06:49 [sicking]
sicking has joined #webapps
23:24:00 [glenn]
glenn has joined #webapps
23:26:14 [marcosc]
marcosc has joined #webapps
23:29:11 [smaug]
smaug has joined #webapps
23:32:38 [sicking]
sicking has joined #webapps
23:58:33 [divya]
divya has joined #webapps
23:59:17 [glenn_]
glenn_ has joined #webapps
00:09:13 [tantek]
tantek has joined #webapps
00:23:28 [divya]
divya has joined #webapps
01:25:36 [sicking]
sicking has joined #webapps
03:05:46 [glenn]
glenn has joined #webapps
05:55:57 [tobie]
tobie has joined #webapps
06:12:07 [skddc]
skddc has joined #webapps
06:13:43 [skddc_]
skddc_ has joined #webapps
08:51:44 [smaug]
smaug has joined #webapps
09:18:01 [Lachy]
Lachy has joined #webapps
09:54:02 [Lachy]
Lachy has joined #webapps
10:50:35 [darobin]
darobin has joined #webapps
12:33:24 [darobin_]
darobin_ has joined #webapps
13:54:52 [jungkees]
jungkees has joined #webapps
14:24:48 [Lachy_]
Lachy_ has joined #webapps
15:30:40 [skddc]
skddc has joined #webapps
15:44:09 [divya]
divya has joined #webapps
15:44:37 [divya1]
divya1 has joined #webapps
16:00:58 [darobin_]
darobin_ has joined #webapps
16:06:00 [shepazu]
shepazu has joined #webapps
16:06:39 [shepazu]
shepazu has joined #webapps
16:11:20 [shepazu]
shepazu has joined #webapps
16:14:05 [jsbell]
jsbell has joined #webapps
16:20:09 [divya]
divya has joined #webapps
16:58:54 [skddc]
skddc has joined #webapps
17:55:27 [tantek]
tantek has joined #webapps
17:59:36 [jeffh]
jeffh has joined #webapps
19:00:06 [jeffh]
jeffh has joined #webapps
19:07:42 [sgalineau]
sgalineau has joined #webapps
19:15:17 [divya]
divya has joined #webapps
20:09:50 [divya]
divya has joined #webapps
20:24:54 [divya]
divya has joined #webapps
20:55:21 [divya]
divya has joined #webapps
21:03:43 [Lachy]
Lachy has joined #webapps
21:30:46 [smaug]
smaug has joined #webapps
22:42:27 [skddc]
skddc has joined #webapps
23:00:39 [sicking]
sicking has joined #webapps
23:09:11 [divya]
divya has joined #webapps