Resize Observer

Resize Observer - HTTP203

Рет қаралды 12,682

6 жыл бұрын

Surma and Jake Archibald discuss observers on todays #HTTP203 -
Surma's blog post: goo.gl/qlyOHk
Subscribe to Chrome Developers here: goo.gl/LLLNvf
Watch more HTTP203: goo.gl/bTQMrY
Listen to the HTTP203 podcast for a full hour conversation & more: goo.gl/LR7gNg
Itunes: goo.gl/cf2yRq

Пікірлер: 27

@aidemalo 6 жыл бұрын

Finally, was waiting for it the whole life

@olivierfaure5896 11 ай бұрын

1:07 "The reason we can't just have element queries is because you can end up with a query which changes based on width. And as a result, it changes width and you end up in an infinite loop." Well good news from the future! There are now CSS containers queries which address this use-case. Using them forces the container element to use the "contain" property which essentially says "size this element as if it had no children" (in other words, the parent size can't depend on the children), which prevents the loops described here. There's still _some_ potential for loops that browsers are busy ironing out, but it's a pretty clever idea overall.

@HZStudio 2 жыл бұрын

Finally used this after learning about it a long time ago

@malipetek 5 жыл бұрын

How do you prevent loop under the hood?

@chris-eg 6 жыл бұрын

"the change is only processed in the same frame if the resized element is deeper on the dom tree than the shallowest element processed in the previous callback" ok...But when it is processed (in the next frame), does that trigger the resize event? (causing the infinite loop)

@dassurma 6 жыл бұрын

That depends on the code that you run in your resize observer. So it's up to you to not build infinite loops. But if you do, resize observer will break them up across multiple frames.

@NipunaGunathillake 6 жыл бұрын

So what the resize observer does ensure is that an infinite loop does not occur in the same frame?

@dassurma 6 жыл бұрын

yes

@arleytriana01 4 жыл бұрын

@@dassurma Yes, but in some scenarios, you can still get a ResizeObserver loop limit exceeded error. => github.com/elastic/kibana/issues/22913

@JIJzerman 4 жыл бұрын

Apparently they thought harder about avoiding infinite loops than when MS implemented onpropertychange in old IE.

@user-mo3cw6go7c 3 жыл бұрын

Hooow is the funny guy from the loop talking. 😍😍😍

@BennyPowers 6 жыл бұрын

Only discussion of browser support was a sideways swipe at other browsers 😠

@dwighthouse 6 жыл бұрын

Glad this is becoming standard. It also has uses for detecting things that are otherwise very hard to detect, such as detecting when a font has loaded or deciding how many items to keep in the buffer when doing an infinite scrolling list. There are ways to detect element resizes without this, but they are all hacks.

@dassurma 6 жыл бұрын

I don’t think ResizeObserver should be used to detect when a font has loaded or what is on screen. That’s what Font Loading API and IntersectionObserver are for, respectively. Or am I misunderstanding you?

@dwighthouse 6 жыл бұрын

I make a font detection library called onfontready ( github.com/dwighthouse/onfontready ). It needs to detect when a font is loaded and ready to use. Font Loading API is unsupported on all versions of IE and, at time of writing, all versions of Edge ( caniuse.com/#feat=font-loading ). My library supports IE6 and up. Furthermore, it can detect other things the Font Loading API can't. onfontready can be used to detect support for a generic font name (like "-apple-system" ). It can also detect if a given font is already loaded in the page or installed on the user's system WITHOUT triggering a download of that font. It does all this in less than 500 bytes, designed for inlining on every page, if a site's loading structure needs it. By adding Resize Observer support (which is planned), I can add a couple dozen more bytes to the size of my library and significantly reduce the processing and time required to do the detection operation on browsers that support it.