[D3E] Sort out the beforeinput event's point

Hi, sorry for the delay to post this email.

At the previous D3E telecon, I feel that there are some mismatch points 
about beforeinput. So, let's sort out the points.

I believe that beforeinput event is alternative new event of legacy 
keypress event.

In my understanding, it's difficult to standardize the behavior of 
keypress event due to current behavior differences between browsers. 
This is the reason why we want to define beforeinput.

Additionally, this name is useful for notifications of other native 
input event like IME. In other words, I was thinking that beforeinput is 
an abstract event of native text input.

Therefore, I was thinking that:

1: beforeinput is fired only when native text input event occurs.

2: beforeinput is fired after all keypress event for allowing web 
developers to replace keypress event handler with beforeinput event handler.

3: beforeinput is fired on focused element. If there is no focused 
element, fired on the root element. This is same behavior as keypress event.

However, there are some objections:

For 1: beforeinput should be fired for editing command too. E.g., 
"paste", "undo" and "redo".

This objection sounds like that the beforeinput event is NOT a 
notification of native text input. This is really fired from editable 
elements same as input event.

If so, it's difficult to make beforeinput cancellable. E.g., if the text 
editing is caused from an event handler, beforeinput event must be fired 
synchronously for canceling check of the text edit. This means that, 
beforeinput text input handler is pushed to the stack. So, web 
application attacker can nest beforeinput event in stack. This may cause 
stack overflow if script engine doesn't protect from this.

For 2: beforeinput should be fired only when the event editing text. 
I.e., it should be pair with input event.

This objection clearly indicates that beforeinput isn't available for 
alternative of keypress event. For example, web developers cannot 
implement their own shortcut key like Ctrl-C with beforeinput event.

If beforeinput isn't available for an alternative of keypress event, web 
developers perhaps keep to use legacy keypress event in some cases. So, 
beforeinput cannot help such web developers from "keypress hell".

For 3: beforeinput should be fired only on focused editable element or 
focused element which has inputmode attribute.

This objection clearly indicates that beforeinput isn't available for 
alternative of keypress event on non-editable element. My objection for 
this objection is same as 2.

I believe that if beforeinput should behave like the objections, 
beforeinput is NOT an alternative of keypress event. Then, we should 
standardize keypress event too.

Masayuki Nakano <masayuki@d-toybox.com>
Manager, Internationalization, Mozilla Japan.

Received on Friday, 30 August 2013 07:40:18 UTC