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. On Friday, February 28, 2014 7:54:13 AM UTC-8, Steve Orvell wrote: > > 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. > > > On Fri, Feb 28, 2014 at 7:03 AM, Erik Arvidsson <[email protected]<javascript:> > > wrote: > >> If I understand things correctly, the children of the inner-element never >> changes. Composition does not cause any DOM mutations. >> >> >> On Thu, Feb 27, 2014 at 7:28 PM, Sergey Shevchenko >> <[email protected]<javascript:> >> > wrote: >> >>> 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 >>> >>> 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 [email protected] <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/polymer-dev/0994645a-acef-4867-a4d9-5379e21ae2bc%40googlegroups.com<https://groups.google.com/d/msgid/polymer-dev/0994645a-acef-4867-a4d9-5379e21ae2bc%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> >> >> -- >> erik >> >> >> 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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/polymer-dev/CAJ8%2BGog30fZ7MfKJLLjnoWTxjz8P4N9XoZWdi62ADOh8AmdjrA%40mail.gmail.com >> . >> >> For more options, visit https://groups.google.com/groups/opt_out. >> > > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/26f98b7f-1ba8-47b7-9750-e91a88afcfc8%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
