3 ms·

There is an emerging standard called Intersection Observer that addresses the same use case: https://github.com/WICG/IntersectionObserver/blob/gh-pages/explaine

by cdata 10y ago

There is an emerging standard called Intersection Observer that addresses the same use case: https://github.com/WICG/IntersectionObserver/blob/gh-pages/explainer.md https://github.com/WICG/IntersectionObserver/blob/gh-pages/e... This is a really useful problem to solve. But, I would personally prefer to solve it with a polyfill for a standardized approach that will eventually receive native implementation.

Heqx 10y ago
I hear you. But, isn't this just an editor's draft spec? Only Chrome and Android have done any implementation at all. So, as far as I can tell, there's a chance this will never be fully implemented? And, because it's a draft, the spec could change significantly. Is that right?
- cdata 10y ago
  All the more reason to experiment with the proposed standard API and contribute feedback. The advantages of standardization and eventual native implementation outweigh the immediacy of a JS-based API designed in relative isolation. Why should I invest time learning this micro-library, when the API is certain to be different from the native implementation? The documentation doesn't seem to even acknowledge the existance of the standard (did the author do any research before implementing a one-off library? I have no way of knowing.), much less explain why it differs from the proposed standard.
- spankalee 10y ago
  A spec being draft seems like an odd reason to ignore it and do a completely different API. Intersection Observer has been implemented in Chrome since 51, and Opera since 38. It's currently being implemented in Firefox ( https://bugzilla.mozilla.org/show_bug.cgi?id=1243846 https://bugzilla.mozilla.org/show_bug.cgi?id=1243846 ), and is "likely" from Edge (https://developer.microsoft.com/en-us/microsoft-edge/platform/status/intersectionobserver/ https://developer.microsoft.com/en-us/microsoft-edge/platfor... ). in-view.js's API is certainly less likely to be the cross-platform API than Intersection Observer. Also, plenty of APIs are implemented by browsers at the editor's draft stage.
  - Heqx 10y ago
    I was sincerely asking all of those questions. I'm not very familiar with the process these specs go through to reach adoption.
SimeVidas 10y ago
The repository you linked to, actually contains the official polyfill: https://github.com/WICG/IntersectionObserver/tree/gh-pages/polyfill https://github.com/WICG/IntersectionObserver/tree/gh-pages/p... (it should be about 6 KB minzipped)
- spankalee 10y ago
  And the polyfill defers to the native implementation where available, like Chrome and Opera, for much better performance and responsiveness.
grumblestumble 10y ago
Came here to say this. Recently spent a day hand-rolling my own, much like the author here has, only to rip it out at the end of the day and replace it with a lightweight wrapper around IntersectionObserver, using the polyfill. The API is just great, really well-thought out and much better than what I had come up with. The only downside is that I'd gone to some pain to get everything working with RAF, and the polyfill doesn't bother with that.

by cdata 10y ago

Heqx 10y ago

I hear you. But, isn't this just an editor's draft spec? Only Chrome and Android have done any implementation at all. So, as far as I can tell, there's a chance this will never be fully implemented? And, because it's a draft, the spec could change significantly. Is that right?

cdata 10y ago
All the more reason to experiment with the proposed standard API and contribute feedback. The advantages of standardization and eventual native implementation outweigh the immediacy of a JS-based API designed in relative isolation. Why should I invest time learning this micro-library, when the API is certain to be different from the native implementation? The documentation doesn't seem to even acknowledge the existance of the standard (did the author do any research before implementing a one-off library? I have no way of knowing.), much less explain why it differs from the proposed standard.
spankalee 10y ago
A spec being draft seems like an odd reason to ignore it and do a completely different API. Intersection Observer has been implemented in Chrome since 51, and Opera since 38. It's currently being implemented in Firefox ( https://bugzilla.mozilla.org/show_bug.cgi?id=1243846 https://bugzilla.mozilla.org/show_bug.cgi?id=1243846 ), and is "likely" from Edge (https://developer.microsoft.com/en-us/microsoft-edge/platform/status/intersectionobserver/ https://developer.microsoft.com/en-us/microsoft-edge/platfor... ). in-view.js's API is certainly less likely to be the cross-platform API than Intersection Observer. Also, plenty of APIs are implemented by browsers at the editor's draft stage.
- Heqx 10y ago
  I was sincerely asking all of those questions. I'm not very familiar with the process these specs go through to reach adoption.

SimeVidas 10y ago

The repository you linked to, actually contains the official polyfill: https://github.com/WICG/IntersectionObserver/tree/gh-pages/polyfill https://github.com/WICG/IntersectionObserver/tree/gh-pages/p... (it should be about 6 KB minzipped)

spankalee 10y ago
And the polyfill defers to the native implementation where available, like Chrome and Opera, for much better performance and responsiveness.

grumblestumble 10y ago

Came here to say this. Recently spent a day hand-rolling my own, much like the author here has, only to rip it out at the end of the day and replace it with a lightweight wrapper around IntersectionObserver, using the polyfill. The API is just great, really well-thought out and much better than what I had come up with. The only downside is that I'd gone to some pain to get everything working with RAF, and the polyfill doesn't bother with that.