Re: textInput --> beforeInput

Sounds good to me.  I would also suggest changing inputMode to inputMethod
as mentioned in the thread (looks like Doug has already added this to the
spec).

I also agree on what you said about cancelation. It should, whenever
possible, cancel the associated action (your cited example was if a "cut"
was cancelled, then the text should not be added to the clipboard nor should
it the original text be removed from the DOM).

Is this going to be just for text insertion, or (as you suggested) would it
be fore any user-initiated modification of the DOM? If the latter, what did
we decide (or did we decide) would be the value of "data" if this event were
to modifications/removal of text (as opposed to pure insertions)? Currently
the spec states: "This attribute cannot be null or contain the empty
string<https://mail.google.com/mail/html/compose/static_files/blank_quirks.html#glossary-empty-string>
."

--Jacob


On Fri, Aug 27, 2010 at 4:34 PM, Ojan Vafai <ojan@chromium.org> wrote:

> Is there consensus on the following changes?
>
> 1. Rename textInput to beforeInput.
> 2. Fire beforeInput for any user-action that modifies the DOM, not just
> actions that cause text to get inserted.
>
> Looking at the history of this thread, it seems that everyone who has
> commented agrees with making these changes.
>
> Ojan
>
> On Fri, Jul 23, 2010 at 2:44 PM, Ojan Vafai <ojan@chromium.org> wrote:
>
>>   And can you please tell me where the "input" event is defined
>>> officially? I can only find some very rough description in html5 draft.
>>>
>>
>> http://www.whatwg.org/specs/web-apps/current-work/#event-input-input
>>
>> On Mon, Jun 21, 2010 at 3:24 PM, James Su <suzhe@google.com> wrote:
>>
>>> According to the current DOM Level 3 Event Specification, the textInput
>>> event is only for inserting text, deleting text is not covered. And IMHO,
>>> using the name 'xxxInput' for deleting action is confusing. Can we have a
>>> better name for this purpose? For example "beforeTextChange"?
>>>
>>
>> I'm suggesting that we change the DOM 3 spec so that the
>> textInput/beforeInput event matches the HTML5 input event, which is already
>> widely implemented. Given that, keeping "input" in the name makes sense.
>>
>>
>>    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).
>>>>
>>> I'm thinking about a possible use case: Javascript based input method,
>>> such as Google transliteration service. Such kind of input methods usually
>>> can be used on any web pages as bookmarklets. They may intercept keyboard
>>> events and fake text input events.
>>>
>>
>>
>>> 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.
>>>
>>
>> I don't feel strongly about taking this out of the spec, but I don't
>> expect WebKit would implement this. If this were really supposed to cover
>> every script operation that might modify the (text)contents of the subtree,
>> then it becomes considerably more complicated and likely more expensive. For
>> example, does it fire for every appendChild/removeChild call? If not, what
>> subset of script operations does it fire for? I'd be OK with saying that it
>> fires just for execCommands, e.g. execCommand('insertText', false, "some
>> text").
>>
>>
>>  >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_........").
>>
>>
>> inputMethod sounds fine to me.
>>
>>
>> On Mon, Jun 21, 2010 at 2:58 PM, Jacob Rossi <rossi@gatech.edu> wrote:
>>
>>  > 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).
>>>
>>
>> Agreed.
>>
>>
>>
>>>  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.
>>>
>>
>> We should stop having this even be about text insertion. It should be
>> about any user-initiated modification to the DOM, as the HTML5 input event
>> is. As such, the data property only makes sense for the cases where we are
>> doing plain text insertion. For those cases, it should be the text being
>> inserted. Specifically, it would be the empty string unless the input method
>> is one of the following:
>> DOM_INPUT_METHOD_KEYBOARD
>> DOM_INPUT_METHOD_IME
>> DOM_INPUT_METHOD_HANDWRITING
>> DOM_INPUT_METHOD_VOICE
>> DOM_INPUT_METHOD_MULTIMODAL
>>
>>
>>     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.
>>>>
>>>
>>> I guess, if the drag'n'drop operation does in fact only copy the text
>>> rather than move it, there would be no DOM_INPUT_METHOD_DRAG textInput event
>>> (?).
>>>
>>> Also, what is the difference to the source how a piece of text is
>>> removed? IOW, wouldn't a single DOM_INPUT_METHOD_DELETE suffice for all
>>> operations that remove text (delete, cut, drag,...)?
>>>
>>
>> As I said above, I don't think having this event ties to the text
>> insertion makes sense. Canceling the event should cancel the associated
>> action. That makes this event much more useful. For example, lets say the
>> input event for a "cut" was cancelled. The text would remain, but also get
>> added to the clipboard? I don't see a use-case for that. If it's going to
>> be cancelable, which I think it should be, it should cancel the user-action
>> entirely.
>>
>> Ojan
>>
>
>