Last Call Issues for WD-DOM-Level-3-Events

1.2. Description of event flow
How does modification of the DOM tree affect event propagation, section
1.2.2 notwithstanding ("If modifications occur to the tree during event
processing, event flow will proceed based on the initial state of the
tree"). If an EventTarget is deleted during propagation of an event,
does that affect propagation?
---
1.2.1. Event listeners activation
"It is expected that actions taken by EventListener <events.html> s may
cause additional events to fire. Additional events should be handled in
a synchronous manner and may cause reentrancy into the event model."

Since implementations may have restrictions such as stack-usage or other
memory requirements, applications should not depend on how many
synchronous events may be triggered.

---
1.2.2. Event capture
"Capture operates from the top of the tree, generally the Document,
downward"
Is "generally" necessary? Can events be fired on nodes that are not in
the document?
---
1.2.4
"In the case of the hyperlink in the browser, canceling the action would
have the result of not activating the hyperlink."
"Different implementations will specify their own default actions, if
any, associated with each event. The DOM does not attempt to specify
these actions."
In the case of HTMLEvents, the default actions for some of the objects,
such as <A>, as well as their relationship with DOM 1 HTML (such as what
DOM2/3 events result from calling the "click, blur, focus, or select"
methods on an element) would be worth specification. Otherwise we end up
with a situation where the first widely distributed implementation
dictates the specification.
---
1.4.1 Event Creation
CustomEvent -- What is the use case for SetEventPhase? Can
preventDefault or stopPropagation be called during execution of that
method.
---
1.5.2. Mouse event 
Issue public0023 notwithstanding, the spec should discuss the
implementation's responsibility regarding screen- and client-coordinate
translation with regard to DOM 0 event handlers. Since one set of
coordinates implies the other set of coordinates, applications might
assume some behavior - once again the "first-implementation-
dictates-the-spec" problem.
Regarding the resolution of 0023, this _is_ a future version and it
seems like a good time to address this issue, particularly since new API
is being added. I'd suggest that the new API remove the specification of
screen/sclient coordinates entirely and support ONLY target-relative
coordinates. That would be less ambiguous.
----
1.5.3. Text events
Is there no differentiation between the 'Enter key on the numeric
keypad' and the 'Return or Enter key on regular typing keyboard'? I see
only DOM_VK_ENTER specified. Other keys are differentiated between left
and right in the spec. On the Mac, a different character code is
generated as well.
Only one of keyVal or virtKeyVal should be non-zero. If initTextEvent is
called with both non-zero, should the implementation check for this? If
so, what action should it take since no exception is specified?
keyDown and keyUp events are not necessarily generated in pairs by a
platform. All that can be assumed is that one or more keyDown events are
followed by a keyUp event. The spec suggests these occur in pairs
"Depending on the input system being used, textEvent events may or may
not be generated for each pair of keydown and keyup events." The
alternative is that only the first keyDown in a "autoKey" sequence
should result in a keyDown.
In previous mailing list discussion, it's been clarified that
"canceling" a keyDown event has NO EFFECT on whether a textEvent event
is generated from that keyDown. This should be in the spec.
In what case would visibleOutputGenerated be TRUE for any TextEvent
other than textInput?
----
1.5.4. Mutation event types
Given that the support of prevValue in MODIFICATION mutations can have a
significant performance and design impact on an implementation, is it
acceptable to claim support for MutationEvent events if NULL is always
returned for prevValue/newValue of implementation-generated mutation
events?
------
1.5.5. HTML event types
For Focus and Blur, it seems like any element with a default- or
script-supplied action for key-input (such as return should be eligible
for these events, particularly since it's common to allow keyboard
navigation between any element with some default action. Don't restrict
the list to specific element types.