Re: D3E last call comments on text and keyboard events

Hi, David-

This is just a note to acknowledge your emails.  I really do appreciate 
your review, and will be logging these issue in the issue tracker 
soon... I'm just a bit busy at the moment.

(FWIW, I wouldn't mind lowercasing 'textInput' if the implementers are 
okay with it.)

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs


David Flanagan wrote (on 10/14/10 4:25 PM):
> 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:35:08 UTC