resize-observer-polyfill icon indicating copy to clipboard operation
resize-observer-polyfill copied to clipboard

Observing the entire document for everything may be too heavy?

Open trusktr opened this issue 5 years ago • 2 comments

https://github.com/que-etc/resize-observer-polyfill/blob/a3ae98bcd34e972b92d9e40e8b974a75399503e8/src/ResizeObserverController.js#L162-L169

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

  1. 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.
  2. 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
  3. Repeat step 1 but inside of every shadow tree instead of the document light tree.
    1. 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.

trusktr avatar Sep 06 '18 17:09 trusktr

@trusktr

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 https://github.com/whatwg/dom/issues/533#issuecomment-405530738 for more thoughts on a somewhat related note.

wessberg avatar Oct 08 '18 18:10 wessberg

@trusktr light/shadow trees, what does the "light" means?

lishoulong avatar Oct 11 '21 13:10 lishoulong