Re: Mutation events replacement

On Mon, Jul 4, 2011 at 10:16 AM, Adam Klein <adamk@chromium.org> wrote:

> On Mon, Jul 4, 2011 at 9:57 AM, Olli Pettay <Olli.Pettay@helsinki.fi>
> wrote:
> > On 07/04/2011 07:28 PM, Ojan Vafai wrote:
> >> Apologies in advance if my comment makes no sense. This is a long
> >> thread, I tried to digest it all. :)
> >>
> >> On Sat, Jul 2, 2011 at 7:07 AM, Boris Zbarsky <bzbarsky@mit.edu
> >> <mailto:bzbarsky@mit.edu>> wrote:
> >>
> >>    That may be ok, if the use cases that incur this cost are rare and
> >>    the common case can be better served by a different approach.
> >>
> >>    Or put another way, if 1% of consumers want the full list because it
> >>    makes them 4x faster and the other 99% don't want the full list, and
> >>    the full list is 3x slower for the browser to build than just
> >>    providing the information the 99% want, what's the right tradeoff?
> >>
> >> I'm not sure there really is a performance tradeoff. I believe that the
> >> proposal Rafael put forward should almost always be faster. Storing the
> >> list of changes and doing a JS callback once, for nearly all use-cases,
> >> should be faster than frequent, semi-synchronous callbacks.
> >>
> >> The only bit that might be slower is what data you include in the
> >> mutation list. I believe that all the data you'd need is cheap except
> >> for possibly the following two:
> >> -The index of the child that changed for ChildListChanged (is this
> >> actually expensive?)
> >
> > You may need more than just an index. element.innerHTML = null removes
> > all the child nodes.
> > And element.inserBefore(some_document_fragment, element.lastChild)
> > may insert several child nodes.
> > Depending on whether we want to get notified for each mutation
> > or batch the mutations, simple index may or may not be enough.
>
> Would a node reference be better ("nextSibling")?  Assuming the
> listeners have access to all inserted/removed nodes along the way,
> using another as an anchor seems like it would work properly (though
> the innerHTML case may need something special).
>

That sounds great to me. nextSibling seems sufficient.


> >> -The old value of an attribute/text node. I know this is expensive in
> >> Gecko's engine at least.
> >
> > Shouldn't be that slow.
> >
> > Mutation listener could easily
> > implement old/new value handling itself, especially if it knows which
> > attributes it is interested in.
>
> This only works if listeners don't care about intermediate values,
> since all they'll have access to is the last value they saw and the
> current value in the DOM. If it was set several times during a single
> "mutation event" (whether that be your or Rafael's definition of a
> "transaction"), they'll miss those in-between values.  Also, while
> this would be acceptable for some use cases, the editing/undo use case
> would need to keep values of all attributes at all nodes, which seems
> likely to be worse than having the UA take care of this.
>
> >> I'd be fine with excluding that information by default, but having a
> >> flag you pass at some point saying to include those. That way, only
> >> sites that need it take the performance hit.
>
> Given that different use cases seem to have wildly different
> requirements (some probably only care about one or two attributes
> while others care about the entire document), this approach to
> handling the availability of oldValue/newValue is appealing.
>
> - Adam
>