6-Aug-2013

<kochi_home> Travis should have scheduled DOM L3 telcon Aug 6

<kochi_home> http://www.w3.org/2008/webapps/wiki/30-July-2013

<kochi_home> > <Travis> Let's try for Aug. 6th!

<garykac> Indeed. I saw an email that he got it scheduled for now.

<garykac> Let me look it up.

<garykac> Arthur said that we now have this meeting scheduled weekly so that we can us it during odd weeks.

<garykac> Kochi asks: What should preventDefault do when set for compositionevent?

<kochi_home> bug 18030

<kochi_home> no

<kochi_home> 18931

<garykac> And suggests that it setting preventDefault to true should result in the DOM not being updated.

<kochi_home> www.w3.org/Bugs/Public/show_bug.cgi?id=18931

<masayuki> It seems that we don't need beforeinput for compositionupdate.

<garykac> Yes, if beforeinput cannot be canceled, then it doesn't seem to do anything useful.

<garykac> But that means that we would have input events firing with out having a beforeinput event.

<garykac> So we wouldn't be able to write the spec as "input events are always preceded by beforeinput events"

<kochi_home> For IME API's perspective, preventDefault()'ing beforinput event

<masayuki> I think that it's not problem. beforeinput and input are really different event even their names are smililar.

<garykac> I'd rather get rid of input events during composition, but it sounds like the consensus is that we need to keep them around.

<kochi_home> can give Javascript chance to draw composition text itself and modify .value

<garykac> kochi: Ah. So calling preventDefault wouldn't cancel the compositionupdate, it would just say that the client is going to update the DOM itself.

<kochi_home> yes, it is my idea.

<masayuki> kochi_home: Isn't JS IME handles only key event? I mean that shouldn't be native IME disabled for JS IME?

<masayuki> Sounds odd to me that JS IME works with native IME.

<kochi_home> hmm, yes, if JS IME comes into place,

<kochi_home> mm

<kochi_home> masayuki: I think I now understand.

<kochi_home> at this point with IME API you can't provide IME API, but you can talk to native system IME

<kochi_home> So what I mentioned above is talking about interacting system IME by Javascript

<masayuki> I think that there should be an API to disable native IME which can be used by JS IME.

<masayuki> kochi_home: like Google suggest?

<kochi_home> masayuki: like google docs, which wants to draw composition text itself

<kochi_home> without using a hack to listen to composition update in a hidden textarea

<masayuki> kochi_home: I understand.

<kochi_home> in that case, if DOM is modified before compositionupdate event, drawing composition text is too late

<kochi_home> but if Javascript code can trap beforeInput, it would be a perfect timing to do that

<kochi_home> masayuki: (about having an API to disable native IME to switch JS IME - yes, we should have one once we provide APIs to implement IME in Javascript)

<garykac> So, you're suggesting that beforeinput during composition would allow preventDefault (to skip updating the DOM), but not be cancelable? Not updating the DOM could be considered canceling, couldn't it? What's the advantage of using preventDefault for this instead of cencel?

<kochi_home> my gut feeling is that canceling a beforInput event for composition udpate mean cancellation of the composition session

<kochi_home> while preventDefault is just canceling what browsers would do when it get updates from IME

<kochi_home> but if the behavior for preventDefault() is different for key events and composition events, spec would be very messy. That is my concern.

<garykac> But we could define "cancel" to mean don't update the DOM, but stay in the IME. Do we need (is it possible) to cancel the IME from within JS handler?

<garykac> I'll have to review how preventDefault is spec'ed for key events...

<kochi_home> okay, it is another option (define "cancel" to mean don't update the DOM)

<masayuki> kochi_home: Even if a call of peventDefault() of beforeinput prevents to update composition string, doesn't modifying editor content cause committing the composition on most browsers?

<kochi_home> yes, currently most browsers cancel composition if .value is modified...

<masayuki> kochi_home: So, I'm not sure if your idea is actually useful...

<kochi_home> I think that javascript can draw composition string is a useful for some application, but how to realize it, which events to use is a difficult question.

<masayuki> How about to make compositionupdate cancelable for such purpose?

<garykac> If cancelable just means that we don't update the DOM (rather than canceling the IME), then we could have beforeinput do that.

<kochi_home> so when compositionupdate is cancelled, DOM is already modified but screen is not updated?

<garykac> However, I'm not sure if it's valuable to have compositionupdate + beforeinput.

<kochi_home> (I assume bug 18931 is resolved and compositionupdate is sent after DOM modification)

<garykac> compositionupdate could be defined to not have the DOM already modified. That's consistent with Chrome/FF already.

<masayuki> kochi_home: If compositionupdate is cancelable, dispatching compositionupdate before DOM modification is good timing.

<kochi_home> yeah, if IE12+ can follow the behavior ... :)

<garykac> That sounds reasonable to me. It also means that we wouldn't need beforeinput in that case.

<masayuki> garykac: yes

<garykac> While it would be nice to have beforeinput for consistency, it's also nice to have fewer events firing.

<kochi_home> if it is more consistent with beforeInput for non-composition event, that sounds a good idea

<garykac> OK. I'll update the document to organize it into the various specific issues we've been discussing.

<kochi_home> garykac: thanks

<garykac> We won't be meeting next week (since some people are not available), but we can still discuss this via the document.

<garykac> I'll send out another email once I've incorporated all the feedback from everyone.

<kochi_home> garykac: sure

<garykac> It feels like we're making some progress here...

<kochi_home> thanks garykac, masayuki!

<masayuki> Thank you.

<garykac> When is the next tie everyone is available?

<garykac> Next week doesn't work, but what about the week after that?

<masayuki> I'm available both 20 and 27.

<kochi_home> I'm available for Aug 13, 20, 27,

<garykac> OK. Let's meetup again on the 20th.

<garykac> We already have Zakim setup for us each week at this time.

<kochi_home> yup, let's keep Travis updated.

<garykac> Indeed.

<garykac> I'm going to head out now. Thank you everyone!

<kochi_home> Thanks!

<masayuki> Thank you!