Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use ResizeObserver #42

Open
ausi opened this issue Jun 8, 2017 · 8 comments
Open

Use ResizeObserver #42

ausi opened this issue Jun 8, 2017 · 8 comments
Assignees

Comments

@ausi
Copy link
Owner

ausi commented Jun 8, 2017

Use the new ResizeObserver API to watch the size of container elements that have width or height queries attached.

@ausi ausi self-assigned this Jun 8, 2017
@tomhodgins
Copy link

This should be a boost in performance where you can use it. Have you decided how you'll handle this in browsers that don't support resizeObserver? Will they use a different version of the plugin, or will it keep a workaround for weaker browsers?

@ausi
Copy link
Owner Author

ausi commented Jun 16, 2017

My current plan is to offer a configuration option where you can pass a ResizeObserver polyfill if you want to use one. Otherwise it will fall back to the global ResizeObserver if available.

cq-prolyfill doesn’t currently watch for resizing of elements, it only reacts to the window resize event and to inserted DOM nodes. So If you choose not to use a ResizeObserver polyfill only the window resize event will trigger the script.

How do you handle resizing elements in EQCSS?

@tomhodgins
Copy link

cq-prolyfill doesn’t currently watch for resizing of elements, it only reacts to the window resize event and to inserted DOM nodes.

Hey @ausi :D We do it the exact same way in EQCSS, and with the goal of maintaining IE8 support (the browser before CSS media queries) I'm not sure we'll ever do things differently in EQCSS.

There is a lot of benefit to using a resize observer, and also mutation observers in the browsers that support them for hinting to your plugin that a recalculation might be needed, so in newer plugins targeted only at more recent browsers I'd definitely take advantage of them! :D

@ausi
Copy link
Owner Author

ausi commented Jun 27, 2017

I think ResizeObservers are perfectly suitable as an enhancement. We can use them soon, even if we still support older browsers.

But regarding browser support, I will probably raise the minimum IE version from 9 to 11 in one of the next releases. I don’t think it is necessary to support an old insecure browser with less than 0.5% market share, especially at the expense of other browsers.

@eeeps
Copy link

eeeps commented Jun 27, 2017

FYI Chrome might ship ResizeObserver in July: https://twitter.com/atotic/status/875754054780985344

Also, the Firefox implementation is most-of-the-way-there-but-stalled: https://bugzilla.mozilla.org/show_bug.cgi?id=1272409 Looks like there’s nothing but the lack of developer-bandwidth holding it back. (I’m super curious to see what WICG/resize-observer#17 looks like in practice)

@ausi
Copy link
Owner Author

ausi commented Jun 29, 2017

As an alternative for browsers that don’t support ResizeObserver, we could listen to some events that might trigger resizing of elements, like window.resize, animationiteration, animationcancel, animationend, transitioncancel, transitionend.

Maybe also observe changes to DOM attributes via MutationObserver, but this would reevaluate all container queries if a class name on the body element gets added. Might be too bad for performance.

@ZeeCoder
Copy link

@ausi @tomhodgins @eeeps Chrome 64 will ship ResizeObserver.
To see the difference it makes, load this demo in both 63 and 64: https://twitter.com/ZeeCoder/status/951171243264303104

@ausi
Copy link
Owner Author

ausi commented Jan 10, 2018

Great 🎉🎊👍

So I need to hurry up now to get this implemented in the next version :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants