Mutation Summary missing attribute namespace and next sibling?

[Sunil Agrawal]

Hi,

I am thinking of using Mutation Summary library and saw that some of the information from MutationRecord is missing from the mutation summary being returned by the library, e.g. the old next sibling (I see there's support for old previous sibling) and in case of attribute modifications, the attribute namespace.

Any reason for the omissions and any plans on adding them?

Thanks in advance,

Sunil

[Rafael Weinstein]

Hi Sunil,

There isn't really a reason, per se, that they are excluded -- mostly
that no one's yet presented a use case.

The use cases I know of that are interested in childList position are
generally tree mirror/synchronization-type mechanisms and
oldPreviousSibling is sufficient to unambiguously identify a node's
position in the previous state of the tree.

Also, a core design goal of MutationSummary and the underlying DOM
Mutation Observers is compute efficiency, so avoiding unneeded
computation is good.

Also, MutationSummary has a bit of an implicit assumption that it's
operating in a single namespace. I honestly haven't thought through
the implications of supporting observation on a DOM which has nodes
from multiple namespaces.

Perhaps you can say more about your use case(s)?

> --
> You received this message because you are subscribed to the Google Groups
> "mutation-summary-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mutation-summary-d...@googlegroups.com.
> To post to this group, send email to
> mutation-sum...@googlegroups.com.
> Visit this group at
> http://groups.google.com/group/mutation-summary-discuss?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Sunil Agrawal]

Thanks Rafael for the response. 

1. My use case is similar to the tree mirror/sync mechanism and currently we are using the 'raw' MutationObserver APIs, but MutationSummary seems like a cleaner high level abstraction for our needs.

What I saw in Firefox is if the web application uses innerHTML, then the mutation records contain a bunch of removed nodes (all the nodes that are getting removed) and then bunch of added nodes (all the new nodes that got added). And syncing these individual operations causes a jerky behavior on the receiving end. However, if we can use some heuristics to detect that web app used innertHTML then we can potentially improve the user experience.

The current heuristic we use if if the new node that got added has previousSibling and nextSibling null, then we try to sync it's parent node, and drop the individual removedNodes and addedNodes.

Hence my interest in getting the nextSibling.

I apologize in advance if I am not articulate with my use case.

2. For attributenamespace, web applications like Google Maps and Yahoo Maps (for some browsers atleast) use inline SVG, which is in a different namespace (SVG namespace). Hence will appreciate if that information can be propagated too.

Thanks, Sunil

[Rafael Weinstein]

On Thu, May 30, 2013 at 10:17 AM, Sunil Agrawal <su...@armor5.com> wrote:
> Thanks Rafael for the response.
>
> 1. My use case is similar to the tree mirror/sync mechanism and currently we
> are using the 'raw' MutationObserver APIs, but MutationSummary seems like a
> cleaner high level abstraction for our needs.
>
> What I saw in Firefox is if the web application uses innerHTML, then the
> mutation records contain a bunch of removed nodes (all the nodes that are
> getting removed) and then bunch of added nodes (all the new nodes that got
> added). And syncing these individual operations causes a jerky behavior on
> the receiving end. However, if we can use some heuristics to detect that web
> app used innertHTML then we can potentially improve the user experience.
>
> The current heuristic we use if if the new node that got added has
> previousSibling and nextSibling null, then we try to sync it's parent node,
> and drop the individual removedNodes and addedNodes.
>
> Hence my interest in getting the nextSibling.
>
> I apologize in advance if I am not articulate with my use case.

I think you'll find that your heuristic is incomplete. I suggest just
using (or adapting)

https://code.google.com/p/mutation-summary/source/browse/mutation_summary.js

For your purposes, as it is doing exactly what you need to do:
completely synchronizing a tree from one location to another.

>
> 2. For attributenamespace, web applications like Google Maps and Yahoo Maps
> (for some browsers atleast) use inline SVG, which is in a different
> namespace (SVG namespace). Hence will appreciate if that information can be
> propagated too.

The only thing that MutationSummary can provide for you in this regard
is the *old*-namespace URI of an element. However, it seems extremely
unlikely that, for these uses, the attributes on the non-html elements
will ever change their namespace. Hence, all you should need to do is
examine the *present* namespace of the affected attribute.

[Sunil Agrawal]

On Thu, May 30, 2013 at 10:37 AM, Rafael Weinstein <raf...@google.com> wrote:

On Thu, May 30, 2013 at 10:17 AM, Sunil Agrawal <su...@armor5.com> wrote:
> Thanks Rafael for the response.
>
> 1. My use case is similar to the tree mirror/sync mechanism and currently we
> are using the 'raw' MutationObserver APIs, but MutationSummary seems like a
> cleaner high level abstraction for our needs.
>
> What I saw in Firefox is if the web application uses innerHTML, then the
> mutation records contain a bunch of removed nodes (all the nodes that are
> getting removed) and then bunch of added nodes (all the new nodes that got
> added). And syncing these individual operations causes a jerky behavior on
> the receiving end. However, if we can use some heuristics to detect that web
> app used innertHTML then we can potentially improve the user experience.
>
> The current heuristic we use if if the new node that got added has
> previousSibling and nextSibling null, then we try to sync it's parent node,
> and drop the individual removedNodes and addedNodes.
>
> Hence my interest in getting the nextSibling.
>
> I apologize in advance if I am not articulate with my use case.

I think you'll find that your heuristic is incomplete. I suggest just
using (or adapting)

https://code.google.com/p/mutation-summary/source/browse/mutation_summary.js

For your purposes, as it is doing exactly what you need to do:
completely synchronizing a tree from one location to another.

[SA] I'll definitely look at it. Any clues on how do you optimize? I am not saying what MutationSummary provides is functionally incorrect.

 

>
> 2. For attributenamespace, web applications like Google Maps and Yahoo Maps
> (for some browsers atleast) use inline SVG, which is in a different
> namespace (SVG namespace). Hence will appreciate if that information can be
> propagated too.

The only thing that MutationSummary can provide for you in this regard
is the *old*-namespace URI of an element. However, it seems extremely
unlikely that, for these uses, the attributes on the non-html elements
will ever change their namespace. Hence, all you should need to do is
examine the *present* namespace of the affected attribute.

[SA] As I am only getting the attribute name and not the namespace, how do I get to the right attribute?  I would like to use the *NS APIs.

[Rafael Weinstein]

What is it you are wanting to optimize?

>
>>
>> >
>> > 2. For attributenamespace, web applications like Google Maps and Yahoo
>> > Maps
>> > (for some browsers atleast) use inline SVG, which is in a different
>> > namespace (SVG namespace). Hence will appreciate if that information can
>> > be
>> > propagated too.
>>
>> The only thing that MutationSummary can provide for you in this regard
>> is the *old*-namespace URI of an element. However, it seems extremely
>> unlikely that, for these uses, the attributes on the non-html elements
>> will ever change their namespace. Hence, all you should need to do is
>> examine the *present* namespace of the affected attribute.
>>
>
> [SA] As I am only getting the attribute name and not the namespace, how do I
> get to the right attribute? I would like to use the *NS APIs.

You can iterate over the element's .attributes collection and when you
find an attribute whose .name matches the attribute you've been given,
inspect the attribute's .namespaceURI.

https://developer.mozilla.org/en-US/docs/Web/API/Node.attributes

[Sunil Agrawal]

>

>>
>> >
>> > 2. For attributenamespace, web applications like Google Maps and Yahoo
>> > Maps
>> > (for some browsers atleast) use inline SVG, which is in a different
>> > namespace (SVG namespace). Hence will appreciate if that information can
>> > be
>> > propagated too.
>>
>> The only thing that MutationSummary can provide for you in this regard
>> is the *old*-namespace URI of an element. However, it seems extremely
>> unlikely that, for these uses, the attributes on the non-html elements
>> will ever change their namespace. Hence, all you should need to do is
>> examine the *present* namespace of the affected attribute.
>>
>
> [SA] As I am only getting the attribute name and not the namespace, how do I
> get to the right attribute?  I would like to use the *NS APIs.

You can iterate over the element's .attributes collection and when you
find an attribute whose .name matches the attribute you've been given,
inspect the attribute's .namespaceURI.

https://developer.mozilla.org/en-US/docs/Web/API/Node.attributes

Really? 

MutationSummary is a great library, but seems there's push back in making it even better. Anyway, I'll see how I can workaround.

Thanks.