D3E last call comments on text and keyboard events

These comments are based on the 2010-10-06 Editor's Draft.

0) I suspect that this has already been debated at length, but does the 
"textInput" event really have to be mixed case?  With the deprecation of 
the various DOM-prefixed event types, won't this be the only mixed-case 
event type?  Assuming that browsers expose this event with an "on" 
handler property, JavaScript programmers are going to be confused when 
typing "ontextInput" and will end up doing "onTextInput".  If a 
single-case name is good enough for genuinely hard-to-read things like 
"compositionend", it should be fine to use "textinput" for this event!

1) This looks like a copy-and-paste error from KeyLocationCode:

>  Definition group InputMethodCode
>
>     This set of constants shall be used to indicate the origin of the text input. In case a DOM implementation wishes to provide a new location information, a value different from the following constant values must be used.
>

Change "wishes to provide a new location information" to "wishes to 
define a new origin"

2) There are a couple of problems with initKeyboardEvent().  First, when 
it first apperas in the gray box, it has a repeat argument.  But down 
below, where the method arguments are each explained the repeat argument 
is missing.  Second, I don't understand how the char and keyCode 
properties of the KeyboardEvent are initialized.  Are they derived from 
the keyArg argument to initKeyboardEvent().  If so, perhaps you could 
add a sentence to the description of that argument: "KeyboardEvent.char 
and KeyboardEvent.keyCode are both derived from this argument."  (Or 
something to that effect).

3) In "Definition group KeyLocationCode", the constants are listed in 
neither numerical order nor alphabetical order.  I was confused for 
awhile because I couldn't find the constant for KEY_LOCATION_STANDARD. 
Please re-order this list so it matches the numerical order of the 
constants shown in the gray box above.  Also, three of these paragraphs 
use a confusing "shall be in/on" wording.  Maybe you could change these 
to be parallel with the "originated on" wording of the other constants.

4) When you are describing the altKey, ctrlKey and similar attributes of 
"KeyboardEvent" you use the word "activated" to mean "in effect".  Just 
above that, in the list of constants, you use the word "activation" to 
mean "the key press or release that triggered this event".  This wording 
is confusing because it could be read to mean that ctrlKey, for example, 
will only be true when the key is first pressed down.  I suggest you 
avoid "activated" here and use language like this:

    "true if the control (Ctrl) modifier was active when this event 
occurred."

I realize now that I actually don't know whether ctrlKey should be true 
for the event generated when Ctrl is first pressed down.  Or whether it 
should be true when the Ctrl key is released. So maybe you could clarify 
that here, too.  Guessing at the proper settings for this modifier, you 
might say something like:

    "If this KeyboardEvent describes the press of a control key, then 
this property will be true.  If this KeyboardEvent describes the release 
of a control key, and if no other control modifier is active, then this 
property will be false."


5) In the description of the KeyboardEvent.char, I suggest you change 
"The value must be a Unicode character string" to "If the key press has 
a character representation, the value of this property will be a 
non-empty Unicode character string".

6) In the description of KeyboardEvent.key, it says "If the value is a 
character, it must match the value of the KeyboardEvent.char attribute." 
  First, is "character" formally defined somewhere, or you mean 
something like "If the key has a printable representation".  Second: 
what about the case of keyboard macros?  If I've somehow bound Ctrl-J to 
insert the string "JavaScript", then I would expect a Ctrl-J 
KeyboardEvent to have "JavaScript" as its char value and "J" as its key 
value.  If this is the correct behavior then the phrase "must match" in 
the spec is a problem.  If keyboard macros are supposed to get expanded 
into the key property, then that allows us to fake out keys that we 
don't have on our keyboards by defining keyboard macros.  In that case, 
if I define a macro to insert the string "Camera", then that macro might 
cause a webapp to behave as if the Camera key had been pressed.  (It 
almost seems like there is a security issue there...)

7) After the description of KeyboardEvent and all its properties and 
methods, there is a warning, followed by one sentence and a Note, and 
then a segue into the next section.  That one sentence ("Depending on 
the character generation device...") seems like an orphan with no home 
and no context.  Can it and its note go at the beginning of the section? 
  Or in the section that follows?

8) In the boxes describing keydown, keyup and keypress, you describe the 
altKey, and related event properties using the word "depressed". 
Elsewhere you've used vaguer language like "activated", and I've assumed 
that is to account for the possibility of locking modifier keys for 
accessibility reasons.  If so, you should probably change "key is 
depressed" to "modifier is active" in these boxes.  (Past tense might 
actually be better: "modifier was active").

9) The keypress, keydown and keyup boxes don't list the char or keyCode 
properties of KeyboardEvent.  And they don't have values filled in for 
key and location.

10) "Whether or not a keydown contributes to the generation of a text 
event is implementation dependent."  Do you mean specifically a 
textInput event here?

11) The description of the keydown event says that the default action of 
a keydown is to dispatch a textInput event for events that generate 
text.  But above, at the start of 5.2.6.1, it says that keypress is 
generated before textInput.  One or the other of these must be wrong.

12) Minor typo in the 3rd bullet after keydown: You should probably have 
a little blue box around the Tab key.  Also, is it okay to hardcode Tab, 
Enter and Space here or do you need to do some kind of OS-dependent 
hand-waving to account for the possibility of operating systems that use 
different keys for moving keyboard focus and activating UI elements?

13) The 2nd sentence of the keypress and keydown event descriptions 
reference the keydown event in an apparent copy-and-paste error.

14) The keypress box says that the keypress event can trigger textInput 
as a default action.  But that is never described in more detail after 
the box.

	David Flanagan

Received on Thursday, 14 October 2010 20:26:01 UTC