30-July-2013

[01:54] <garykac> Hello Masayuki

[01:55] <masayuki> garykac: hello

[01:56] <kochi_ho_> hello

[01:58] <garykac> We're dialing into the the bridge, but we intend to use the chat room as much as possible for the discussion.

[01:58] <garykac> It doesn't seem that Travis is here yet.

[02:00] <garykac> I don't know how to use the Zakim commands as well as Travis, so we probably won't use them.

[02:00] <garykac> The only Agenda item that I have is to go over the open bugs.

[02:00] <garykac> I've started going through some of them, and have some fixes.

[02:01] <garykac> Does anyone have any other issues to add to the agenda?

[02:01] <garykac> (other than things being tracked in bugs)

[02:02] <kochi_ho_> beforeInput

[02:02] <garykac> We need to discuss beforeinputevent vs. textInput event

[02:02] <real_wez> garykac: we have bug 22070 for that

[02:03] <garykac> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22070

[02:04] <garykac> That bug is what we have so far for that issue. I was supposed to start an email thread to discuss this issue.

[02:04] <garykac> Was there anything in particular you wanted to discuss about beforeInput

[02:06] <garykac> I will send an email to the webapps group that summarizes the issues to initiate a discussion in a larger group of people.

[02:06] <garykac> We raised a bunch of issues during our last confcall, and there were other concerns mentioned in the bug.

[02:06] <garykac> I want to summarize both "sides" of the issue as best as I can.

[02:06] <garykac> Kochi, did you have any preferences or concerns that you wanted to raise?

[02:07] <garykac> <kochi> concerns are that we should specify the order of the events

[02:07] <garykac> Did you have a preference between beforeinputevent vs. textinput

[02:08] <Travis> I'm here!

[02:08] <Travis> Sorry about the wait..

[02:08] <kochi_ho_> hello Travis

[02:08] <garykac> kochi says that beforeinput is cancelable while textinput is not.

[02:08] <Travis> Going to call in momentarily...

[02:09] <garykac> Actually, textinput needs to be cancelable since it is intended to be a replacement for keypress (which was cancelable).

[02:09] <RRSAgent> logging to http://www.w3.org/2013/07/31-webapps-irc

[02:09] <Travis> RRSAgent: this is dom3

[02:09] <RRSAgent> I'm logging. I don't understand 'this is dom3', Travis. Try /msg RRSAgent help

[02:10] <Travis> RRSAgent, this meeting spans midnight

[02:10] <RRSAgent> ok, Travis; I will not start a new log at midnight

[02:11] <masayuki> Spec should define the order of keydown, beforeinput, keypress and input for a key press and of keydown, compositionstart, beforeinput compositionupdate, compositionend, input.

[02:11] <masayuki> for IME.

[02:11] <masayuki> I like the order which I wrote above.

[02:12] <garykac> Masayuki: agreed

[02:12] <kochi_ho_> sounds good

[02:12] <Travis> Do we have any disagreement on the current proposal for beforeinput?

[02:12] <garykac> Excellent, that was my next question. I was going to ask you about a preferred event order. ^_^

[02:12] <kochi_ho_> where is the definitive 'beforinput' proposal?

[02:12] <garykac> Travis: only what's in 22070 and from our last teleconf

[02:14] <masayuki> I mentioned at last teleconf. Is the beforeinput is a good name? I mean that input is fired for *any* change of editor. However, before input should be fired only for the user input.

[02:15] <garykac> The beforeinput event is supposed to be general.

[02:15] <masayuki> E.g., it shouldn't be fired for "Undo", "Redo" and "Paste".

[02:15] <garykac> Yes

[02:15] <Travis> I honestly can't think of a better name for it.

[02:16] <Travis> "keyinput"?

[02:16] <kochi_ho_> yeah, speech or hand writing

[02:16] <masayuki> I think "userinput"?

[02:17] <garykac> The textinput event is a special case of beforeinput.

[02:17] <garykac> The name beforeinputevent was specified elsewhere (I forget which spec makes mention of it).

[02:18] <garykac> I imagine that there was a big discussion before they came to consensus on beforeinputevent...

