Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Observing the entire document for everything may be too heavy? #41

Open
trusktr opened this issue Sep 6, 2018 · 2 comments
Open

Observing the entire document for everything may be too heavy? #41

trusktr opened this issue Sep 6, 2018 · 2 comments

Comments

@trusktr
Copy link

trusktr commented Sep 6, 2018

this.mutationsObserver_ = new MutationObserver(this.refresh);
this.mutationsObserver_.observe(document, {
attributes: true,
childList: true,
characterData: true,
subtree: true
});

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.

@wessberg
Copy link

wessberg commented Oct 8, 2018

@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 whatwg/dom#533 (comment) for more thoughts on a somewhat related note.

@lishoulong
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants