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
