Clipping ignored due to "containing block" usage

[jakearchibald]

https://static-misc-3.glitch.me/scroll-layout-test/intersection-demo-reduced.html

In this demo, a position: fixed element and a position: absolute element is entirely clipped by its parent.

Chrome: Neither intersecting.
Firefox & Safari: Both intersecting.

It seems like Firefox & Safari are getting it right according to the spec, but it's probably the spec that's wrong, since Chrome's result seems the most reasonable.

The problem in the spec is here I think: https://w3c.github.io/IntersectionObserver/#compute-the-intersection

Let container be the containing block of target.

The problem here is that the "containing block" for absolute & fixed elements 'skips over' the element that's causing the clipping.

I think the spec needs to be updated so that clip-path on all ancestor elements is considered. However, overflow clipping should be ignored unless it's part of the containing block chain.

[jakearchibald]

@emilio @annevk would you be happy with a spec change & tests that defines what Chrome is doing here? It seems to match the intent of the feature.

[emilio]

Firefox doesn't take clip-path into account for IntersectionObserver, that's bug 1319140. But yeah, the spec seems wrong.

[wangxianzhu]

@szager-chromium Actually Chrome's behavior is not consistent. It uses two code paths to calculate the intersection rect. The mostly used code path supports css clips, clip-paths and masks, while the other rarely used code path doesn't. How about keeping the current spec, and changing chrome to ignore css clips, clip-paths and masks? These things don't follow the containing block chain, amd make things complicated and difficult to optimize unnecessary intersection computations. It seems good to make intersection observer v1 just to consider overflow clips because v2 will consider them in visibility.