23 July 2013

The following transcript from the 23 July 2013 DOM 3 Events call is also available at [http://krijnhoetmer.nl/irc-logs/webapps/20130724 http://krijnhoetmer.nl/irc-logs/webapps/20130724].

[17:06] <kochi_home> Is Travis here?

[17:10] travis may have messed up the teleconference time

[17:10] Anyone here for the DOML3Events call?

[17:10] <kochi_home> yes?

[17:10] here.

[17:10] <kochi_home> I see no agenda posted this week...

[17:11] I think I messed up the call times, and am not seeing a bridge available :-(

[17:11] (It's probably setup for next week.)

[17:11] <kochi_home> yeah, i called in but 3663# didn't work

[17:11] Yeah, me too.

[17:11] Well, we can still use IRC to discuss issues...

[17:12] <kochi_home> ok, so my naive question: is this call for finalizing DOM3, and any addition will go to DOM Events or so-called d4e?

[17:13] I'm going to pull up the bug list...

[17:13] <kochi_home> "this call" = this telconference

[17:14] kochi_home: Gary and I have been using this call to 1) get DOM L3 Events finished and also 2) make progress on "UI Events" (d4e).

[17:14] ... our focus is definately on #1 though.

[17:15] <kochi_home> i see, thanks for clarification.

[17:15] https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=DOM3%20Events&resolution=---&list_id=21086

[17:15] I see 30 bugs

[17:17] <kochi_home> For 18931, I think there is corresponding bugs in webkit and chromium issue tracker.

[17:17] The last time I checked in with Gary, he was preparing the spec for a heartbeat publication.

[17:17] Some bugs for defining key values are moved to UI Events, though... (e.g., bug 21120)

[17:19] <kochi_home> https://bugs.webkit.org/show_bug.cgi?id=31902 and .

[17:19] <kochi_home> https://code.google.com/p/chromium/issues/detail?id=41945

[17:19] Let's talk briefly about 18931.

[17:20] <kochi_home> sure

[17:21] It looks like we're looking at making the compositionupdate event timed such that the data will be available in the input/textarea field during the handling of the event.

[17:21] <kochi_home> so modifying the editor's value and then firing compositionend event,

[17:21] <kochi_home> ah, 'compositionupdate' event

[17:22] <kochi_home> chromium and webkit bugs refer to 'compositionend' event.

[17:22] <kochi_home> so they are slightly different

[17:22] Perhaps this bug is also about compositionend?

[17:22] <kochi_home> I think so.

[17:23] <kochi_home> compositionend should be used for scripts to notice that all the composition activities are finished and the resulting data is ready.

[17:23] Gecko and WebKit: compositionupdate -> modified -> input

[17:23] IE: modified -> compositionupdate -> input

[17:24] <kochi_home> I think IE's behavior makes more sense (in regards to bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=18931)

[17:24] agree.

[17:25] Gecko can change the behavior so.

[17:25] <travis_> In looking through the latest spec, I don't see the order in relation to the composition defined

[17:25] <kochi_home> If Gecko/WebKit/Blink are fixed to follow IE's order, there's some concern about compatibility, though

[17:25] <travis_> https://dvcs.w3.org/hg/dom3events/raw-file/6cc9e60bf4b1/html/DOM3-Events.html#event-type-compositionupdate

[17:25] <kochi_home> probably apps that depends on the order are rare, I hope

[17:27] <travis_> Spec current says:

[17:27] <travis_> A user agent SHOULD dispatch this event during a composition session when a text composition system updates its active text passage with a new character, which is added to the string in CompositionEvent.data. Some text composition systems might not expose this information to the DOM, in which case this event will not fire during the composition process. If the composition session is canceled, this event will be fired immediately before the compositionend event, and

[17:27] <travis_> ... the CompositionEvent.data attribute will be set to the empty string.

[17:27] Basically, if web apps need the latest value of the editor, using 'input' event is simpler because it's fired for any input.

[17:27] <travis_> Proposed new spec text?

[17:29] == travis [~[email protected]] has quit [Ping timeout: 180 seconds]

[17:30] <kochi_home> related question: does any spec say .value should/may reflect IME's on-going composition?

[17:30] <travis_> Sorry, .value of what object?

[17:31] <kochi_home> or <textarea> etc.

[17:31] no, but IIRC, IE, Gecko and WebKit includes the composition string to .value

[17:31] <kochi_home> I thought desktop browsers conventionally exposed IME's composition in .value, e.g. for Google Suggest

[17:32] <travis_> The spec's perspective is that a "text composition system" can, but may not be updating the actual control.

[17:33] <travis_> There are some IME's that are "separate" from the webpage, and do not provide the in-progress composition info back into the control, I believe, and the spec is trying to account for those cases...

[17:33] <kochi_home> travis_: sounds ok, so on some systems .value is not guaranteed to reflect the on-going composition.

[17:34] <travis_> However, most built-in IME's apparently do keep the composition in-line in the control, and the control's value are updated in real-time.

[17:34] Chinese IME typically doesn't expose composing string.

[17:35] <kochi_home> that's a security concern that may expose personalized dictionary order to the web, although this is a separate matter.

[17:35] <kochi_home> masayuki: in that case for Chinese IME, during the composition, compositionupdate events are fired?

[17:36] <kochi_home> (without modifying .value)

[17:36] kochi_home: no

[17:36] <kochi_home> i see.

[17:37] "Some text composition systems might not expose this information to the DOM, in which case this event will not fire during the composition process."

[17:37] <travis_> I updated the bug with some proposed spec text. Take a look.

[17:38] So, clearly, compositionupdate is defined for the event which notifies web apps of modifying composing string on DOM.

[17:38] <travis_> It sounds that way.

[17:39] <kochi_home> then firing compositionupdate after modifying DOM makes sense.

[17:39] <travis_> Other bugs or topics of interest?

[17:39] == sicking [~[email protected]] has quit [sicking]

[17:40] <kochi_home> (but then in the existence of input event, what's the value of 'compositionupdate'?...)

[17:41] <travis_> For cases where the composition system doesn't keep the text in sync, yet the developer wants to know the changes to the composition string in real-time anyway. The "data" property would provide the updates...

[17:41] kochi_home: If web apps want to watch the change only during composition, it's easier to use compositionupdate rather than input.

[17:41] <travis_> (at least two reasons :-)

[17:42] <kochi_home> okay...

[17:43] <travis_> Is there 1 or 2 bugs that we should have Gary focus on next?

[17:44] I hope that https://www.w3.org/Bugs/Public/show_bug.cgi?id=22084 should be fixed.

[17:45] <travis_> Sounds good. I know Gary wanted to tackle separating the monolithic table into smaller groups for ease-of-readability and to start to address some of these consistency problems.

[17:45] IE and Gecko need to change the .key value, probably...

[17:45] <travis_> Yes, for a number of things I believe.

[17:47] And also, I want to see the draft of https://www.w3.org/Bugs/Public/show_bug.cgi?id=22070

[17:49] <travis_> Agree.

[17:50] == tobie [[email protected]] has joined #webapps

[17:50] <travis_> So focus for next telco is 22084 and 22070--I'll see if I can inspire him to work on those.

[17:53] <travis_> 22070 still looks like it needs more info, but perhaps we can try to cut a draft.

[17:53] <kochi_home> btw, quick update on IME API: I'm drafting the next WD and will be posted to public-webapps soon.

[17:53] <travis_> Super!

[17:54] Excellent!

[17:54] <kochi_home> (sorry for hijacking D3E chat :)

[17:54] <travis_> :)

[17:54] <travis_> OK, time's almost up. Any last items to discuss?

[17:55] about "beforeinput".

[17:56] If beforeinput is fired only for user inputs, the name might not be good.

[17:56] E.g., if it's not fired for "undo", on the other hand, "input" is fired.

[17:56] <travis_> I know that some things like form auto-filling will put text into form fields. These should probably not fire beforeinput??

[17:56] this sounds strange...

[17:57] <travis_> Proposal? beforeinput should fire for all changes?

[17:58] No, I don't think so because if it's fired for Undo or something, it's difficult to cancel.

[17:59] <travis_> ...and cancellation is an important scenario, right? It's a new scenario, though, right?

[18:00] If it's not cancellable, I have no scenario of using beforeinput.

[18:00] (keypress is cancelable)

[18:01] <travis_> Ah, so not a new scenario, but a replacement for keypress.

[18:01] Yes, and how about for delete or backspace?

[18:02] "input" is fired for any changes but...

[18:02] <travis_> So, we want the "before" notice to be cancelable, and we want it to only apply to keyboard input?

[18:02] keyboard or IME? (perhaps, voice input or something is a part of IME)

[18:03] == cabanier [~[email protected]] has joined #webapps

[18:04] commands like paste, undo and redo shouldn't cause beforeinput, I think.

[18:05] That's all for now.

[18:05] <travis_> So, "input" is the catch-all for any changes (as it currently is), and beforeinput is the catch-all for all keyboard/IME input.

[18:06] I hope so.

[18:06] <travis_> OK. Thanks everyone for participating!

[18:07] <travis_> I think that next week we are back on track for our normal bi-weekly meetings again (with a phone bridge).

[18:07] <travis_> I will send out the reminders for that.