- From: <bugzilla@jessica.w3.org>
- Date: Fri, 16 Mar 2012 20:58:26 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=12958 Travis Leithead [MSFT] <travil@microsoft.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #14 from Travis Leithead [MSFT] <travil@microsoft.com> 2012-03-16 20:58:23 UTC --- textinput (as currently spec'd) appears to be merely a drop-in replacement for "keypress": * It happens after the relevant character was added * It happens only for new input (not deletions, etc., which "input" covers today) Regarding changing textinput to "beforeinput" or similar: this is non-trivial and would impact the legacy event order with keypress as I tested in various UAs. Additionally, (with my implementor hat on) this requires substantial work to the input pipeline in the browser in order to fire it before and with the implied ability for it to cancel the input. In order to resolve this bug, I think there are several options: 1. Leave the spec as-is. As has been noted, textinput in its current incarnation is a sub-set of the "input" event in all scenarios where it matters (input/textarea/contenteditable). This reduces churn in this spec, but doesn't really provide an value over "input" except in the TextInput interface's member info. 2. Rename the event to "input" as noted in the title. This would require that this spec harmonize with the definition of "input" in HTML5, that allows "input" to be fired on any relevant change to the "editing control" (insertions or deletions). It requires the somewhat tricky definition of an "editing control" (Aryeh could help me with that), requires me to re-think (and possibly re-name) what's on the TextEvent interface (e.g., how does "data" work when you've just deleted something?), and requires HTML5 to update to throwing the TextEvent (or whatever it's renamed to) to match. 3. Delete the TextEvent and related event type. Keypress will remain spec'd for legacy reasons, but won't have a default action of textinput. We leave "input" defined in HTML5 as-is, and let the editing spec define a "beforeinput" if they want it. My order of preference at this point is #1 (easiest for me!) > #3 > #2. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Friday, 16 March 2012 20:58:29 UTC