[webcomponents] Need a shadowRoots MutationObserver option (bugzilla: 26213) (#204)

Title: Need a shadowRoots MutationObserver option (bugzilla: 26213)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26213

----
comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26213#c0
*Elliott Sprehn* wrote on 2014-06-26 21:47:43 +0000.

Per the discussion in bug 24861 (See https://www.w3.org/Bugs/Public/show_bug.cgi?id=24861#c4) We should add a new MutationObserver option that lets you watch for additions of new ShadowRoots. Otherwise there's no way to detect DOM modifications that happen in new minted ShadowRoots.

----

comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26213#c1
*Olli Pettay* wrote on 2014-06-26 22:21:02 +0000.

And I thought it was one of the main points of Shadow DOM to hide its internals
from the outside world...

If you need to know about the internals of shadow DOM, you probably shouldn't
use it at all, but just plain normal DOM, IMHO.


(Somewhat similar use case to bug 24861#c4 came up in
 FFOS localization. Though, there whenever a component wants to be
 localizable can register itself to some global service after
 shadow dom creation.)

----

comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26213#c2
*Elliott Sprehn* wrote on 2014-06-26 23:04:08 +0000.

(In reply to Olli Pettay from comment #1)
> And I thought it was one of the main points of Shadow DOM to hide its
> internals
> from the outside world...
> 
> If you need to know about the internals of shadow DOM, you probably shouldn't
> use it at all, but just plain normal DOM, IMHO.

Shadow DOM is about making sure consumers don't accidentally access the internals.

The current approach is to replace Element.prototype.createShadowRoot which I think makes Gecko go into slow mode, and doesn't work from isolated script contexts that extensions run inside.

It's also brittle since libraries are fighting to be first so they can replace the built in function before anyone uses it.

> 
> 
> (Somewhat similar use case to bug 24861#c4 came up in
>  FFOS localization. Though, there whenever a component wants to be
>  localizable can register itself to some global service after
>  shadow dom creation.)

This doesn't work in use cases for global attribute polyfills or libraries that use them, or for extensions.

Instead of library authors hacking around us, we should just give them this ability.

----

comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26213#c3
*Anne* wrote on 2014-06-27 06:02:36 +0000.

So we keep adding new features that don't actually explain the platform, but make it more complicated. I'm not a fan.

----

comment: 4
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26213#c4
*Ryosuke Niwa* wrote on 2014-06-30 20:02:07 +0000.

(In reply to Anne from comment #3)
> So we keep adding new features that don't actually explain the platform, but
> make it more complicated. I'm not a fan.

^ THIS × Googolplex.

Indeed this doesn't strike me as a good direction to take.  It's one thing if the shadow root was deliberately exposed by the author, but adding an option to intrude into any shadow root seems to defeat the whole point of using shadow DOM altogether.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/204