Polyfill

[jeremenichelli]

In case this goes on I would like to try wirting a polyfill for it, I'm writing this as an issue because I dodn't know how to ask for that chance. Let me know if it's a better way.

[atotic]

You do not need anyone's permission, it's an open standard :)

The spec is not final yet. I am not sure if we'll end up observing clientWidth or something else, there will be a bug filed about this today.

Polyfill is an interesting topic, there is a tension between API correctness, and performance.

The obvious polyfill is to do size polling in requestAnimationFrame. The downside is wasted CPU/power.

Others have tried to create more performant resize detectors: https://github.com/wnr/element-resize-detector/ is very good, but they all have their quirks.

[jeremenichelli]

Thanks for the response @atotic. As soon as I have time I'll fork and branch this to start playing a little with the standard, even if it's not finished it could arise needs or caveats around the API. Also, as I was reading the spec my first idea was to poll using rAF plus some deboucing since it would stop doing it when the tab is not visible and its polyfill is short to include on top of a project.

[atotic]

I will add any polyfill attempts here:

https://github.com/pelotoncycle/resize-observer

[atotic]

https://github.com/que-etc/resize-observer-polyfill

Implements event based tracking of changes in elements dimensions. Uses MutationsObserver and falls back to an infinite dirty checking cycle if the first one is not supported. Handles long running CSS transitions/animations, attributes and nodes mutations along with changes made by :hover pseudo-class (optional).

Written in ES6 and compliant with the spec. Doesn't contain any publicly available methods or properties except for those described in the spec. Size is 4.4kb when minified and gzipped.

[ShimShamSam]

https://github.com/ShimShamSam/ResizeListener
How it works:
Hidden elements are appended to the elements you want to monitor. These hidden elements exploit their scrollbar behavior when they change in size and react to the corresponding scroll events. The events are then aggregated and throttled using requestAnimationFrame (or setTimeout in older browsers) to make a fast and efficient way to listen for changes in element size.

[NekR]

Here is another attempt to watch element resizes. Very simple and straightforward, also small (~350b even not minified). Not a polyfill for this exact spec though.

[atotic]

@NekR you did not include a link?

[NekR]

@atotic oh, sorry, silly me. Here it is: https://github.com/developit/simple-element-resize-detector

[NekR]

I'm using approach from simple-element-resize-detector now in a project to customize browser scrollbars. Works great even on iOS where iframes have its limitations.

[trusktr]

@atotic

The spec is not final yet. I am not sure if we'll end up observing clientWidth or something else, there will be a bug filed about this today.

I really hope not, we need floating point values that represent what is actually rendered on screen. clientWidth and clientHeightare, for all intents and purposes, values aliased to CSS pixels, which means if we observe those then something may be visually changing size on the screen while no ResizeObserver callbacks fire at all.

Content that is on the plane of the display would be fine with clientWidth observation, but not content that is zoomed, and not most of all 3D content. For example, content that is translateZ(200px) (between the display plane and the user's eyes) will visibly grow with flaoting values of width and height (for example, width: 100.234px).

We need to be able to react to those changes and (for example) render WebGL content appropriately without visual disparity bugs that would arise from observing values aliased to CSS pixels.