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

On Tue, 2002-08-06 at 14:01, Brad Pettit wrote:
> 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?

Yes.

> Should the spec point out that
> EventListeners should make few, if any, assumptions about the DOM
> heirarchy at the time they are called?

Any piece of code that rely on a specific hierarchy may fail if the
hierarchy is changed, whether it works on nodes resulting from the DOM
event flow, on nodes resulting from an XPath query or
getElementsByTagName, etc. As an author of a web page, that defines the
content and scripts associated with it, it seems reasonnable to make
some assumptions about the DOM hierarchy. The DOM is a "lived" structure
and since the behavior for the DOM event flow is clearly, I don't feel
an extra sentence is needed. Now, having said that, if we really want to
add a sentence, it could something like "Event listeners authors must
understand that the DOM tree is a live structure and therefore, the
current target might not be no longer at the expected position, or be
removed from the DOM tree, when the event listener is invoked".

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

Again, if the event listener do so, then it is clearly against what is
recommended in this specification. The DOM Events implementation is the
only one which is supposed to invoke those methods and will never skip a
phase or set it to a previous phase. I proposed a different wording for
the CustomEvent interface description but we can certainly change it if
it's not clear or strong enough:
[[
The CustomEvent interface gives access to the attributes
Event.currentTarget and Event.eventPhase. It is intended to be used by
the DOM Events implementation to access the underlying current target
and event phase while dispatching the event in the tree.

The methods contained in this interface are not intended to be used by a
DOM application, especially during the dispatch on the Event object.
Changing the current target or the current phase may conduct into
unpredictable results of the event flow. The DOM Events implementation
should invoke both methods before invoking each event listener on the
current target to protect DOM applications from malicious event
listeners.
]]

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

It's trying to address an issue with DOM Level 2 Events discovered a
year. While we didn't find a 100% satisfactory, we believe that the
proposed solution is the best proposal for the moment but it is
certainly controversial [3]. 

Philippe

[1] http://lists.w3.org/Archives/Public/www-dom/2002JulSep/0048.html
[2] http://lists.w3.org/Archives/Public/www-dom/2001JulSep/0294.html
[3] http://lists.w3.org/Archives/Public/www-dom/2002JulSep/0053.html

Received on Tuesday, 6 August 2002 16:41:44 UTC