Re: [D3E] Sort out the beforeinput event's point

I agree that beforeinput should not be intended as a replacement for
keypress. Also, I agree that the spec needs to cover at least the existing
keypress event since there's too much content that depends on it for
browsers to be able to drop it. I'm not convinced we need to go farther and
add new features (e.g. key or code properties).

What are the use-cases for keypress that are not already met by keydown?


On Fri, Aug 30, 2013 at 12:39 AM, Masayuki Nakano <masayuki@d-toybox.com>wrote:

> 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.
>
>