- From: Jacob Rossi <rossi@gatech.edu>
- Date: Wed, 15 Sep 2010 13:45:20 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Ojan Vafai <ojan@chromium.org>, Olli Pettay <Olli.Pettay@helsinki.fi>, Olli@pettay.fi, Doug Schepers <schepers@w3.org>, Jonas Sicking <jonas@sicking.cc>, Roland Steiner <rolandsteiner@google.com>, Tony Chang <tony@chromium.org>, www-dom@w3.org, morrita@google.com, danilatos@google.com
> 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