Hi, Alexey-
This is indeed very valuable information. A few comments inline...
Alexey Proskuryakov wrote (on 4/3/08 5:12 AM):
- 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.
Default handlers should be defined by the host language (for example,
HTML or SVG). I don't think that SVG will actually define default
handlers for any keys, other than specialized zoom or pan keys (though
it's conceivable that the arrow keys might be overloaded for this);
HTML, however, has a lot of controls and expected behaviors for them.
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.
Yup. Again, that's out of scope for DOM3 Events, but it should be made
clear that a host language should define these default handlers, and how
to do it.
- 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.
Yes, we've already resolved that we will explicitly warn authors that
the OS and the browser may not pass all events through to the DOM/script
context.
- 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.
I think it would be worthwhile for us to consider
hotkeys/accesskeys/etc. in the WebApps context, whether it is specified
in DOM3 Events or not. Maciej put forward an interesting proposal in
WebAPI or HTML... I'll hunt it down.
- 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.
Ouch. Perhaps the emulation layer, if we mandate one, will simply have
to have some known flaws. We discussed making an informative appendix
with some similar known issues.
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 :)
Under the circumstances, that seems reasonable.
If both IE and Safari (at least) have the same charCode and keyCode
charts, publishing those as an informative list seems to have legacy value.
- 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.
Let's discuss this during the telcon.
Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI
