Re: textInput --> beforeInput

>
> Is this going to be just for text insertion, or (as you suggested) would it
> be fore any user-initiated modification of the DOM?
>
Sorry, you answered that. I'm not opposed to it being for any user-initiated
modification of the DOM, however there is the issue of what the value of
"data" should be (see my previous email).

--Jacob


On Fri, Aug 27, 2010 at 5:04 PM, Jacob Rossi <rossi@gatech.edu> wrote:

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