`MutationObserver` flag to observe mutations in (open) shadow trees to facilitate polyfills of HTML syntax about dom HOT 9 OPEN

An alternative to this might be to be able to observe the composed tree, because in some cases we might want to know the nodes that will participate in the final output:

I've had to implement composed tree tracking so that webgl-rendered custom elements would render correct results when composed via slots into shadow roots. I'd like to release some of these tools separate libs, maybe it'll help ideate.

Even without custom rendering, it might be beneficial to react to composed nodes, avoiding extra work for trees that are not active. F.e. suppose a client-side route switcher modifies slot attributes to show/hide content, and we want to observe only content in the active tree.

from dom.

As author of all polyfills from v0 to current state, I fully support this proposal. My workaround is not super slow but it requires me patching the global attachShadow method on native classes which is a practice I usually avoid at all costs and something I've been advocating against for just about forever ... yet polyfill gotta polyfill, so that if this new proposal is the only thing that might need a greedy polyfill around until everyone is onboard, it's definitively worth the effort to me.

On a side note: the closed shadow might still be addressed somehow and I feel like the elephant in the room here is that we don't have a way for Websites authors to decide what is trusted as script that could patch natives, and what isn't ... CSP is not a great answer to this disambiguation, but maybe this discussion should be done in other venues.

from dom.

Over in

• webqit/realdom#3

@ox-harris implements options.subtree = 'cross-roots' in the realdom lib for synchronously observing added/removed elements across shadow root boundaries, and gets us a little closer to synchronous observation of the composed tree (f.e. detect composed children, composed parent, etc).

Not only is the usage simpler than with MutationObserver (because MO events fire out of order) and lead to simpler code, but composed tree tracking code will also be as simple when that's ready (ComposedChildrenObserver, ComposedParentObserver, ComposedMutationObserver, etc).

from dom.

@LeaVerou could you explain a bit more what is the use case here?

from dom.

@LeaVerou could you explain a bit more what is the use case here?

Sure, what is unclear in my examples?

from dom.

"to implement polyfills of certain features that affect HTML syntax across both light and shadow DOM because it requires observing mutations in shadow trees as well" ... "Any new HTML element or attribute"

So what issue there exactly are you trying to solve?

from dom.

"to implement polyfills of certain features that affect HTML syntax across both light and shadow DOM because it requires observing mutations in shadow trees as well" ... "Any new HTML element or attribute"

So what issue there exactly are you trying to solve?

To implement polyfills of new HTML syntax, you need to be able to react to relevant changes in the DOM. E.g. for a new attribute foobar, you need to be able to react when someone adds a foobar attribute anywhere, including deeply nested Shadow DOM. Doing this with the current MutationObserver API is a hack (I listed how in the OP). Does that make sense? If not, it would help to try and formulate an actual question on what part you find confusing.

from dom.

I see, you want to polyfill new global attributes basically.

from dom.

I see, you want to polyfill new global attributes basically.

That's one use case. Or new native elements. Or new attributes on native elements.

from dom.