- From: Doug Schepers <schepers@w3.org>
- Date: Fri, 30 Oct 2009 00:34:14 -0400
- To: www-dom@w3.org
- CC: whatwg@whatwg.org
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. > I agree though > that the documentation could be clearer about this as it's not > explicitly stated. Yes, more clarification for focus and for key events is in the works for DOM3 Events... this thread has a bunch of great data and questions, thank you. I expect that HTML5 will probably also say something about this. Regards- -Doug
Received on Friday, 30 October 2009 04:34:25 UTC