Re: textInput --> beforeInput

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

Yes, I would say that would be the correct way to go about it (fire 2 events).

In general, it would be important to note though that the textInput
event for the DRAG would not be concurrent with drag event(s) as
specified in HTML5.  This is because the removal of the text as caused
by a DRAG does not occur until you DROP the text. Therefore, when
dragging text, no textInput events fire until you drop the text. At
that point, you would get two simultaneous textInput events:

textInput (inputMode == DOM_INPUT_METHOD_DRAG) on the source where the
text came from
textInput (inputMode == DOM_INPUT_METHOD_DROP) on the destination
where the text is going

As you pointed out, the targets of the two events could in fact be the
same if you are dragging text within the same input.

Another good question to ask, then, would be what happens if you
cancel one of these events? I think it's important not to confuse
these textInput events with the DragEvents as specified in HTML5 [1].
In other words, I would say this:

1. The default action of the first textInput is to remove the text
from the source. If cancelled, then the text remains. However, the
drop still occurs.
2. The default action of the second textInput is to insert the text
into the destination. If cancelled, then the text is not inserted.
However, this has no effect whatsoever on the source element.

So cancellation of one or both of the textInput events does not affect
the other. Similar rules would apply to cut/copy/paste and undo/redo.
This should not be used as a model for handling drag and drop.

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

If it's going to fire for cut and drag, then it should for Backspace too.

As for formatted text, the spec currently says only to fire textInput
if the paste (though it could just as well be a drop) results in the
"simple sequence of characters." I'm not sure I agree with that. It
could possibly be fired with just the text contents. Though again,
this shouldn't be used as a model for handling copy/paste. It's
purpose, as I see it, is for notification of the insertion (and
removal) of characters. So I'd hate for characters to be inserted as
the result of a drop or paste with HTML content yet no textInput event
be fired. We should change that, I think.

--Jacob

Received on Monday, 21 June 2010 21:59:45 UTC