On Fri, 30 Oct 2009 00:34:14 -0400, Doug Schepers <[email protected]> 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
<[email protected] <mailto:[email protected]>> 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
