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

I have a few follow-ups to the remarks of Philippe Le Hegaret:

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

So it's reasonable to say that an event could fire on a node that had,
for all intents and purposes, been otherwise deleted, and the only
reason it still exists is because there is an event pending on it,
either a source or a target? Should the spec point out that
EventListeners should make few, if any, assumptions about the DOM
heirarchy at the time they are called?
---------

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

It is specifically the HTMLEvent suite to which I am referring. In the
case of specifying a set of HTMLEvent default actions, yes, I do believe
it is within the scope of DOM Events to define that based on the current
state of HTML, just as DOM-0 was based on the current state of
implementations. At the time other types are developed, it would be wise
to take into account the original intent of HTMLEvents if that is what
they choose to model. 

---------
Use of CustomEvent::SetEventPhase
>>The DOM Events implementation do need to update the current phase
before calling the event listeners otherwise how would >>the
implementation do?

Should there be a restriction to the callers of the event, or whether,
for instance, it is legal to set the event phase to a previous value or
skip values, such as at-target to capture, or capture to bubble?

Perhaps CustomEvent isn't quite ready for release in spec form?

--Brad

Received on Tuesday, 6 August 2002 14:01:55 UTC