- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 22 Jul 2011 15:57:13 -0700
- To: Dave Raggett <dsr@w3.org>
- Cc: Adam Klein <adamk@chromium.org>, Olli Pettay <Olli.Pettay@helsinki.fi>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
On Fri, Jul 22, 2011 at 2:08 AM, Dave Raggett <dsr@w3.org> wrote: > On 22/07/11 02:26, Adam Klein wrote: >> >> This is only complex because you're coalescing the mutations, right? >> In Rafael's original proposal, each mutation would result in a single >> immutable mutation record, so the semantics would be to "deliver" (by >> appending to a queue associated with each observer) a mutation record >> to any currently-registered observers. >> >> Or is there some other concern with beginning notifications partway >> through a task? > > I would suggest avoiding coalescing mutations altogether! > > But if you are going to, *don't* coalesce mutations when the resulting DOM > tree is dependent on the order in which those mutations took place. This is > critical to distributed editing applications. The DOM should have no such behavior. The only exception to this rule that I know of is <script> elements. They execute their contained script the first time they are inserted into a Document, but don't "undo" that action when removed (for obvious reasons), nor do they redo it when inserted again. / Jonas
Received on Friday, 22 July 2011 22:58:10 UTC