Intent to Ship: Intersection Observer

[Kenji Baheux]

Contact emails

sza...@chromium.org, m...@chromium.org

oj...@chromium.org, kenji...@chromium.org

Spec

https://github.com/WICG/IntersectionObserver (Tag Review)

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.

For instance, many third parties have come to rely on scroll handlers, plugins and other polling approaches in order to measure viewability. On mobile, this is particularly unfortunate given the significant negative impact on performance and battery life of such approaches.

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.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/eLxh8xUp3j4/m7RH4_nLBgAJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Debuggability

N/A (no additional devtools functionality needed)

Interoperability and Compatibility Risk

Medium:

• The rough API and use cases were received positively when meeting with other browser vendors in Paris in August. Notes from Paris: http://www.w3.org/2015/08/27-positionobserver-irc

• Since then, we’ve worked with other vendors to surface and address concerns via the github issue tracker. We also reached out to a wide range of interested parties to vet the design and viability of the API.

• Based on these interactions, we believe that we have attain reasonable confidence in the specification and its initial scope

• We have a good coverage of the spec in our test suite and we intend to convert and upstream it to the w3c repo.

OWP launch tracking bug

http://crbug.com/540528

Entry on the feature dashboard

https://www.chromestatus.com/features/5695342691483648

[Rick Byers]

LGTM1

Great coverage of the interop risk - thank you!  It's unfortunate that the tests are all blink-style js-tests rather than W3C-style testharness.js tests.  It's going to take some work to get them up to web-platform-test.  Please make that a priority to help with achieving interop with other implementations!

Rick

[Philip Jägenstedt]

I took a look at the IDL and filed Use FrozenArray<double> for IntersectionObserver's thresholds attribute. The situation is similar to Notifications, and there the problematic attributes have been held back from shipping. Would it make sense to ship IntersectionObserver without the theresholds attribute exposed as well?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Kentaro Hara]

The binding team is planning to support the FrozenArray but I'm not sure if we can make it happen in a week (tracking bug). I'll chat with the team next week.

--

Kentaro Hara, Tokyo, Japan

[Stefan Zager]

On Fri, Mar 11, 2016 at 6:40 AM Philip Jägenstedt <phi...@opera.com> wrote:

I took a look at the IDL and filed Use FrozenArray<double> for IntersectionObserver's thresholds attribute. The situation is similar to Notifications, and there the problematic attributes have been held back from shipping. Would it make sense to ship IntersectionObserver without the theresholds attribute exposed as well?

It can't see how omitting the attribute would be better then returning a non-frozen array.  Either way, we don't conform to the spec.  The current implementation returns a non-frozen array, but modifying the array does not change the behavior of the observer.  So, the out-of-spec behavior is this: modifications to the array do not raise an exception.  Can we live with that for now?

[Domenic Denicola]

From: blin...@chromium.org [mailto:blin...@chromium.org] On Behalf Of Stefan Zager

> It can't see how omitting the attribute would be better then returning a non-frozen array.  Either way, we don't conform to the spec.  The current implementation returns a non-frozen array, but modifying the array does not change the behavior of the observer.  So, the out-of-spec behavior is this: modifications to the array do not raise an exception.  Can we live with that for now?

Does the current implementation cause `observer.thresholds !== observer.thresholds`? If that is the case, we cannot live with it, and should avoid shipping until that can be resolved.

Otherwise, you just have the compat risk that people will start writing code that depends on the mutability, and you will be unable to ship the frozen array variant later. Maybe that is negligible, but I wouldn't be sure.

[Greg Whitworth]

Does the current implementation cause `observer.thresholds !== observer.thresholds`? If that is the case, we cannot live with it, and should avoid shipping until that can be resolved.

Otherwise, you just have the compat risk that people will start writing code that depends on the mutability, and you will be unable to ship the frozen array variant later. Maybe that is negligible, but I wouldn't be sure.

I can't agree with this more, we saw this while implementing srcset and the conflict we had with the Picturefill polyfill doing this very thing (mutating an immutable property). 

[Stefan Zager]

It was suggested to me that there's an IDL incantation that would implement the correct behavior:

interface IntersectionObserver {

    ...

    [CallWith=ScriptState, CachedAttribute=thresholdsDirty] readonly attribute double[] thresholds;

};

IntersectionObserver would define a thresholdsDirty() method that always returns false, so the attribute getter would only be invoked once.  The attribute getter would be responsible for constructing the javascript array of doubles, freezing it and returning it via the ScriptState.

So, the behavior would be correct but the IDL would look kinda weird.

Does that sound reasonable, or would it be better not to ship that attribute?

[Alex Russell]

That seems reasonable to me. I'm mostly concerned that we've got the right semantics outlined (even if it's in prose); IDL beauty isn't something we should optimize for.

--

[Elliott Sprehn]

That's a pretty crazy hack, can you not just do custom bindings and store the array in a hidden property? Constructing the array in core/ seems pretty gross. Maybe it's not much better either way.

[Domenic Denicola]

From: blin...@chromium.org [mailto:blin...@chromium.org] On Behalf Of Stefan Zager

> It was suggested to me that there's an IDL incantation that would implement the correct behavior:

This wouldn't be correct. The "IDL array" type (double[]) has been removed from the latest IDL specification, for a variety of fairly good reasons (like: it's missing a bunch of methods JS programmers expect of arrays; it doesn't pass common tests like instanceof Array or Array.isArray; no two browsers implemented it the same way; and, it's yet another exotic object that we want to eliminate from the platform).

It seems better to just ship without the thresholds property until FrozenArray is implemented.

[Philip Jägenstedt]

Given that this is what happened with Notifications this seems like a
reasonable thing to do. But just to sanity check, is this expected to
be a bigger problem here than for Notifications?

[Stefan Zager]

I don't think it should be a problem to ship without this attribute.  It's only there for convenience; its value is the same as the "thresholds" parameter given to the constructor, and it never changes.

[Kenji Baheux]

On Tue, Mar 22, 2016 at 12:42 AM Stefan Zager <sza...@chromium.org> wrote:

I don't think it should be a problem to ship without this attribute.  It's only there for convenience; its value is the same as the "thresholds" parameter given to the constructor, and it never changes.

+1

Let's go with this approach for now and reconsider later if the missing IDL bits are in place before the branch cut.

[Philip Jägenstedt]

LGTM2

[Chris Harrelson]

LGTM3 for this revised plan.

[Adam Klein]

On Fri, Mar 18, 2016 at 9:43 PM, Domenic Denicola <d...@domenic.me> wrote:

From: blin...@chromium.org [mailto:blin...@chromium.org] On Behalf Of Stefan Zager

> It was suggested to me that there's an IDL incantation that would implement the correct behavior:

This wouldn't be correct. The "IDL array" type (double[]) has been removed from the latest IDL specification, for a variety of fairly good reasons (like: it's missing a bunch of methods JS programmers expect of arrays; it doesn't pass common tests like instanceof Array or Array.isArray; no two browsers implemented it the same way; and, it's yet another exotic object that we want to eliminate from the platform).

To be clear, when Stefan said "IDL incantation" here he meant "Blink IDL" not "WebIDL". The intended incantation would have created an object that passed all those isArray, instanceof checks...

 

It seems better to just ship without the thresholds property until FrozenArray is implemented.

...but I tend to agree that this outcome is still good, as it just means less custom V8 bindings code in core blink.