Re: Mutation events replacement

On Fri, Jul 22, 2011 at 2:08 AM, Dave Raggett <> 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