W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2011

Re: Replacement for mutation events

From: Andrew Oakley <andrew@ado.is-a-geek.net>
Date: Wed, 2 Feb 2011 22:25:28 +0000
To: Olli@pettay.fi
Cc: Olli.Pettay@helsinki.fi, Jacob Rossi <jrossi@microsoft.com>, "www-dom@w3.org" <www-dom@w3.org>, "schepers@w3.org" <schepers@w3.org>, "jeresig@gmail.com" <jeresig@gmail.com>, Jonas Sicking <jonas@sicking.cc>
Message-ID: <20110202222528.6daa1d64@ado-gentoo>
On Wed, 02 Feb 2011 17:04:26 +0200
Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
> On 02/02/2011 03:30 PM, Andrew Oakley wrote:
> > I didn't like the fact that the notifications were normally
> > synchronous but sometimes they might not be.
> In which case would they be async?
> If a callback modifies DOM, the callbacks which are listening that
> "inner" mutation would be called after the currently in the 
> queue-for-execution callbacks have been executed.
> That is still synchronous in the level of the first DOM mutation.
> 
> Or are you thinking about some other case?

No, that is the case I am thinking of.  Perhaps an example is in
order to show why I think this is a problem.

Lets imagine that you had some code that create a dynamic outline view
of a document.  The outline view shows the headings present elsewhere
in the page and is presented in the page itself.  It listens for
SubtreeChanged somewhere high up in the document tree and rebuilds it's
view of the contents below the node passed node.  Obviously this code
is adding and removing nodes to the tree in response to the callbacks.
This should work fine and doesn't seem to be an unreasonable use of the
API.  It doesn't really care when the events happen, as long as they
happen in a reasonable time frame.  Everything works fine here.

Now imagine we have a toolkit that creates fancy looking widgets based
on attributes on nodes.  Lets say you could do something like this:
<ul fancy-toolkit-view="tree">
  <li>item1</li>
  <li>item2
    <ul>
      <li>subitem1</li>
      <li>subitem2</li>
    </ul>
  </li>
</ul>
The fancy toolkit could turn this into a tree view with little [+]
signs next to the nested items so they could be expanded.  The
toolkit uses the mutation notifications to detect nodes with the
relevant attributes.  The developers of the fancy toolkit rely on the
synchronous nature of the notifications of tree mutations, lets say
they ignore updates that happen while the fancy controls are being
created.  Again, this all works fine.

Now if we imagine that the outline view is tweaked the fancy toolkit to
display the document outline.  Because the fancy tree view is being
created from a mutation callback the fancy toolkit breaks.  One script
has managed to break the other, but only when they are included in the
same page.  The authors of the fancy toolkit have probably never tested
this behaviour and just assumed the notifications are always
synchronous.  

The fact that including two "stock" scripts on the same page might not
work worries me.  The fact that I can't think of a good use case that
requires the notifications to be synchronous is what makes me think
that we should always perform them asynchronously.  

[ I'm not saying that building a toolkit like this is a good idea, just
that someone might do it. ]

>   It feels like this could be the source
> > of subtle bugs (in scripts, rather than browser implementations),
> > especially if toolkits were built on top of other toolkits (like
> > script.aculo.us on top of prototype) and both toolkits used the
> > notifications and expected them to be synchronous.
> >
> > The fact that you could batch changes could be considered to be a
> > side effect of this change, however I think it is a fairly
> > compelling argument in itself.
> 
> The problem is to define how to batch and when?

Hopefully my explanation as to why I think asynchronous events is a
good idea makes sense, and does not require batching of events.  That
is a separate problem which warrants further thought.  

-- 
Andrew Oakley
Received on Wednesday, 2 February 2011 22:25:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:07 GMT