Gathering detailed insights and metrics for resize-observer-polyfill
Gathering detailed insights and metrics for resize-observer-polyfill
Gathering detailed insights and metrics for resize-observer-polyfill
Gathering detailed insights and metrics for resize-observer-polyfill
@juggle/resize-observer
Polyfills the ResizeObserver API and supports box size options from the latest spec
resize-observer-lite
A ResizeObserver polyfill that has limited functionality of ResizeObserver.
resize-observer
An implementation and polyfill of the Resize Observer draft.
element-resize-event-polyfill
Native event listener polyfill to capture element size changes
npm install resize-observer-polyfill
Typescript
Module System
Node Version
NPM Version
JavaScript (100%)
Total Downloads
0
Last Day
0
Last Week
0
Last Month
0
Last Year
0
MIT License
1,758 Stars
99 Commits
132 Forks
12 Watchers
17 Branches
4 Contributors
Updated on Jun 19, 2025
Latest Version
1.5.1
Package Id
resize-observer-polyfill@1.5.1
Size
31.97 kB
NPM Version
6.4.1
Node Version
11.0.0
Published on
Dec 09, 2018
Cumulative downloads
Total Downloads
Last Day
0%
NaN
Compared to previous day
Last Week
0%
NaN
Compared to previous week
Last Month
0%
NaN
Compared to previous month
Last Year
0%
NaN
Compared to previous year
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).
From NPM:
1npm install resize-observer-polyfill --save-dev
From Bower: (will be removed with the next major release)
1bower install resize-observer-polyfill --save-dev
Polyfill has been tested in the following browsers:
NOTE: Internet Explorer 8 and its earlier versions are not supported.
It's recommended to use this library in the form of a ponyfill, which doesn't inflict modifications of the global object.
1import ResizeObserver from 'resize-observer-polyfill'; 2 3const ro = new ResizeObserver((entries, observer) => { 4 for (const entry of entries) { 5 const {left, top, width, height} = entry.contentRect; 6 7 console.log('Element:', entry.target); 8 console.log(`Element's size: ${ width }px x ${ height }px`); 9 console.log(`Element's paddings: ${ top }px ; ${ left }px`); 10 } 11}); 12 13ro.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.
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:
<img>
, <input>
, <textarea>
, <canvas>
, <tr>
, <tbody>
, <thead>
, <table>
, etc. For most of them you would need to keep an extra <div>
wrapper and almost all instances of the SVGGraphicsElement will be out of scope.display: none
state. Same goes for when it's being removed from or added to the DOM. It's not possible to handle these cases merely by using former approaches, so you'd still need to either subscribe for DOM mutations or to continuously check the element's state.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.
:hover
and :focus
, are not tracked. As a workaround you could add a short transition which would trigger the transitionend
event when an element receives one of the former classes (example).To build polyfill. Creates UMD bundle in the dist
folder:
1npm run build
To run a code style test:
1npm run test:lint
Running unit tests:
1npm run test:spec
To test in a browser that is not present in karma's config file:
1npm run test:spec:custom
Testing against a native implementation:
1npm run test:spec:native
NOTE: after you invoke spec:native
and spec:custom
commands head to the http://localhost:9876/debug.html
page.
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
Found 4/24 approved changesets -- score normalized to 1
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Reason
72 existing vulnerabilities detected
Details
Score
Last Scanned on 2025-07-07
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More