Re: Events ordering: Largely undefined?

keshlam@us.ibm.com wrote:
> 
> After consideration: We may be able to nail down the exact sequence for _simple_
> mutations (insert and remove), but I think we may have to declare compound
> operations subject to variation from DOM to DOM, unless we're willing to specify
> DOM implementation to a greater degree than in the past.

A quick look suggests to me that there aren't so many "compound"
operations to worry about:

	Node.replaceChild ... but a partial ordering constraint	
	exists (see below) so I think there are only three possible
	orderings for the three events.

	Attr.setValue ... order in which all old nodes are
	removed and the new text node is inserted is variable,
	but not visible outside of the attribute's subtree

	Document.importNode ... new, it'd be practical to
	specify ordering if that were the desired solution.

Maybe I missed some.  In all cases there's useful application
advice that can be given:  (a) don't use replaceChild, unless
you somehow know that event ordering will never matter; (b) don't
put event listeners on Attr objects, but use the DOMAttrModified
events on the Element instead; (c) since you can't see any nodes
in the new tree before the method returns, you can't listen for
any of its mutation events.

Do similar issues exist for events other than MutationEvents?
 

> That does mean that folks can't count on one set of events occurring before the
> other. I don't think that's a problem. But it might be a good idea to state it
> explicitly, to discourage folks from relying on any given implementation's
> behavior.

In your replaceChild example, you missed one basic constraint on the
sequencing:  if newChild already has a parent, it'll be removed from
there before it's inserted into the new node's set of children.

I actually do think that it's a problem if there's too much variability
here, since applications tend to write order-dependent code.  So rather
than just a blanket "it can all be different" statement, I'd rather see
some explicit descriptions of what differences are permissible.

It may be easier to do this in the context of specifying all event delivery
sequences adequately.  (As I'd commented before, some of the events seem
insufficiently described to support even vaguely portable applications.)

- Dave

Received on Tuesday, 5 October 1999 12:19:21 UTC