IntersectionObserver V2

[szager-chromium]

こんにちはTAG！

I'm requesting a TAG review of:

• Name: IntersectionObserver V2
• Specification URL: https://szager-chromium.github.io/IntersectionObserver/
• Explainer, Requirements Doc, or Example code: https://github.com/szager-chromium/IntersectionObserver/blob/master/explainer.md
• Tests: https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/web_tests/intersection-observer/v2/
  https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/web_tests/http/tests/intersection-observer/v2/
• Primary contacts: szager-chromium

Further details (optional):

• Relevant time constraints or deadlines: [please provide]
• I have read and filled out the Self-Review Questionnare on Security and Privacy.
• I have reviewed the TAG's API Design Principles

You should also know that...

This feature is currently implemented in chromium, hidden behind a flag:

--enable-blink-features=IntersectionObserverV2

There are some ham-fisted demos:

https://szager-chromium.github.io/IntersectionObserver/demo/cashbomb/hammerz/
https://szager-chromium.github.io/IntersectionObserver/demo/cashbomb/hidden/
http://szager-chromium.github.io/IntersectionObserver/demo/cashbomb/transparent/
http://szager-chromium.github.io/IntersectionObserver/demo/svg/

We'd prefer the TAG provide feedback as (please select one):

• open issues in our Github repo for each point of feedback: https://github.com/szager-chromium/IntersectionObserver/issues
• open a single issue in our Github repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

[slightlyoff]

Hey @szager-chromium!

The demos are killer and really help to show the feature off. Would be easier to run if wired into chrome://flags/#enable-experimental-web-platform-features

Per conversation on the HTML5 integration issue for V1, it seems like the timing issues raised there haven't been addressed in V2. Any chance that we can get movement on the aspects @dbaron raised there?

Regarding the V2 spec an explainer, a few things seem missing:

• A discussion of considered alternatives. What other solutions could address these use-cases and why aren't they the right solution?
• Updated and expanded example code. How does the new design work (in sample code) to solve the issues that motivate V2? Given that the spec itself doesn't have much in the way of example code, this seems useful.
• Perhaps some discussion of implementation considerations?

Thanks again.

[szager-chromium]

I just added a comment to the V1 TAG review addressing the timing issue.

I also added the stuff you mentioned to the explainer for V2 (alternatives considered, implementation considerations, and sample code).

[dbaron]

So as discussed starting in the third bullet of mozilla/standards-positions#109 (comment) (though I believe there's been a bit of progress since that comment), one of my concerns is that it's not clear to me that this is specified in a way that will give sufficient interoperability -- and this is particularly important because the basic use case for the spec seems to be the desire to deny users access to content when it's being used in a way that is unexpectedly insecure (e.g., being partly obscured or interfered with by the page containing the <iframe>. If the conditions that are considered interference are different between browsers, then this could lead to users of some browsers being denied access to the content in the normal use case. In other words, getting interoperability right here is particularly important because the use case is a security mechanism that will lead to users being denied access to content.

[slightlyoff]

AI for me to invite @szager-chromium to our next call to discuss in a high-bandwidth way with @dbaron.

[dbaron]

I think the basic justification for this feature is reasonable, but features that are designed to deny access to content need to be done particularly carefully. My biggest concern is that a feature whose purpose is to deny access to content needs to be handled particularly carefully so that it doesn't inadvertently deny access to content in cases that the authors of the content or the designers of the feature didn't think of.

One aspect of this (and the one I've talked about so far in mozilla/standards-positions#109) is that it needs to be specified precisely enough to be interoperable, which includes having the definitions that it depends on (such as visual overflow) being specified precisely enough as well. This is needed to avoid harmful effects on browser competition.

It's possible there are other concerns that need to be thought through. For example, interventions that modify the page to aid accessibility for users with poor vision or particular color requirements, or that modify the page for other reasons (say, text size inflation on mobile) could also change the results of this API and thus render content inaccessible.

[dbaron]

Discussed on the teleconference today; Stefan said he'd look in to getting work done on specifying the things this depends on (sounds like visual overflow is the main thing), and we'll cycle back to this issue at our May face-to-face or perhaps later.

[dbaron]

@szager-chromium curious if there's been progress on the previous comment?

[szager-chromium]

@dbaron No, sorry; it's on my short list, but I haven't done anything with it yet.

[hober]

Hi,

@dbaron, @plinss, and I took a look at this at our Cupertino F2F. It seems like we're still waiting on updates to this proposal and related work based on @dbaron's feedback of December 2018 and March 2019. For the time being, we'll close this issue and mark it as timed out. If you do make updates based on our earlier rounds of feedback, please file a new request or let us know and we can re-open this one. We hope that you will consider our previous rounds of feedback prior to shipping.