- From: Noam Rosenthal via GitHub <sysbot+gh@w3.org>
- Date: Thu, 16 Nov 2023 06:58:20 +0000
- To: public-css-archive@w3.org
> One of the open questions for this feature is defining when an element is considered visible. There's 2 aspects to it: > > > > - Intersection with the viewport (snapshot root from VT perspective). Ideally we'd use the element's ink overflow rect for it. IntersectionObserver already uses ink overflow rect to detect occlusion [here](https://w3c.github.io/IntersectionObserver/v2/#:~:text=Implementations%20should%20use%20the%20ink%20overflow%20rectangle%20of%20page%20content%20when%20determining%20whether%20a%20target%20is%20occluded). And #8649 is in progress to make the ink overflow bounds interoperable. > > > > - Occlusion by other elements on the page. I haven't seen a use-case where a named element was occluded so I don't know if we need to consider it. Occlusion calculations are also more expensive so better if we can avoid it. In either case I think we should be consistent with IntersectionObserver. For viewport intersection IntersectionObserver doesn't take the ink overflow into account, so this shouldn't either. If IO exposed ink overflow in some way, eg for occlusion, we could consider doing the same. Note that with a big enough root margin, being accurate about the ink overflow becomes less important. -- GitHub Notification of comment by noamr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8282#issuecomment-1813887560 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 16 November 2023 06:58:21 UTC