Re: textInput --> beforeInput

> The textInput event should be expanded to include all user-input that
> modifies the DOM. This would match the existing "input" event and make the
> event much more useful. It could then be a catchall event that happens
> before any user-modifications. Basically I'm proposing that:
>
> 1. We add every possible user-action to the list of InputModes (e.g. cut,
> paste, undo, redo, etc.).

Paste is already defined (DOM_INPUT_METHOD_PASTE). As for cut, it's
not so much the "input" of characters as it is the removal of such.
Undo/Redo are potential good adds too. Though, again you will run into
cases for both where you are really removing characters instead of
adding. Does the Backspace button cause a textInput (or beforeInput)
if it removes a character? If removing characters also causes
textInput events, then what is the value of data on the event object?
It could be an empty string, null, or the characters that are being
removed. In the case of a cut, it would be apparent that the event
will result in the removal of characters. However, undo/redo can both
be for adding or removing characters. So I would recommend it be an
empty string so as not be confusing whether characters are being
added/removed.

In general, I like where you're headed with this. I'll try and think
of other input methods.

>2. We rename textInput to beforeInput.

I don't particularly care. But since this event only applies to
character data I see no problem with it as named (textInput).

>3. We not fire this event for script operations (matches the existing
>"input" event, is easier to implement and meets all the use-cases that I can
>think of).

Sorry, which "input" event are you referring to.....textInput or
something else?  If it's significantly easier to implement this way, I
guess that's fine. I remember having a discussion about this once
before. But I can't seem to find any emails or minutes about it. So if
someone else knows where that's at or what was said, then it might be
useful. I believe we identified some use cases for it to fire when
script generates input.

One use case I can think is for user/browser scripts that might
auto-fill input content (forms, etc.). Such scripts would not have
functional parity with manual user input if the site is relying on
textInput for some reason.

>Nit: I don't much like "inputMode" as a name. Really it's the user-action
>that it's referring to. I'd rather see inputMode renamed to action, but I
>won't be too upset if we leave it as inputMode.

I don't like inputMode too much either. Personally, I think
inputMethod might be best since it matches the inputModeCodes
("DOM_INPUT_METHOD_........").

--Jacob

Received on Monday, 21 June 2010 01:46:15 UTC