Re: textInput --> beforeInput

On Thu, Sep 16, 2010 at 6:48 AM, Olli Pettay <Olli.Pettay@helsinki.fi>
 wrote:

> On 09/15/2010 11:45 PM, Jacob Rossi wrote:
>
>>  On Wed, 15 Sep 2010 21:19:43 +0200, Olli Pettay<Olli.Pettay@helsinki.fi>
>>> wrote:
>>>
>>>> So I don't understand at least copy nor drag. Those aren't "input", they
>>>> don't generate anything to the DOM (or anonymous DOM).
>>>> So whether the event name is beforeInput or textInput, those cases
>>>> just don't belong to this event.
>>>>
>>>
>> I believe some are considering text removal as "input," which could
>> occur from a cut (but certainly not copy) or drag.
>>
>
> Oops, right. Drag is sort of ok, but copy certainly isn't.
>

Ugh, sorry, I didn't mean to include copy in that list. There should only be
beforeInput/textInput events for the ones that modify the DOM.

On Thu, Sep 16, 2010 at 6:45 AM, Jacob Rossi <rossi@gatech.edu> wrote:

> I think it should soley be fired as a
> catch-all for user text input (keyboard, IME, paste, etc).  Otherwise,
> developers will find themselves filtering by inputmethod all the time
> because all they really want is to catch all the possible ways to
> insert text.


This is assuming that the common case will be developers wanting to check
for text input. I don't actually think it is the common case. More
importantly, even if it were the common case, filtering for text input is a
one-liner (i.e. just check event.data != ''), but there is no way to get
from textInput to the more generic beforeInput.

I like having "text" as a part of the name since it indicates what
> type of input we're referring to (as opposed to say, mouse input).
> Also, if it remains that markup is not included in .data  (which I
> prefer), then textInput is even more accurate of a name seeing as the
> contents are just text.
>

The proposal is for this event to fire for any user-inserted content, at
which point, it's possible that this event would fire without text getting
inserted (e.g. pasting in an image). The current input event does not have
any confusion with other types of input. Developers seem to understand that
it refers to user-inserted content.


> 1. User inputs characters.
> 2. textinput is fired as a result *after* the input has occured.
> 3. Provided the event is not canceled, the default action of inserting
> the characters occurs.
>

I don't really understand what it means for the textInput to fire after the
input as occurred but before the inserting of the character occurs. Isn't
the inserting of the character exactly what the "input" is? Let me restate
the steps and see if we agree:
1. User inputs a character (e.g. types a key)
2. Fire the event
3. If the event is not cancelled, modify the DOM appropriately.

On Thu, Sep 16, 2010 at 4:55 PM, Anne van Kesteren <annevk@opera.com> wrote:

> On Wed, 15 Sep 2010 22:45:20 +0200, Jacob Rossi <rossi@gatech.edu> wrote:
>
>> On Wed, Sep 15, 2010 at 12:26 PM, Anne van Kesteren <annevk@opera.com>
>> wrote:
>>
>>> beforeinput (all lowercase) would be more consistent with other event
>>> naming. E.g. beforeunload, beforeprint. I think that would be better.
>>>
>>
>> Well for one, beforeunload and beforeprint are not in D3E.
>>
>
> That should not matter one bit. We should always consider the platform
> holistically.
>
>  But in
>> their defense, they represent events that ocur *before* an action has
>> occured, i.e. before the document is unloaded and before the printing
>> of the document occurs.  On the contrary, textinput occurs as a
>> notification *after* the user input action has occured (via whatever
>> inputmethod).  At least that is, I define the "input" to be when the
>> user performs the action that then causes text insertion.
>>
>
> The input event is dispatched after the text is inserted. Logically the
> beforeinput event would be dispatched before the text is inserted. I do not
> think we should discuss beforeinput (or textinput) without also considering
> how input behaves.
>

This is the key point I think. The input event already exists and is widely
deployed. The beforeInput event is a natural analog to it. Doing something
slightly different for the input event that fires before complicates the
platform without benefit.

Also, beforeInput is more general than textInput and meets significant
use-cases that textInput does not. It does not make sense to include both
events because beforeInput is a superset of textInput
and mimicking textInput from the beforeInput event is straightforward.

I still don't understand what the drawbacks are to replacing textInput with
beforeInput:
-beforeInput has no meaningful performance impact compared to textInput
-beforeInput is likely easier to implement
-beforeInput meets more use-cases
-beforeInput does not harm developers who only care about text insertion
because it's a simple if-statement to filter them out
-beforeInput is not much more complicated to spec than textInput

Ojan