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

I don't think beforeinput has to be always interchangeable with keypress in
every aspect.
I believe in general it is meant to be a better alternative to keypress
event.

For the third objection, I wrote up a document a while ago about delivering
composition events to
non-editable element, for use cases like DOM-based editing widgets.
https://docs.google.com/a/chromium.org/document/d/1iKd4zhJaoZN5UMeMjWDjr-x5FtnUC5d1sYd4RqAbjGo/edit#heading=h.il4xki2xfv0e

It's still not clear using inputmode is the way to go, but I hope the
demand for objection 3 is understandable
and using the inputmode could be a part of the solution.



On Sat, Aug 31, 2013 at 2:42 AM, Ojan Vafai <ojan@chromium.org> wrote:

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


-- 
Takayoshi Kochi