TextEvent.inputMethod is needed to discern the method of input used to triggered a textInput event.
Is there a specific use case for this? I think that this API is poorly designed, and would prefer that we don't implement it. For example, what should the inputMethod property be equal to when typing with Mac OS X U.S. keyboard layout? It sometimes works indistinguishably from IME (specifically, when using press-and-hold to type accented characters on Lion).
I think inputMethod is a poor property name as well. the name input method is normally referred to text input assisting software such as Microsoft IME, Kotoeri, and ATOK.
(In reply to comment #1) > Is there a specific use case for this? I don't really think anyone cares if something comes from a keyboard, but some of the other ones (paste, voice, handwriting) could make sense in a webapp. I agree that it is poorly designed though. Ideally, it would be a list of methods used to output the text (also dropping the IME method, since they're all IMEs anyways) instead of this. Given that, inputMethod is still sufficient enough right now for webapp dev, and could be changed in a later spec.
Should we implement inputMethod now then? I have no strong opinion about this. This comes from bug 60451, but it would be also possible to solve the event firing part of it without adding an inputMethod attribute to text events. In fact, speech input has already an onwebkitspeechchange event that also provides alternative result candidates with their confidence.
I think that we shouldn't implement this.
(In reply to comment #5) > I think that we shouldn't implement this. I would have agreed given the seemingly poor name and values, but now I realize that this is a part of DOM level 3: http://www.w3.org/TR/DOM-Level-3-Events/#events-TextEvent
Okay, I did some research on this and apparently neither Firefox nor Opera supports textinput event. Given that I see little to no benefit in implementing this property, which is really hard to implement correctly in WebKit.
(In reply to comment #7) > Okay, I did some research on this and apparently neither Firefox nor Opera supports textinput event. Given that I see little to no benefit in implementing this property, which is really hard to implement correctly in WebKit. The fact is that it's already there and working in Chromium. Try using addEventListener("textInput") with some <input type=text> element. However it looks like only the event itself is actually supported, not its inputMethod or locale attributes. Should we leave it as it is? Maybe add the event for the speech input case but ignore the inputMethod?
(In reply to comment #8) > The fact is that it's already there and working in Chromium. Try using addEventListener("textInput") with some <input type=text> element. We should consider dropping the support altogether given only Trident and WebKit support the event (I checked with Ehsan about Gecko's plan and he told me he doesn't know any plans to implement in Gecko), and there are alternatives such as input and beforeinput events. >However it looks like only the event itself is actually supported, not its inputMethod or locale attributes. Should we leave it as it is? Maybe add the event for the speech input case but ignore the inputMethod? That appears to be the plan to maintain the consistency although I'd argue that we should just kill the event.
Correction. There IS a Mozilla but to implement textinput event and someone from Mozilla Japan is interested in fixing this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=622245. So we may not be able to kill this event after all. But let's see what Mozilla does before implementing this property in WebKit.
I fully support killing textInput and replacing it with beforeInput if we find we can do so without causing a compat issues. Certainly we should not further extend textInput and instead focus on implementing beforeInput and making it meet all the use-cases. I feel less strongly about whether we should fire the event for speech input, but we don't need to implement inputMethod in order to do so.
Thank you for your comments. I think probably the best option now is to fire the event for consistence with what it's already landed, but not to add any inputMethod or additional information to the TextEvents until it's clear what to do about them. If anyone has other suggestions or reasons for not doing this please don't hesitate to share them.
If I am not mistaken, it got dropped: https://www.w3.org/Bugs/Public/show_bug.cgi?id=12958 TextEvent is not in spec. Should we create separate new bug to get rid of 'TextEvent'?
Yes This is probably irrelevant and should be closed.