Re: Events ordering: Largely undefined?

Results of discussions: events are explicitly not ordered, so you 
can't write code that relys on an order (brief list of reasons includes 
concerns with multi-threaded environments, whether it's possible 
anyway, etc.)


On 5 Oct 99, at 9:18, David Brownell wrote:

> 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 Thursday, 25 November 1999 15:53:21 UTC