- From: Lauren Wood <lauren@sqwest.bc.ca>
- Date: Thu, 25 Nov 1999 12:48:12 -0800
- To: www-dom@w3.org
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.) 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 Thursday, 25 November 1999 15:53:21 UTC