W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Mutation events replacement

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 22 Jul 2011 15:57:13 -0700
Message-ID: <CA+c2ei_DKQi1qnOLKdvsxxJP8PNdhbAVtGf3qBXCaVqsEWkf5w@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:46 GMT