Re: DOM L2 comments, various

I didn't see any response to my earlier query re events; should I
expect one?

Here are some further observations about the event portion of the
specification -- based in part on the task of trying to understand
the spec well enough to implement it !!

- Dave

6.2	It appears that there's no way to guarantee that an ancestor
	will get an event -- both capturing and bubbling permit other
	nodes to interfere with event reporting.  This seems ungood
	in general; there ought to be _one_ mechanism whereby event
	reporting isn't subject to interference.

6.3.1	I'm curious in general why EventListener.handleEvent() is
	defined to handle _all_ events rather than having separate
	interfaces that directly handle the different sorts of events
	(a MouseEventListener, MutationEventListener, etc).  That's
	how Swing does this stuff, and it's generally handy to have
	such "pre-dispatched" frameworks -- it can be faster, too!

6.2.2	Event capture ... the text is unclear what preventCapture()
	achieves.  The third para says that if you call it, no
	further targets lower in the tree will get events, which
	seemingly includes both the "deliver to target" phase (which
	is elsewhere said to be "guaranteed") and event bubbling.

	It makes sense to me to see the preventCapture() method only
	have effect during the capture phase.  If so, its description
	in 6.2.2 needs updating (no further targets will capture).

6.6.4	DOMSubtreeModified ... insufficiently specified.  What event
	batching is supposed to be performed?  In what sense may it
	be used "instead of the more specific events"?  And for that
	matter, which "more specific events"?

	I couldn't make any sense of this description at all.  And there
	was the hint that it's another one of those really expensive
	events (like DOMNode**Document) noted below ...

6.6.4	DOMNodeRemovedFromDocument ... seems horrendously expensive.
	After delivering an DomNodeRemoved event, that node and all
	of its descendants (!!!) get one of these.

	Must this really be done?  It'll increase the cost to support
	the mutation events substantially.

6.6.4	DOMNodeInsertedIntoDocument ... correspondingly expensive.

General	There's no way for applications to define their own events
	and thus use the event mechanism for any purpose except those
	that are built in.

	I'd like to see such a standard, perhaps part of the basic
	"Events" mechanism.  In the same way that DOM events all have
	"DOM" prefixes, perhaps they could have a "USER." prefix.
	And it'd be desirable for such user events to have a way to
	include information ... maybe a UserEvent interface could have
	an Object parameter set in its initUserEvent() method, which
	has application defined semantics.

Received on Friday, 1 October 1999 15:34:30 UTC