W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2009

Re: [whatwg] focus change inside keypress event handler

From: Michael A. Puls II <shadow2531@gmail.com>
Date: Fri, 30 Oct 2009 19:09:42 -0400
To: "Doug Schepers" <schepers@w3.org>, www-dom@w3.org
Cc: whatwg@whatwg.org
Message-ID: <op.u2mymgzq1ejg13@sandra-svwliu01>
On Fri, 30 Oct 2009 00:34:14 -0400, Doug Schepers <schepers@w3.org> wrote:

> Hi, Folks-
>
> Scott González wrote (on 10/29/09 11:03 AM):
>> On Thu, Oct 29, 2009 at 9:20 AM, Michael A. Puls II
>> <shadow2531@gmail.com <mailto:shadow2531@gmail.com>> wrote:
>>
>>     Safari and Firefox will allow focus() inside the handler to decide
>>     where the character gets inserted, but only with "keydown". With
>>     "keypress" (and textInput in webkit) in Firefox and Safari, it
>>     appears that the char was already inserted right after keydown, so a
>>     focus() change is already too late. Despite that though,
>>     preventDefault() still works in Firefox and Safari inside a
>>     "keypress" handler to prevent the char from being inserted. So, I'm
>>     not exactly sure what's they're doing behind the scenes.
>>
>>
>> DOM Level 3 Events says "The default action of the keypress event
>> depends upon the key and the context: if the key is associated with a
>> character, and if there currently focused element in the document can
>> receive text (such as a form input or an editable text block), the
>> default action is to dispatch a textInput event with the character as
>> the value of the TextEvent.data attribute"
>>
>> The default action of a keypress is not to insert a character in the
>> element that has focus, but to insert a character on the element that
>> represents the context of the keypress. In the given example, the
>> keypress's context is the first field, not the second.
>
> Correct.

So, you're saying that changing the focus() to another field inside the  
'keydown' handler (or keypress handler in the case of Opera and IE) MUST  
NOT change the insertion context (the field in this case that the text  
gets inserted into)?

If so, that would seem to contradict what browsers do when the focus  
changes inside  a 'keydown' handler and contradicts Opera and IE for focus  
changes inside a 'keypress' handler.

Not allowing that would break chase.com's SSI entry for example. (It uses  
3 fields and moves to the next field after you've entered 3 numbers, then  
2, then 4.

I've noticed lots of sites that change focus as you're typing to move the  
rest of the text to the next field. I'm not sure how many do the focus  
change inside a handler instead of after/before though.

-- 
Michael
Received on Friday, 30 October 2009 23:10:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:04 GMT