A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

Resize event for elements

trusktr
2016-09-03

Listening to size changes on elements is currently an abominable pain.

It’d be nice if there was simply a resize event for any HTMLElement, not just the window.

Performance shouldn’t really be a problem. At some point in the code path there is a size calculation for a given element, and simply calling callbacks at that point IFF any exist should be perfectly fine. So, the only perf hit would be the conditional statement that checks if any callbacks exist.

Elements that have been resized could be pushed into a list, then the list iterated over after all layout sizing is complete and the callbacks called all at once (in a batch).

trusktr
2016-09-03

Oops, this is duplicate of Resize event on DOM elements.

simevidas
2016-09-05

Have you seen the Resize Observer API? It’s available in Chrome Canary behind “Web Platform” flag (chrome:flags page).

Status page: https://www.chromestatus.com/feature/5705346022637568

tabatkins
2016-09-08

Yup, ResizeObserver is the way to do this, actively being standardized as we speak.

It helps avoid resize loops by batching up all the observer calls, running them, then batching up all the new observer calls on children of the root, running them, then batching up all the new observer calls on grandchildren of the root, running them, etc. If you ever break that pattern and produce a new observer call at a higher level than it’s currently evaluating, that’ll get held until the next frame, and will throw an async error at Window so you can tell you’ve done something wrong (or some library has).