Re: [whatwg] focus change inside keypress event handler

On Wed, Oct 28, 2009 at 2:43 AM, Michael A. Puls II
<shadow2531@gmail.com<shadow2531@gmail.com?Subject=Re%3A%20%5Bwhatwg%5D%20focus%20change%20inside%20keypress%20event%20handler&In-Reply-To=%253Ca9699fd20910280201h3c7990a1s7cb9a7e5dc2c60c1%40mail.gmail.com%253E&References=%253Ca9699fd20910280201h3c7990a1s7cb9a7e5dc2c60c1%40mail.gmail.com%253E>>
wrote:
> (CCing DOM list just in case anyone there has any comments)
>
> With:
>
> <p><input onkeypress="this.nextSibling.focus()"><input></p>
>
> , if you type a character in the first field, should the character be
> entered in the second field or the first?
>
> In Firefox and Safari, it's the first field. In IE and Opera, it's the
> second.
[...]
> I do think FF and Safari's way makes more sense and I think most will
agree.

The keypress event is similar to textInput.  Their intent is to indicate
when character data has been entered. textInput is more powerful and
captures character input from a number of input sources (keyboard, IME,
voice, etc). In both cases, I would consider the default action to be the
insertion of the characters into the DOM. For *most* events, the default
action isn't performed until after event dispatch. Accordingly, I would
expect that calling focus() during the dispatch of the keypress (or
textInput) event would result in moving the cursor prior to the character
data being inserted (because events are synchronous). Thus I think it makes
most sense for the character to appear in the second input box.

Another reason why this should be the case is what happens when you cancel
the default action (call preventDefault() ). Canceling a textInput or
keypress event should prevent the character from being inserted. So that's
further evidence that the character insertion should happen after dispatch
of the event.

--Jacob