[02:19] <garykac> What are people's preferences for beforeinputevent vs. textinput?

[02:20] <kochi_ho_> https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html mentions something on beforeInputEvent.

[02:20] <garykac> If we have textinput, do we need to always have beforeinput?

[02:20] <garykac> Is that generating too many events?

[02:21] <masayuki> textinput is already implemented on IE and WebKit by different way (IIRC). So, not using "textinput" doesn't cause any compatibility issues.

[02:22] <kochi_ho_> WebKit implements 'textInput'

[02:24] <masayuki> Yeah, I was confused by the case of "I" at writing testcase :(

[02:24] <Travis> What are the differences between the proposals for textinput and beforeinput?

[02:24] <Travis> textInput:

[02:24] <kochi_ho_> beforeinput is cancellable.

[02:24] <Travis> textInput is not cancellable

[02:26] <garykac> beforeinput doesn't give any indication of *what* has changed.

[02:26] <Travis> What event interface does each use?

[02:27] <Travis> IE had a "TextEvent" interface for "textInput" with fields for "data", "inputMethod", "locale".

[02:28] <Travis> beforeinput would use what? KeyboardEvent?

[02:28] <Travis> Event?

[02:28] <Travis> beforeinput _will_ need an event interface that contains the data that _will be_ inserted (if not cancelled)

[02:29] <masayuki> I think that beforeinput should have attributes which stores inputting text, modifier key state and whether it's fired for key or composition.

[02:29] <Travis> textinput = i'm only interested in keyboard event

[02:30] <Travis> beforeinput = i'm interested for all user input

[02:30] <Travis> Is this right?

[02:30] <masayuki> Travis: agree for the beforeinput

[02:31] <Travis> If we merge these two together into beforeinput, does that cover most scenarios?

[02:32] <garykac> Masayuki raised an issue in the bug about cutting/pasting.

[02:33] <masayuki> I understood that the main purpose of beforeinput is replacing keypress event and it's available for composition too.

[02:33] <Travis> keypress is cancellable?

[02:33] <Travis> garykac: Yes

[02:33] <masayuki> Travis: yes

[02:34] <Travis> Our solution to replace keypress must be cancellable.

[02:35] <Travis> If we made textinput cancelable, then it does effectively replace the keypress.

[02:37] <masayuki> Travis: it might be possible, but I worry about the compatibility issue with older textinput (textInput).

[02:37] <Travis> Note to self: we can't just standardize keypress because we would need to change its behavior in a few areas (the return value for keyCode/charCode/firingorder?/) and those would break the web.

[02:38] <kochi_ho_> yeah, on WebKit textInput event is dispatched after DOM modification

[02:38] <garykac> Masayuki: textInput was intended as a replacement for keypress (because keypress is not consistent across browsers). beforeinput is a general way of handling input events like textinput.

[02:39] <garykac> Masayuki: Hence, it would be nice if we could merge textinput into beforeinput (to reduce the number of events fired).

[02:39] <Travis> Do we really need both textinput and beforeinput to fullfill all scenarios?

[02:39] <Travis> garykac: I don't think so.

[02:39] <masayuki> garykac: yes, therefore, I believe that defining new event, beforeinput, is the best way.

[02:43] <Travis> Here's where I think we are:

[02:43] <masayuki> I think that we don't need to worry about the cost of firing textinput (textInput). If the cost is expensive, the browsers should check whether there is one or more event listeners for it.

[02:43] <Travis> Add a definition for beforeinput into DOM3Events

[02:43] <Travis> Make beforeinput cancellable

[02:43] <Travis> Make beforeinput be associated with a new Event interface (BeforeInputEvent), which has at least one field for the "data"

[02:44] <masayuki> Travis: but it should NOT be cancellable while composition.

[02:44] <Travis> Hmm, why?

[02:44] <Travis> (Maybe "value" or "input" -- since "data" may already be in use)

[02:44] <garykac> Masayuki: why not? what problems does it cause?

[02:44] <masayuki> Travis: because we have no way to cancel only one compositionupdate of native IME on any platforms.

[02:45] <masayuki> We can just make it cancelable immediately before compositionend, though.

[02:46] <garykac> Could beforeinput be fired after compositionend?

[02:48] <kochi_ho_> typically on windows key events will be VK_PROCESS while IME is on

[02:48] <masayuki> compositionend is just a notification of the result of composition.

[02:49] <garykac> I assume the each beforeinput should be followed by an 'input' event.

[02:50] <garykac> So it seems that the events should be : keydown, ... compositionbegin/update/end ... beforeinput, input

[02:50] <kochi_ho_> garykac: agree

[02:50] <garykac> Does that work? Not allowing beforeInput to fire until compositionend has signaled the end of the composition?

[02:51] <garykac> That way we could cancel beforeinput without impacting the IME events

[02:51] <masayuki> garykac: If so, web apps cannot check the modified value with compositionupdate event, is it OK?

[02:52] <garykac> If they want to see the modified IME events, can't they get that info from the composition events? That seems reasonable to me.

[02:52] <masayuki> I think that beforeinput should be fired immediately before compositionupdate (not cancellable) and immediately after compositionend (cancellable).

[02:53] <garykac> What's the value of firing beforeinput before compositionupdate? Can't you get everything you need from the compositionupdate event?

[02:54] <kochi_ho_> masayuki: firing beforeinput before compositionupdate, and if the beforeinput event is cancelled, user agent doesn't fire compositionupdate and doesn't update .value either?

[02:54] <garykac> That way, we don't have to define beforeinput as sometimes cancelable, but other times not-cancelable.

[02:55] <masayuki> garykac: I believe that it's worthwhile web apps can handle all user input only with beforeinput even during composition.

[02:56] <kochi_ho_> masayuki: yes, I agree

[02:56] <masayuki> kochi_ho_: I don't think so, even if preventDefault() of beforeinput before compositionupdate is called, browser don't change the later behavior.

[02:57] <kochi_ho_> masayuki: so compositionupdate will be dispatched anyway?

[02:57] <garykac> During compositionupdate, no input is being proposed - it's just a candidate at that point. It's not about to be inserted until the compositionend event fires.

[02:57] <garykac> So, technically, it doesn't seem like it's "input" yet.

[02:57] <masayuki> kochi_ho_: I think so.

[02:58] <masayuki> garykac: "input" event is also fired after compositionupdate.

[02:58] <kochi_ho_> masayuki: if beforeinput before compositionupdate is cancelled, that means the app doesn't want the .value to be modified, so if any DOM modification doesn't occur, compositionupdate won't fire either? no?

[02:59] <kochi_ho_> (if chrome/ff follow the order of composition update as IE9+)

[02:59] <garykac> Masayuki: does it make sense for 'input' to fire after each compositionupdate? I'm not sure it does. what use cases does that support?

[03:00] <kochi_ho_> garykac: apps like google suggest can only have to handle input event?

[03:00] <garykac> I think that the spec becomes a lot easier if the beforeinput/input events don't fire until after all the composition events are done.

[03:00] <masayuki> kochi_ho_: If browser doesn't modify compostion string in their editor, IME has modified composition string. Such difference shouldn't occur.

[03:01] <kochi_ho_> masayuki: ah, ok, so IME has the modified string anyway.

[03:01] <garykac> kochi_ho: but apps should be able to ignore compositionevents if they're not interested in them. If beforeinput fires during the middle of composition, then I receive these extra beforeinput/input events that I'm not necessarily expecting.

[03:02] <masayuki> garykac: yes. like google suggest needs the input events after compositionupdate.

[03:02] <garykac> I'm not sure it *needs* them. It could just have an eventhandler for compositonupdate events.

[03:03] <masayuki> kochi_ho: yes. If we allow such state, composition string and candidate list will be different.

[03:03] <garykac> It seems like a slight convenience for an edge case at the cost of a much more complex event specification.

[03:03] <kochi_ho_> (I personally wish we have a spec that forbids modifying .value during composition...)

[03:04] <masayuki> garykac: anyway, currently, all browsers fire input event after compositionupdate, IIRC.

[03:04] <garykac> But the 'input' event isn't specified anywhere!

[03:04] <kochi_ho_> masayuki: my idea for IME API is to allow js apps to draw composition string for composition update event, so beforeinput.preventDefault() can be used for the case.

[03:06] <Travis> I'm unfortable having beforeinput *sometimes* not cancellable.

[03:07] <masayuki> kochi_ho_: if IME supports cancelling a compositionupdate, I don't think beforeinput before compositionupdate shouldn't be cancellable. But native IMEs are not cancellable per compositionupdate.

[03:08] <garykac> kochi_ho: So calling beforeinput.preventDefault would stop the 'input' event. would it affect any of the composition events?

[03:08] <kochi_ho_> garykac: yes

[03:11] <masayuki> kochi_ho_: Hmm, sounds like browsers need to change the behavior whether the IME is native's or JS's.

[03:13] <kochi_ho_> masayuki: could you let me know the deatails offline (about native vs JS)?

[03:13] <masayuki> kochi_ho_: or JS IME API should have a method whether editor draws composition string automatically.

[03:14] <masayuki> kochi_ho_: Sure.

[03:14] <kochi_ho_> masayuki: ah, I meant the current state of IME API, which dropped the spec for writing IME in Javascript.

[03:14] <garykac> It would be nice if JS IME's behaved the same as native IMEs. I don't know if that's reasonable...

[03:16] <masayuki> garykac: Applications (browsers) cannot touch composition if there is no API.

[03:17] <Travis> We're going to need to wrap up.

[03:17] <garykac> Sadly, we need to wrap up for today. I'm going to draft a doc that explores the different events being fired (and cancelled). I'll share this out so that we can discuss pros/cons.

[03:18] <Travis> Thanks Gary.

[03:18] <kochi_ho_> thanks

[03:18] <masayuki> thanks

[03:18] <Travis> We meet again on the phone in 2 weeks.

[03:18] <garykac> Kochi_ho/masayuki: Thanks for your input/expertise.

[03:18] <Travis> Perhaps we could have Gary's doc in 1 week over email to begin looking through?

[03:19] <masayuki> garykac: you're welcome.

[03:19] <Travis> See you all next time: Aug 13, 2013!

[03:19] <garykac> See you then!

[03:19] <masayuki> Ah, wait.

[03:19] <masayuki> The week is holiday week of Japan.

[03:19] <kochi_ho_> i'm available on that day

[03:20] <masayuki> I'm not :-(

[03:20] <kochi_ho_> aha!

[03:20] <garykac> Let's find a time when we can all meet.

[03:21] <Travis> masayuki: when will work better? +/- a week?

[03:21] <garykac> Does August 6th work for everyone?

[03:21] <masayuki> Travis: Yes, and either is OK.

[03:21] <kochi_ho_> ok for me

[03:21] <masayuki> OK.

[03:22] <Travis> Let's try for Aug. 6th!

[03:22] <Travis> Done.

[03:22] <garykac> Hurray. August 6th it is.

[03:22] <masayuki> Thank you!

[03:22] <Travis> rrsagent, this is DOM3

[03:22] <RRSAgent> I'm logging. I don't understand 'this is DOM3', Travis. Try /msg RRSAgent help

[03:23] <Travis> zakim, this was DOM3

[03:23] <Zakim> I don't understand 'this was DOM3', Travis

[03:24] <Travis> RRSAgent, set logs public

[03:24] <RRSAgent> I have made the request, Travis

[03:25] <Travis> Zakim, what conferences are active?

[03:25] <Zakim> I see no active conferences and none scheduled to start in the next 15 minutes

[03:25] <Travis> zakim, this conference is "DOM3"

[03:25] <Zakim> sorry, Travis, I do not see a conference named '"DOM3"' in progress or scheduled at this time

[03:26] <Travis> RRSAgent, make the minutes

[03:26] <RRSAgent> I have made the request to generate http://www.w3.org/2013/07/31-webapps-minutes.html Travis

[03:26] <Travis> RRSAgent, set minutes public

[03:26] <RRSAgent> I'm logging. I don't understand 'set minutes public', Travis. Try /msg RRSAgent help

[03:27] <Travis> RRSAgent, set logs public

[03:27] <RRSAgent> I have made the request, Travis