This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 26213 - Need a shadowRoots MutationObserver option
Summary: Need a shadowRoots MutationObserver option
Status: RESOLVED MOVED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-26 21:47 UTC by Elliott Sprehn
Modified: 2015-07-06 08:04 UTC (History)
11 users (show)

See Also:


Attachments

Description Elliott Sprehn 2014-06-26 21:47:43 UTC
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 Olli Pettay 2014-06-26 22:21:02 UTC
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 Elliott Sprehn 2014-06-26 23:04:08 UTC
(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 Anne 2014-06-27 06:02:36 UTC
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 Ryosuke Niwa 2014-06-30 20:02:07 UTC
(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.
Comment 5 Hayato Ito 2015-07-06 08:04:06 UTC
Moved to https://github.com/w3c/webcomponents/issues/204