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