W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2013

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

From: (wrong string) 河内 隆仁 <kochi@google.com>
Date: Tue, 3 Sep 2013 19:04:34 +0900
Message-ID: <CADP2=hr4q52ipTfdZeaBv6e_jiz0c-+MhNCyw_NiBqgK_ed9+A@mail.gmail.com>
To: Ojan Vafai <ojan@chromium.org>
Cc: (wrong string) marík (šоˆма€‡ик) <garykac@google.com>, Travis Leithead <travis.leithead@microsoft.com>, "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>, "www-dom@w3.org" <www-dom@w3.org>
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

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.

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
Received on Tuesday, 3 September 2013 10:05:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:03 UTC