Re: textInput --> beforeInput

On 09/15/2010 11:45 PM, Jacob Rossi wrote:
>> On Wed, 15 Sep 2010 21:19:43 +0200, Olli Pettay<Olli.Pettay@helsinki.fi>
>> wrote:
>>>
>>> So I don't understand at least copy nor drag. Those aren't "input", they
>>> don't generate anything to the DOM (or anonymous DOM).
>>> So whether the event name is beforeInput or textInput, those cases
>>> just don't belong to this event.
>
> I believe some are considering text removal as "input," which could
> occur from a cut (but certainly not copy) or drag.

Oops, right. Drag is sort of ok, but copy certainly isn't.



While in previous
> emails I have outlined how I think cut/drag should behave if they were
> to be considered input methods, I too would prefer them not be
> included with this event. I think it should soley be fired as a
> catch-all for user text input (keyboard, IME, paste, etc).  Otherwise,
> developers will find themselves filtering by inputmethod all the time
> because all they really want is to catch all the possible ways to
> insert text.
>
>>>
>>> IMO, textInput sounds better for what is meant for; to have an event
>>> which is dispatched before entering some data.
>
> I like having "text" as a part of the name since it indicates what
> type of input we're referring to (as opposed to say, mouse input).
> Also, if it remains that markup is not included in .data  (which I
> prefer), then textInput is even more accurate of a name seeing as the
> contents are just text.
>
> However, I'd like it to be all lowercase: textinput. That way the only
> ones in D3E that are CamelCase are the deprecated mutation events and
> DOMActivate.
>
> On Wed, Sep 15, 2010 at 12:26 PM, Anne van Kesteren<annevk@opera.com>  wrote:
>> beforeinput (all lowercase) would be more consistent with other event
>> naming. E.g. beforeunload, beforeprint. I think that would be better.
>
> Well for one, beforeunload and beforeprint are not in D3E.  But in
> their defense, they represent events that ocur *before* an action has
> occured, i.e. before the document is unloaded and before the printing
> of the document occurs.  On the contrary, textinput occurs as a
> notification *after* the user input action has occured (via whatever
> inputmethod).  At least that is, I define the "input" to be when the
> user performs the action that then causes text insertion.
>
> I'd like the default action of textinput in the spec to say it is the
> insertion of the inputted characters.  So it works like this:
>
> 1. User inputs characters.
> 2. textinput is fired as a result *after* the input has occured.
> 3. Provided the event is not canceled, the default action of inserting
> the characters occurs.
>
> --Jacob
>

Received on Wednesday, 15 September 2010 20:49:19 UTC