Re: comments on DOM3 Events working draft of April 10

> Date: Tue, 1 May 2001 10:59:17 -0700
> Message-Id: <>
> From: David Flanagan <>
> To:
> Subject: comments on DOM3 Events working draft of April 10
> Here are some comments on the 4/10/2001 draft of the Level 3 DOM Events
> spec.
> 1) Typo: the description of the checkModifier() method refers twice to
>    it as "CheckModifier" with a capital C.  Also, in the description of
>    virtKeyVal, change "virtKeyVale" to "virtKeyVal".


> 2) inputGenerated: I don't understand why this property has the word
>    "input" in its name when the description refers to "visible
>    *output*".  Would outputGenerated be a better name?

To avoid confusion with outputString, we renamed it to visibleOutputGenerated.

>    Also: the description of this property needs an example.  It says "is
>    intended to differentiate between key events which may or may not
>    produce visible output depending on system state".  This is really
>    vague, and I just don't get it, but I think an example would help.

The sentence seems pretty clear. As an example, 'Ctrl+a' doesn't normally
generate a visible output, while 'a' does.

> 3) keyVal: according to the description, this property doesn't provide
>    any information that isn't already provided by outputString.  Is this
>    correct, or is there some interaction between inputGenerated, keyVal
>    and outputString?

keyVal will hold the value of the last used key. For 'ctrl+a', you will
obtain the following sequence:
(v == virtKeyVal, k == keyVal, o == outputString, vo == visibleOutputGenerated,
 m == modifier, 0 == 0/null)


keydown   [v=^,k=0, o=0, vo=0, m=0]
textEvent [v=^,k=0, o=0, vo=0, m=0]
keydown   [v=0, k=a, o=0, vo=0, m=right_ctrl]
textEvent [v=0, k=a, o=0, vo=0, m=right_ctrl]
keyup     [v=0, k=a, o=0, vo=0, m=right_ctrl]
keyup     [v=^, k=0, o=0, vo=0, m=0]

>    What I really think we need to accompany the description of KeyEvent
>    is some pseudo-code showing how an event listener might examine a
>    KeyEvent and extract the maximum amount of information from
>    it. Here's the understanding I've formed based on the current draft:
> if (e.outputString != null && e.outputString.length > 1) {
>    // use outputString
> }
> else if (e.outputString != null && e.outputString.length == 1) {
>    // use outputString or keyVal, depending on preference
> }
> else if (e.outputString == null || e.outputString.length == 0 ||
>          e.keyVal == 0) {
>    // use virtKeyVal
> }

I'm double-checking my example with Tom and will fix the draft.

> 4) In the specs for other event modules, each event type specifies which
>    properties of the event interface are valid for that type.  It would
>    be useful to have the same specified here for textEvent, keyup, and
>    keydown events.  For example, id the inputGenerated property ever
>    valid for keyup and keydown events, or only for textEvent events?

Fixed. (btw, 'views' was missing in DOM Level 2 events context info. oops).

> 5) I've got to question the event type "textEvent".  This is better than
>    "keypress", since that event name is already in use in existing
>    browsers.  But it is redundant and unprecedented to have the word
>    "Event" in an event type name.  The usual format of event names is
>    nounVerb or nounverb, so how about "textGenerated" or "textgenerated"
>    instead?

hum. could be confusing with visibleOutputGenerated...


Received on Tuesday, 24 July 2001 08:16:06 UTC