Intent to Implement: Intersection Observer

1,786 views
Skip to first unread message

Michael Blain

unread,
Oct 7, 2015, 12:10:40 AM10/7/15
to blin...@chromium.org
Contact emails
m...@chromium.org, oj...@chromium.org 

Spec

Summary
This specification describes an API that can be used to understand the visibility and position of DOM elements relative to a viewport. The position is delivered asynchronously and is useful for understanding the visibility of elements and implementing pre-loading and deferred loading of DOM content.
https://github.com/slightlyoff/IntersectionObserver/blob/master/explainer.md 

Motivation
Accurately measuring viewability is important for several use cases; deferred-loading or lazy-loading of content, infinite-scroll lists and advertising. Because there is no standard way to get viewable information across browsers, developers have built and rely on a series of browser-specific hacks and workarounds. Sites rely on scroll handlers and plugins in situations where they really aren't necessary, impacting performance. Intersection Observer addresses this need by introducing a new API to asynchronously report on the relative positions of elements without interrupting the critical paths of rendering or processing.

Compatibility Risk
Low. The rough API and use cases were received positively when meeting with other browser vendors in Paris in August. Some of the decisions around behaviors of edge cases need a fresh review though. Notes from Paris: http://www.w3.org/2015/08/27-positionobserver-irc

Ongoing technical constraints
None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no. 
Yes 

OWP launch tracking bug

Link to entry on the Chrome Platform Status

Requesting approval to ship?
No.

Ilya Grigorik

unread,
Oct 7, 2015, 6:36:47 PM10/7/15
to Michael Blain, blink-dev
Really happy to see this! The "visibility and position relative to viewport" use case is a common request in many webperf discussions: analytics, prioritization of visible content, smart(er) pre- and deferred loading strategies, etc. Current approaches for "solving" this are really costly and don't work well... In short, +1; this is a really important building block.

QQ: setting the margin to "200vh 0" would let me know when the observed element is ~2 screens away?

reinek...@gmail.com

unread,
Oct 8, 2015, 8:13:01 PM10/8/15
to blink-dev, m...@chromium.org, igri...@google.com
Wouldn't setting a "200vh" threshold via the IntersectionObserverInit dictionary be a more expected way to accomplish that same behavior?

What would happen when the threshold is a negative value?

Michael Blain

unread,
Oct 8, 2015, 8:16:04 PM10/8/15
to reinek...@gmail.com, blink-dev, Ilya Grigorik
'Threshold' is meant to to be the percentage on-screen you care about.
For some (most?) use cases, this will be "1px" because if a single pixel of your element is intersecting with the root, you want a trigger.
For some use cases (ads?, chat widgets?) there are different thresholds they care about, 50% on-screen or 100% on-screen or some other range.
I think Ilya's use of 'rootMargin' is the intended use here.

Yoav Weiss

unread,
Oct 9, 2015, 2:16:02 AM10/9/15
to Michael Blain, reinek...@gmail.com, blink-dev, Ilya Grigorik
On Thu, Oct 8, 2015 at 11:16 PM, Ilya Grigorik <igri...@google.com> wrote:
Hey all, fyi... Still in early stages, but this is *highly* relevant to the many use cases we've discussed on this list around deferred loading, element visibility, etc. For a more hands-on overview, check out the explainer: https://github.com/slightlyoff/IntersectionObserver/blob/master/explainer.md
 
+1 
Super excited to see this being implemented! This would make both lazy loading and visibility based perf metrics significantly easier.

I know it's still very early, but any word from other vendors?

On Fri, Oct 9, 2015 at 2:15 AM, Michael Blain <m...@chromium.org> wrote:
'Threshold' is meant to to be the percentage on-screen you care about.
For some (most?) use cases, this will be "1px" because if a single pixel of your element is intersecting with the root, you want a trigger.
For some use cases (ads?, chat widgets?) there are different thresholds they care about, 50% on-screen or 100% on-screen or some other range.
I think Ilya's use of 'rootMargin' is the intended use here.

Would negative values be possible as well? e.g. "-50vh" for getting a trigger when the element is half a viewport height away? 

rhondah...@gmail.com

unread,
Nov 20, 2018, 4:22:27 PM11/20/18
to blink-dev
Help please I want to keep my Google Chrome account has pictures of my only child I lost that's all I have any help would be greatly appreciated thank you Rhonda Holbrook
Reply all
Reply to author
Forward
0 new messages