Re: textInput --> beforeInput

> 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.  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:46:15 UTC