On 07/04/2011 08:16 PM, Adam Klein wrote:
On Mon, Jul 4, 2011 at 9:57 AM, Olli Pettay<olli.pet...@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<bzbar...@mit.edu
<mailto:bzbar...@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).
Where would the node reference be?
What would the API look like?
-Olli
-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
