You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here this triggers refresh, which makes all ResizeObservers check for size changes on any change of anything in the DOM.
This seems like it may be a little heavy.
Maybe we can instead
observe changes to any <style> elements in the top-level light tree.
call broadcastActive on all ResizeObservers in the light tree only on these changes.
for each element observed with ResizeObserver, listen to attribute changes only on that element directly (as opposed to attribute changes of all elements that exist in the document).
call broadcastActive on the element's ResizeObservers only on these changes
Repeat step 1 but inside of every shadow tree instead of the document light tree.
When an element is moved from one shadow tree to another (or to the document light tree), the ResizeObserver needs to associate with a ResizeObserverController of that new tree.
The easy way to change ResizeObserverController is to have one per tree (light or shadow), so that we can re-associate ResizeObservers with them when elements are moved.
Another possibility could be that a single ResizeObserverController keeps track of all the light/shadow trees, and re-associate which tree a ResizeObserver receives refreshes from after an element has been moved.
Re-association might be as simple as just destroying the current ResizeObserverSPI and making a new one, and when ever a new one is made it happens relative to an element's new location in some tree, therefore the controller or SPI can traverse up the tree to determine what is the root (document or shadow root) and use the associated MutationObserver.
Currently, I don't think observing the document considers what happens in Shadow roots, right? Because a MutationObserver won't cross the boundary, because shadow roots aren't (grand)children of any element in the document, and if they are mode: 'closed' then they are not even referenced from any elements in the document.
So that's why we need a controlling mechanism in each light/shadow tree.
The text was updated successfully, but these errors were encountered:
Currently, I don't think observing the document considers what happens in Shadow roots, right? Because a MutationObserver won't cross the boundary, because shadow roots aren't (grand)children of any element in the document, and if they are mode: 'closed' then they are not even referenced from any elements in the document.
You're absolutely right. As far as I can tell, this polyfill won't be able to detect Mutations within ShadowRoots which is a moving target. See also whatwg/dom#533 (comment) for more thoughts on a somewhat related note.
resize-observer-polyfill/src/ResizeObserverController.js
Lines 162 to 169 in a3ae98b
Here this triggers
refresh
, which makes all ResizeObservers check for size changes on any change of anything in the DOM.This seems like it may be a little heavy.
Maybe we can instead
<style>
elements in the top-level light tree.broadcastActive
on allResizeObserver
s in the light tree only on these changes.ResizeObserver
, listen to attribute changes only on that element directly (as opposed to attribute changes of all elements that exist in the document).broadcastActive
on the element'sResizeObserver
s only on these changesResizeObserverSPI
and making a new one, and when ever a new one is made it happens relative to an element's new location in some tree, therefore the controller or SPI can traverse up the tree to determine what is the root (document or shadow root) and use the associated MutationObserver.Currently, I don't think observing the
document
considers what happens in Shadow roots, right? Because aMutationObserver
won't cross the boundary, because shadow roots aren't (grand)children of any element in the document, and if they aremode: 'closed'
then they are not even referenced from any elements in thedocument
.So that's why we need a controlling mechanism in each light/shadow tree.
The text was updated successfully, but these errors were encountered: