This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
PORT: ISSUE-183: (This bug will be used to track this LC comment.) http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-compositionstart DOM3 Events Spec defines that compositionstart is cancelable. But it doesn't make sense for IME at least. UA doesn't know which key event causes starting composition. It is decided by IME. Current UAs dispatch compositionstart when IME starts composition actually. Therefore, "This event must be dispatched immediately before a text composition system is launched", this definition doesn't match current implementations. And also the composition has started already at that time. Therefore, "If this event is canceled, the text composition system must not be launched.", this explanation is impossible behavior. I'm not sure for other input methods. I think that the spec should document the IME case at least.
I had some help, and tested the Japanese IME on Microsoft Windows 7 machine running IE9 (which supports these composition events as speced). The IME application will be running and enabled down in the notifiation area. If I do nothing with the composition events as they fire, my first keystroke in an edit area will start a composition (underlining the text as it's not yet been fully composed). When I cancel the compositionstart event, the behavior I see is that no text is entered into the edit control when I type. The compositionend event will fire immediately after the composition start signalling that the composition was terminated. This behavior seems in line with the spec, so I'm not sure that what the spec says is impossible to implement. However, it's very possible that I have some bad terminology in the spec. So, without changing the cancelable nature of compositionstart, how would you suggest this be better phrased?
It's not canceling *launching* composition. The composition has been actually started and IE canceled the *started* composition. So, even if you cancel the composition, it cannot cause alternative keypress event for the pressed key. And this behavior can be only on some platforms which can discards the composition string. E.g., GTK doesn't have such APIs in its IM module. > However, it's very possible that I have some bad terminology in the spec. So, > without changing the cancelable nature of compositionstart, how would you > suggest this be better phrased? I think that spec should say "it depends on the platform or IME whether it's cancelable by calling preventDefault() of compositionstart." at least. However, I believe such difference between platforms must not be good thing for Web application developers because most of them must not familiar with every platform's APIs. Therefore, it *might* be better if it's impossible to cancel composition (only when it's caused IME) on all browsers. Or it might be better if there is an API in CompositionEvent for canceling the composition. E.g., "bool CompositionEvent.cancelComposition();". Then, we developers can see whether it succeeded or not.
To primarily address this bug, I will be changing the "must" requirement to a "should" implying that wherever possible, an implementation *should* allow the composition session to be cancelable; however, if an implementation can't for legitimate reasons (like not having the API to do so), then it's OK. In addition, for both our sakes, I'll be updating the spec to get rid of the "launching" text, and be more specific in describing the composition process from compositionstart to compositionend as a "composition session" that is maintained by the "text composition system". This will include minor updates throughout section 5.2.7.1.
Updated text has been added to the spec. Please review: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html?rev=1.217#events-composition-event-order
Looks OK. Thank you.