On Thu, 15 May 2008 01:56:10 +0200, Bjoern Hoehrmann <[EMAIL PROTECTED]>
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
