- From: Rafael Weinstein <rafaelw@google.com>
- Date: Tue, 5 Jul 2011 14:42:59 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Ojan Vafai <ojan@chromium.org>, public-webapps@w3.org
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