Re: Events ordering: Largely undefined?

Lauren Wood wrote:
> 
> 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.)

Just catching up after some time off-line ... I hope that the next
WD clarifies this a little bit, saying _which_ cases that applies to.

Point being that I think _some_ events must explicitly be ordered,
purely since nodes may only appear in one place at a time.  So the
blanket statement above is demonstrably too strong.

Agreed that in some cases the ordering has issues (e.g. the three
methods that I identified), hence the advice I listed seems to be
appropriate for those cases (and perhaps others TBD).

- Dave


> Lauren
> 
> On 5 Oct 99, at 9:18, David Brownell wrote:
> 
> > 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 Wednesday, 8 December 1999 14:20:07 UTC