search

w3c / IntersectionObserver

Intersection Observer
https://www.w3.org/TR/intersection-observer/
Other
3.62k stars 523 forks source link

Can we have an option to compound rootMargin values with the "optimal viewing region"/scroll-padding? #371

Open jonjohnjohnson opened 5 years ago

jonjohnjohnson commented 5 years ago

https://drafts.csswg.org/css-scroll-snap-1/#optimal-viewing-region

In the css scroll-snap spec, which I know is separate from the intersection observer spec, a concept called the optimal viewing region is defined, and is set by the scroll-padding property for a scrollport/root. Aside from the property, there has also been talk of heuristics to infer this optimal viewing region from fixpos/stickypos elements obfuscating areas of a scrollport. Either way, when using intersectionObserver I've found myself wanting to compound my rootMargin values off my currently rendered optimal viewing region.

I wonder if @tabatkins can corroborate that I'm making sense here? What do you think @ojanvafai?

szager-chromium commented 5 years ago

It seems like this could be polyfilled (pseudo-code without string conversions or "px" stripping):

new IntersectionObserver(callback, { root: scroller, rootMargin: -getComputedStyle(scroller).scrollPadding });

?

jonjohnjohnson commented 5 years ago

It seems like this could be polyfilled

Sure and this is what I've done, though with more complications like handling the computed value of scroll-padding changing to do relayout or matchMedia updates. But even if it can be hacked in, it could still be aided by a keen "auto optimal viewing region" value for rootMargin, like why intersectionObserver was created as a way to not just polyfill the behavior with scroll events?