- From: Masayuki Nakano <masayuki@d-toybox.com>
- Date: Tue, 20 Aug 2013 14:25:21 +0900
- To: "Gary Kačmarčík (Кошмарчик)" <garykac@google.com>, Travis Leithead <travis.leithead@microsoft.com>
- CC: "wez@google.com" <wez@google.com>, "olli@pettay.fi" <olli@pettay.fi>, "hallvord@opera.com" <hallvord@opera.com>, "karlt@mozbugz.karlt.net" <karlt@mozbugz.karlt.net>, "kochi@google.com" <kochi@google.com>, "www-dom@w3.org" <www-dom@w3.org>
On 2013/08/20 10:08, Gary Kačmarčík (Кошмарчик) wrote: > (2) Desired order of beforeinput and compositionupdate events. > In the teleconf that I missed a few weeks back, there was consensus to > have beforeinput + compositionupdate + input. When I wrote the summary > doc, I was unaware of this and wrote compositionupdate + beforeinput + > input. We should review this and make sure we're all in agreement here. > This event ordering depends on whether the DOM is changed before or > after compositionupdate. Hmm, in my understanding, beforeinput isn't fired before compositionupdate for simpler spec. > (3) What event type is sent with beforeinput/input? > Previous discussions have assumed that input would send and Event, but > beforeinput needs (at least) a |data| attribute. > Should we create a new InputEvent type that is used by these events? > Pros: The spec would then naturally describe them at the same time > (under InputEvent). > Cons: Yet another event type. I think so. beforeinput should have: data: inputting text (or unmodified (except shift) text when it's not actually input text like Ctrl+C) inputtingText (?): true if the data is actually inputted. false if the data is unmodified value (pressing Ctrl key or something). shiftKey, ctrlKey, altKey, metaKey and getModifierState(): for replacing keypress event in some cases. But I'm not sure what's the best values for this during composition. > Is locale needed for beforeinput? > It has text... I don't think .locale should be discussed now... It has too difficult issues and so not important than current agenda items. > Is repeat needed for beforeinput? > keypress had a |repeat| attribute, but how useful was it on the keypress > We'll still have |repeat| on the keydown event. We would recommend that beforeinput is a alternative standard event of keypress event. Then, beforeinput must have all information of keypress event which will follow the event. If not, in some cases, keypress event would be used forever. This causes we'd fail to finish the keypress hell between browsers. > What is the |data| value for beforeinput when DEL is pressed? > Empty string? And if people want to trap DEL, they need to look at > keydown/keyup events? I don't think beforeinput should be fired for Del and Backspace. beforeinput should be fired only at adding text. So, I think that the data value of beforeinput never becomes empty. > In bug #22070: "And, it might be worthwhile to add "inputDevice" > attribute which indicates the beforeinput is caused by a key press or IME." > Is this still worth considering? What's the use case? If beforeinput is used for handling shortcut key, the events should be ignored during composition if beforeinput is also fired during composition. -- Masayuki Nakano <masayuki@d-toybox.com> Manager, Internationalization, Mozilla Japan.
Received on Tuesday, 20 August 2013 05:25:47 UTC