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

Here is my take on some of the issues.

On Sat, 2002-07-13 at 18:13, Brad Pettit wrote:
> 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?

Modifications to the tree hierarchy don't modify the event flow once the
dispatch started since the set of nodes involved in the event flow was
computed before the beginning of the dispatch.

> ---
> 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?

Yes. The DOM Events model while mainly used to dispatch events on a DOM
tree could be used on other places, such as a DocumentFragment or a CSS
tree. As long as the node supports the EventTarget interface, the
application can always call the Event.dispatchEvent method in fact.

> ---
> 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.

But is is the role of DOM Events to specify what is the default actions
for HTML elements? As of today, we have several ways to define a link:
in HTML, SVG, SMIL, XLink, HLink, ... One can even imagine to define XML
Schema types for XLink attributes and use them without the XLink
namespace. In fact, XLink do define some default actions using its
behavior attributes.

> ---
> 1.4.1 Event Creation
> CustomEvent -- What is the use case for SetEventPhase?

The DOM Events implementation do need to update the current phase before
calling the event listeners otherwise how would the implementation do?

> Can
> preventDefault or stopPropagation be called during execution of that
> method.

Given that its use is reserved to the DOM Events implementation, if the
DOM application tries to call preventDefault or stopPropagation while 
setEventPhase is beeing executed, the result is unpredictable.
Hopefully, the next version of the Events specification will provide a
better explanation of the CustomEvent interface.

Philippe

Received on Tuesday, 6 August 2002 11:51:47 UTC