Observe ShadowRoot attachment

[hayatoito]

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.

[valdrinkoshi]

Any advice on how to efficiently polyfill this? Is patching of attachShadow the only way to do this?

I'm implementing the support of shadow dom for the inert polyfill, and I need to observe shadowRoot creation and mutations in order to keep an inert element's content in the shadowDOM inert as well (see issue and proposed solution with patching).

[rniwa]

Polyfilling inert seems like exactly the kind of an edge case in which monkey-patching attachShadow is appropriate.

[hayatoito]

I am triaging open issues. Let me close this since this no longer gets much attentions.
As far as I can read, the original motivation could be addressed by slotchange events.

[felixfbecker]

The fact this doesn't work really cripples browser extensions, which often need to observe changes to the DOM (even on websites that use shadow roots) to decorate it.