Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intersection Observer v2 #441

Closed
1 of 3 tasks
BearCooder opened this issue Sep 18, 2023 · 8 comments
Closed
1 of 3 tasks

Intersection Observer v2 #441

BearCooder opened this issue Sep 18, 2023 · 8 comments
Labels
focus-area-proposal Focus Area Proposal

Comments

@BearCooder
Copy link

BearCooder commented Sep 18, 2023

Description

This is a resubmission of the Intersection Observer v2 from last year Interop proposal.

Intersection Observer v2 introduces the concept of tracking the actual "visibility" of a target element as a human being would define it. By setting an option in the IntersectionObserver constructor, intersecting IntersectionObserverEntry instances will then contain a new boolean field named isVisible. A true value for isVisible is a strong guarantee from the underlying implementation that the target element is completely unoccluded by other content and has no visual effects applied that would alter or distort its display on screen. In contrast, a false value means that the implementation cannot make that guarantee.

An important detail of the spec is that the implementation is permitted to report false negatives (that is, setting isVisible to false even when the target element is completely visible and unmodified). For performance or other reasons, browsers limit themselves to working with bounding boxes and rectilinear geometry; they don't try to achieve pixel-perfect results for modifications like border-radius.

That said, false positives are not permitted under any circumstances (that is, setting isVisible to true when the target element is not completely visible and unmodified).

The IntersectionObserver constructor now takes two additional configuration properties: delay and trackVisibility. The delay is a number indicating the minimum delay in milliseconds between notifications from the observer for a given target. The trackVisibility is a boolean indicating whether the observer will track changes in a target's visibility.

This information is from the following source

Supporting links:

Delay
TrackVisibility
isVisible

Slides

Specification

https://w3c.github.io/IntersectionObserver/v2/

Open Issues

No response

Tests

https://wpt.fyi/results/intersection-observer/v2?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned&view=subtest

Current Implementations

  • Blink
  • Gecko
  • WebKit

Standards Positions

Browser bug reports

No response

Developer discussions

No response

Polls & Surveys

No response

Existing Usage

Workarounds

No response

Accessibility Impact

No response

Privacy Impact

No response

Other

V2 is supported by Chrome but not on Firefox and Safari. Its not even mentioned in the MDN doc, an open issue for the MDN doc is open here mdn/content#19201

Chrome, Edge, Safari and Firefox have shipped V1 of IntersectionObserver. The V2 proposal is a relatively small change to the spec, but unfortunately not supported by all.

@BearCooder
Copy link
Author

With 1. October we can see a jump to 6.4: https://chromestatus.com/metrics/feature/timeline/popularity/3051

@npdoty
Copy link

npdoty commented Oct 3, 2023

This interop focus proposal -- and the linked version of the spec -- makes no mention of the privacy impacts of an API apparently designed primarily to reveal information about what the user has seen to third parties.

@gsnedders
Copy link
Member

Specification

https://w3c.github.io/IntersectionObserver/v2/

What's the status of the spec? This v2 draft is dated 2019, and links to https://www.w3.org/TR/intersection-observer/ as the "latest published version" (which appears to be v1, but 2023). Is there no FPWD of v2? If so, it would appear the spec doesn't meet the bar we asked for, for W3C documents (REC-track).

@szager-chromium
Copy link

@gsnedders -- we're trying to build consensus among browser vendors to implement this spec (issue). If that's successful, then my plan is to create a PR for the main branch of the spec repository containing all of the V2 language.

@wpt-interop
Copy link

Thank you for proposing Intersection Observer v2 for inclusion in Interop 2024.

We wanted to let you know that this proposal was not selected to be part of Interop this year.

As of the deadline, the specifications for Intersection Observer v2 were not yet complete enough to allow interoperable implementations. To make progress on this area in the future, it will first be necessary to ensure that the feature has a clear specification in a standards track document.

For an overview of our process, see proposal selection. Thank you again for contributing to Interop 2024!

Posted on behalf of the Interop team.

@bkardell

This comment was marked as duplicate.

@BearCooder
Copy link
Author

Hello @szager-chromium any progress on ths spec? Chrome's usecounter is at over 8% of pageloads.

@szager-chromium
Copy link

@BearCooder -- Mozilla has taken a positive standards position, and the V2 feature set has been merged into the spec. The only thing left to do is to implement it in all browsers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
focus-area-proposal Focus Area Proposal
Projects
Status: Done
Development

No branches or pull requests

6 participants