Re: Some key event handling issues of interest

Specifying default handling is important, sure.
Some default handling is defined in HTML5/WebForms2 and that is perhaps
the right place for the rest of the default handling issues.

One important question is that what is the target for DOM Level 3
Events? Is it only for browsers? If yes, then defining default handling
in it makes lots of sense. But I'm not at all sure the browsers are the 
only ones to implement DOM 3 Events.

This is something to remember also when specifying for example
mousewheel handling (the latest proposal isn't browser-specific at all, 
IMO) and key event flow/handling.

About key event flow:
I think if or when defining key event flow, it must be made clear that 
event handlers (for example in web page or in browser chrome) may move
control out from the element, which means that event flow stops.



-Olli

Alexey Proskuryakov wrote:
> 
> As promised, here are some issues of interest that we had under 
> consideration when reworking WebKit keyboard event handling.
> 
> - It is important to perform default handling of events at well-defined 
> moments. E.g. having Tab perform its work of switching from one form 
> control to other in keypress default handler instead of keydown one was 
> causing problems with sites filtering keystrokes (e.g. 
> <http://bugs.webkit.org/show_bug.cgi?id=13916>).
> 
> - Default handlers are different for different elements. E.g. a space 
> bar results in a space inserted from keypress default handler in an 
> editable area; a button highlighted from keydown and a click event 
> dispatched from keyup, a pop-up button menu displayed from keypress, or 
> the page being scrolled down from a top-level keypress handler if the 
> event bubbled without having been handled otherwise.
> 
> Sometimes, these differences are arbitrary (e.g. there is no technical 
> reason for a pop-up button to necessarily display its menu from 
> keypress, not keydown), but they are important for compatibility.
> 
> Clearly, this is mostly an issue with highly overloaded keys, such as 
> Space, Enter, Tab, Backspace, or arrow keys.
> 
> - Interaction of DOM and browser chrome has to be considered. Keyboard 
> shortcuts (such as Ctrl+F or Alt+F4 on Windows) are handled after DOM 
> event dispatch, and some of them can be prevented, but not all.
> 
> Similarly, the browser chrome can perform an action that disrupts normal 
> event flow. E.g., Ctrl+F moves focus to a search window, and thus a 
> keydown event is not followed with a keyup one.
> 
> - Access keys are handled after keydown event dispatch, but they cannot 
> be prevented. This behavior has been one of the most problematic parts 
> for us because of a conflict with platform-supplied editing shortcuts on 
> Mac OS X (such as Ctrl+A == move to beginning of line). I believe some 
> other vendors have considered using another modifier combination for 
> access keys (e.g. Ctrl+Shift), perhaps we should do the same.
> 
> - On Windows, the underlying platform provides two events for keystrokes 
> (plus variations), one for physical key (WM_KEYDOWN == keydown), and 
> another for a character that it corresponds to (WM_CHAR == keypress). It 
> is hard, or maybe even impossible, to second-guess which event comes 
> when, because there are cases where they occur almost independently.
> 
> Here is an example, which I hope demonstrates the issue well, despite 
> being an edge case from user point of view. On German keyboards, there 
> is a dead key for circumflex (^), which modifies the results of the next 
> keystroke. If it is pressed twice in succession, the sequence of events 
> is: keydown, keyup, keydown, keypress, keypress, keyup. In other words, 
> the first keystroke has no visible results, and "^^" is inserted on the 
> second keystroke.
> 
> Mac OS X has a single event with both physical and processed key 
> information. We have found it practical to emulate Windows behavior on 
> the Mac, as there was no need to magically gather information from 
> separate events.
> 
> So, we have removed physical key information (keyIdentifier, 
> keyLocation) from keypress events. For compatibility, they still have 
> keyCode, but it is equal to charCode. Since keypress has not been 
> previously defined in DOM3 Events, either behavior is compliant :)
> 
> - Preventing default handling of keydown has no effect on IME input; 
> keypress is not dispatched. Also, keyCode is set to 229 (VK_PROCESSKEY) 
> in the keydown event. This was done just to provide IE compatibility, I 
> do not have any other support for this rather counter-intuitive behavior.
> 
> - WBR, Alexey Proskuryakov
> 
> 
>

Received on Wednesday, 9 April 2008 12:03:31 UTC