Re: Some key event handling issues of interest

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

Received on Wednesday, 9 April 2008 18:23:29 UTC