Home

Awesome

ResizeObserver Polyfill

Build Status

A polyfill for the Resize Observer API.

Implementation is based on the MutationObserver and uses Mutation Events as a fall back if the first one is not supported, so there will be no polling unless DOM changes. Doesn't modify observed elements. Handles CSS transitions/animations and can possibly observe changes caused by dynamic CSS pseudo-classes, e.g. by :hover.

Follows the spec and the native implementation. The size is 2.44 KiB when minified and gzipped.

Live demo (has style problems in IE10 and lower).

Installation

From NPM:

npm install resize-observer-polyfill --save-dev

From Bower: (will be removed with the next major release)

bower install resize-observer-polyfill --save-dev

Browser Support

Polyfill has been tested in the following browsers:

Build Status

NOTE: Internet Explorer 8 and its earlier versions are not supported.

Usage Example

It's recommended to use this library in the form of a ponyfill, which doesn't inflict modifications of the global object.

import ResizeObserver from 'resize-observer-polyfill';

const ro = new ResizeObserver((entries, observer) => {
    for (const entry of entries) {
        const {left, top, width, height} = entry.contentRect;

        console.log('Element:', entry.target);
        console.log(`Element's size: ${ width }px x ${ height }px`);
        console.log(`Element's paddings: ${ top }px ; ${ left }px`);
    }
});

ro.observe(document.body);

Package's main file is a ES5 UMD bundle that will be swapped with the ES6 modules version for those bundlers that are aware of the module field, e.g. for Rollup or webpack 2+.

Note: global version of the polyfill (dist/ResizeObserver.global) is deprecated and will be removed in the next major release.

Observation Strategy

As mentioned above, this implementation primarily (but not solely) relies on Mutation Observer with a fallback to Mutation Events for IE 9 and IE 10.

Speaking of Mutation Events as a fallback approach: they might not be as ugly as they are being rendered, particularly when their calls are batched, throttled and there is no need to analyze changes. Given that, they won't interrupt browser's reflow/repaint cycles (same for MutationObserver) and may even outperform Internet Explorer's implementation of MO causing little to no performance degradation. In contemporary browsers (Chrome, Firefox, etc.) Mutation Observer slows down the suite that includes 200 iterations of adding/removing elements, changing attributes and modifying text data by less than 1%. Internet Explorer gives different results with MO slowing down the same suite by 2-3% while Mutation Events show the difference of ~0.6%.

As for the reasons why other approaches, namely the iframe/object and scroll strategies, were ruled out:

And though every approach has its own limitations, I reckon that it'd be too much of a trade-off to have those constraints when building a polyfill.

Limitations

Building and Testing

To build polyfill. Creates UMD bundle in the dist folder:

npm run build

To run a code style test:

npm run test:lint

Running unit tests:

npm run test:spec

To test in a browser that is not present in karma's config file:

npm run test:spec:custom

Testing against a native implementation:

npm run test:spec:native

NOTE: after you invoke spec:native and spec:custom commands head to the http://localhost:9876/debug.html page.