Re: specification of "legacy" key events

On Thu, 15 May 2008 01:56:10 +0200, Bjoern Hoehrmann <derhoermi@gmx.net>  
wrote:

> * 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.

Hi Björn, thanks for your thorough review - so thorough you even sent  
feedback on the phrasing of the request for comments paragraph.. :)

> 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.

Can you help me rephrase it? As you see I'm trying to pin down what key  
input exactly should cause keypress events. I think it makes sense to say  
something to the effect of "input that generates text" or "input that  
would generate text if the target was an editable element" - with an  
exception that also includes Esc because all browsers do that.

(Some browsers send more keypress events than this. Opera and Firefox send  
keypress events for navigation and function keys. I know it causes web  
application bugs for us to do so, if it's not a problem for Firefox I  
guess the reason is browser sniffing. IMO it simplifies things to only  
send keypress for keys that would cause text input and at least for Opera  
this also seems to be more compatible with what web content expects though  
I'm sure we'll also see something break if we make this change..)

>> 	* 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.

OK. We can drop it and focus on the two issues of when to send what  
events, and how keyCode/charCode should be defined.

>> 	* 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.

If we call those bullets 1, 2 and 3 should we re-order them to be 2,3,1 or  
3,2,1?

> 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?

I'll leave that to the WG specifying textInput - my main interest here is  
getting the legacy stuff really documented and specified. I've described  
how keypress works for keys that generate multiple characters and the WG  
should specify how textInput should work for this case.

> 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;

This indeed happens in Opera and Safari (Win), but not in IE and Firefox..  
If browsers are inconsistent and we can assume no web content relies on  
this can the spec ignore that detail? :-p

> 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).

Yes, I do. IE, Firefox and Safari generate repeated keydown events, Opera  
repeated keypress events. My spec text should be fixed to say fire  
repeated keydown events if the key does not generate key press events..

>> 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.

Absolutely. TODO#2 was meant to be sort of an open issue on fixing this.

What about something like this for the keydown/keyup keyCode calculation?

1 If system's keyCode is in the range 48-57, use the given value for  
keyCode (0-9 keys)
2 If system's keyCode is in the range 65-90, use given value for keyCode  
(A-Z)
3 If system's keyCode is in the range 97-122, subtract 32 and use the  
result for keyCode (a-z becomes A-Z)
4 If the corresponding character has an upper-case form, use the ASCII  
value of the upper case form
5 Else, use the system supplied keyCode

(Perhaps add a step between 4 and 5 to handle comma, period, plus, minus,  
space and enter and specify what key codes they should have..)

> 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.

Well, I plead guilty to not having ventured beyond BMP in my testing :-p

>> 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.

Yes, this TODO implies some re-ordering of those steps..

>> 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.

It just seems a bit convoluted to specify. I understand what's going on  
but I'm not sure how to phrase it..

-- 
Hallvord R. M. Steen
Core QA JavaScript tester, Opera Software
http://www.opera.com/
Opera - simply the best Internet experience

Received on Thursday, 15 May 2008 12:27:00 UTC