Re: Mutation events replacement

On Tue, Jul 5, 2011 at 2:29 PM, Rafael Weinstein <rafaelw@google.com> wrote:
> On Tue, Jul 5, 2011 at 2:27 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> On 7/5/11 5:21 PM, Rafael Weinstein wrote:
>>>
>>> For ChildlistChanged, the potential data to be included:
>>> -Target node*
>>> -Removed nodes*
>>> -Added nodes
>>> -one of nextSibling or previousSibling*
>>>
>>> My belief is that including the starred (*) data above would be
>>> sufficient to meet David's test of mirroring a tree *without* a ton of
>>> processing or O(N) memory.

Doh! Sorry. Just to note: if you omit Added Nodes, I think you'd need
AddedNodeCount.

Generally speaking, to avoid application script needing to make copies
of wholesale DOM structures, it needs to be given "the old data" and
"the shape of the new data"

E.g.:
For ChildlistChanged: removedNodes + addedNodeCount & next/previousSibling.
For AttributeChanged: added/removed/updated + oldValue
For TextChanged: oldValue.

This may be an unreasonable burden for UA's to deliver all the time.
If so, a "give me old data" flag seems worth considering.

Many use-cases will be aiming to minimize expensive work (typically
creating more DOM or writing to the wire) -- and it'll be tempting to
guarantee that work *has* to be done. Lacking "old data", the
application will need to preemptively make a copy of all data that
*could* change.

>>
>> How is that not O(N) memory?
>
> Sorry - that was imprecise. What I meant was: the application script
> wouldn't need to maintain more or less it's own copy of the DOM to
> know for certain whether a node has effectively been added, removed,
> or moved elsewhere in the document.
>
>>
>> -Boris
>>
>

Received on Tuesday, 5 July 2011 21:43:23 UTC