Re: specification of "legacy" key events

* Hallvord R. M. Steen wrote:
>I've never really written English specification prose before (though I've  
>been an avid reader of W3C TRs) so please give this stuff a critical but  
>patient review ;-)

I don't think it is useful to discuss specification prose if it's
unclear what is to be specified, and what the requirements are. I
am only familiar with how key events function in the Win32 API, I
will just point out some differences. This should be the same as
the differences to Internet Explorer running on Windows since it
essentially just passes the events along as far as I understand it.

>	* If the key does not cause text input and is not the Escape key (i.e. if  
>the key is not is an alphanumerical key, a punctuation key, a repeated  
>press of a dead key or the Escape key), terminate this algorithm.

I may be misparsing this, but Escape key occurs twice, and I am not sure
what the text in the parens actually refers to (what is a key that ge-
nerates my name, or a combining character? those do not fall in any of
the items you list, yet they do generate text); I would also suggest to
remove some of the negations here.

>	* Set event meta key properties (shiftKey, ctrlKey, altKey, metaKey)  
>depending on what meta keys are pressed, if any

This should not be part of this, or you have to complete it and say,
among other things, to set the .view attribute.

>	* For backwards compatibility reasons the character code property has two  
>different names. Define charCode and keyCode, set both to the decimal  
>value of the unicode reference number of the corresponding character.

See below.

>	* Fire the event. If it was not cancelled with event.preventDefault()  
>proceed to fire a textInput event.
>
>	* If the same keystroke inserts several characters, fire one keypress  
>event for each
>
>	* If the key is held down, repeatedly fire one keydown event and one or  
>more keypress events at a rate determined by the system's repeat key  
>interval setting

I think the order here is off, and this is easy to misread. For example,
if the key generates multiple characters, do you send textInput only for
the first character, or one for each character, or one for all chars?

Further, some keys may generate multiple keydown events, for example,
the AltGr key on my keyboard will generate sequences of CTRL and Menu
keydown events; also, you may hold some keys down without any repetition
(e.g., hold a, additionally hold shift, release shift; you are holding
the a key but don't get events for that).

>TODO#1: note that IE does NOT take the upper-case value of certain  
>non-English character (for example ø/Ø on Norwegian keyboards). I believe  
>doing so makes the model cleaner and is unlikely to cause compatibility  
>problems - this needs investigation though. Here we also probably need to  
>specify some specific algorithm for upper/lower-casing characters?

If you use a cyrillic keyboard layout, you may not have any "english"
characters on it, but all the cyrillic keys specify the virtual key
codes in their keyboard events. So a U+0439 key may generate the same
code as a 'q' key. With your proposal, pretty much all the letter keys
would generate different codes. That seems a compatibility issue to me.

Also note that for keypress, Windows, and I would expect other systems
that use a UTF-16 variant internally, you get pairs of events specifying
surrogate codes points, rather than the unicode scalar value for non-BMP
characters.

>TODO#2: Step 4 of this algorithm is incomplete, probably needs to specify  
>how to get a virtual key from system? The issue step 4 is trying to solve  
>is: If a given key, say the I key is mapped to something else, say  
>"Hiragana I" keydown/keyup will still have the key code of an upper-case I  
>in reference implementations but not according to this algorithm without  
>some magic in step 4. Hence we need to fall back to reading virtual key  
>codes from the system in step 4, but how to do this exactly is  
>underspecified and will probably vary between operating systems.

It seems to me, at least in the cyrillic case above, nothing in step 4
can help there, since the algorithm exits at step 2.

>TODO: dead keys pressed twice fire two keypress events. Dead keys followed  
>by space fire keydown space, keypress for the dead key's accent, keyup  
>space (!). Dead keys are currently a bit underspecified in the above text.

Is there anything peculiar about this? `keypress` in Internet Explorer
maps to a WM_CHAR notification, and if you press a dead key twice you'll
generally get two characters, followed by space generates one character,
and the ups and downs follow naturally.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Wednesday, 14 May 2008 23:56:57 UTC