- From: Trevor Gau via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Mar 2021 20:06:51 +0000
- To: public-css-archive@w3.org
The intersection rectangle might be what is needed, but browsers are not consistent on how it is calculated. I couldn't find any implementation that calculates the intersection rectangle in a manner that I would expect. In fact, I'm not sure the algorithm above is exactly what I am looking for. [Here is a CodePen](https://codepen.io/team/GitHub/pen/BaQXYOE?editors=1111) that demonstrates this. We have a scrollable container (the intersection root) that is 500px tall, with some top padding, a 100px tall element (pink) followed by a 2000px tall element (blue) that is the intersection target. As the container scrolls, we log out the height of the intersection rect. Clearly, when scrolled far enough, we should log 500, since the blue is filling the 500px-tall container, but instead, we log at most 400. The 100px of padding seems to get lost. Chrome and Safari behave the same (modulo decimal precision). Up until recently, so did Firefox, but the latest Firefox works as expected. However, for another issue, change `overflow: auto` on the `#outer` element to `overflow: visible`. After making this change (and re-running the pen), you will see that the height of the intersection rectangle is always 300, even though it should be equivalent to the window height. To @keithamus's point, `getClippingRect` would be a nice addition to `Element`, which would avoid having to set up an IntersectionObserver in the first place, just to have it fire once. The returned rectangle would contain all of the available space that the _element_ has to render itself before getting clipped. -- GitHub Notification of comment by T-Hugs Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6132#issuecomment-806153047 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 24 March 2021 20:06:53 UTC