Re: textInput --> beforeInput

On Mon, Jun 21, 2010 at 10:45 AM, Jacob Rossi <rossi@gatech.edu> wrote:

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


I suppose you would also want DOM_INPUT_METHOD_DRAG for the cases where
you're moving text.  This could get complicated if you're moving text within
the same input.  Should two textInput events be fired (one with DRAG and one
with DROP)?

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

Currently, WebKit doesn't fire textInput for backspace, but that seems like
a bug to me.  What is data in the case where HTML is being pasted into a
content editable region?  Is it the full HTML or just the text contents?
 I'm ok with data being an empty string in the case of text being removed,
but in that case, I'm not sure there's a lot of value to data in general.


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


Ojan is referring to the event fired by <input> tags, e.g., <input
oninput="oninput(event)">.

tony