Mutation observer over Shadow DOM with distributed content

[Sergey Shevchenko]

Hi all,

The context for this is Polymer Dart, but @jmesserly thinks this is probably a generic Shadow DOM + Mutation Observers question, so I'm asking here.

I'm trying to observe mutations in the distributed content of a <content> tag as follows: 

@CustomTag(inner-element')

class MyElement {

  void enteredView() { 

    new MutationObserver((m, o) => print("content changed")).observe(this, childList: true); 

  }

};

That works when I use it like this:

<inner-element>

  <template repeat="{{x in xs}}">

    {{x}}

  </>

</>

But it breaks when there is another element that wraps around and reprojects its distributed content into <inner-element>:

<polymer-element name="outer-element">

  <template>

    <inner-element>

      <content></content>

    </inner-element>

  </>

</>

<outer-element>

  <template repeat="{{x in xs}}">

    {{x}}

  </>

</>

InnerElement does not see the changes in the xs. What it is the right way to observe them? Ideally, I'd like it to be generic, i.e. working for both cases above. As a less preferred option, I could implement a special case for when the distributed content is a reprojected <content> from the embedder. 

I could of course add a second MutationObserver to OuterElement and explicitly tell InnerElement to update whenever a mutation happens, but it seems to me that this defies the whole idea of MutationObservers.

Thanks,

--Sergey

[Erik Arvidsson]

If I understand things correctly, the children of the inner-element never changes. Composition does not cause any DOM mutations.

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/0994645a-acef-4867-a4d9-5379e21ae2bc%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
erik

[Steve Orvell]

I agree and I think this is a general problem that the ShadowDOM spec should address. I've tried to summarize the issue in this spec bug, to which I linked this post.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24861

Feel free to contribute.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAJ8%2BGog30fZ7MfKJLLjnoWTxjz8P4N9XoZWdi62ADOh8AmdjrA%40mail.gmail.com.

[Sergey Shevchenko]

Can't wait to see this resolved!

This also echoes with another thread that I started on Dart Web some time ago:

https://groups.google.com/a/dartlang.org/forum/#!topic/web/WLayzsT1WMA

The thing I've realized while working on Polymer widget library for Spark IDE is that, very inconveniently, any given custom element should be aware of and check whether it's being used in a "pure HTML" environment or in the environment of another embedding element. So:

<div></div>

<my-element></my-element>

<div></div>

should be detected and treated differently by <my-element> than:

<polymer-element name="some-other-element">

  ...

  <content ...></content>

  <my-element></my-element>

  <content ...></content>

-- even when the same 2 divs are distributed in the 2 <content>s above as in the first case. As a developer, I'd want to have something like getDistributedNodesRecursivelyPleaseExpandAllCascadingContentTagsForMe(). I don't want to know or care about the way the true light DOM nodes have been brought into my environment, just as in C++ I don't care whether a given class I'm about to use is defined in the same source or has been imported via a chain of 10 cascading #includes.