ResizeObserver is an API for observing changes to elements size.
Here is an explaner: https://github.com/atotic/ResizeObserver/blob/master/explainer.md
Most of the discussions of the API have happened inside Google. We’d like to open the discussion to the outside. To facilitate that, we would like to transfer ResizeObserver repo to the WICG.
Exciting stuff! I’d be happy to help to bring the repo into the WICG. Let’s discuss the gory details by mail.
@atotic Could you clarify example 1? I don’t understand the <div id="content"> inside the iframe. Iframes load documents via the src attribute, and their contents are empty. From my understanding, placing text or elements inside an iframe serves as a fallback for browsers that don’t support iframes.
You are right, that example is invalid use of HTML. Just imagine that the <iframe> had a src attribute whose body was the content div. I’ll fix it. Ideally, I’d love to have a cleaner use case instead.
I wonder if this sort of layout-triggered feature might be solved by Houdini? It’s a proposal / prototype for the “ServiceWorker for CSS”: https://groups.google.com/a/chromium.org/forum/#!topic/input-dev/l0F4JfDospw
With hooks in the layout process, it’ll be possible to interrogate and manipulate layouts as they occur.
Hi @jokeyrhyme, it is a subtly different problem space than what the css-layout-api is trying to solve.
Most use-cases for ResizeObserver are to create/remove DOM based on you current size. A lot the use-cases for “element queries” are satisfied by this. For example when a menu-bar in an app is too small, display a drop-down-menu with the items instead.
The css-layout-api is explicitly trying to write css layouts in author code performantly, at this stage of the pipeline you don’t have elements to refer to and manipulate.
^-^ Ian
ResizeObserver explainer has been updated: new rationale, simplified API, more details on error handling.
Comments welcome…
Another use case is observing CSS Resize: https://developer.mozilla.org/en-US/docs/Web/CSS/resize