- From: David Bokan via GitHub <sysbot+gh@w3.org>
- Date: Fri, 12 Jan 2024 15:38:04 +0000
- To: public-css-archive@w3.org
> But for definition of snapshot containing block is ambiguous for iframes: "all areas of the window that could potentially display page content". The impact it has on clipping of images aside, I think it should be the iframe's ICB Agree, the Snapshot Containing Block for an iframe should be that frame's Initial Containing Block > I'm thinking the following: > * If the iframe is completely offscreen, just skip the transition. Why animate instead of directly flipping to the new state. > * If its onscreen (fully or partially) use the SCB of the top level frame to decide what should be captured in the images. I'm not a fan of making the clipping depend on the iframe's position. Theoretically the owning document could be scrolling or animating the iframe's position so the exposed part could change during the transition. This information might also need to cross process boundaries so could be out of date. It feels rather complex for something that seems to me like an extreme edge case? Why not just do the simple thing and apply the clip in the same way we do for non-root elements? i.e. take the above definition of the snapshot containing block for an iframe and also clip the root to it. It's true that the author might move the iframe so that an area beyond the clipping region is shown but this doesn't seem like something that'll happen in practice (and if there are use cases for it we can discuss it then?). Doing cross-process rect intersections seems like it'll be difficult to get right in implementation and even harder to make interoperable across browsers... FWIW the [bug](https://crbug.com/1516874) where this came up, the reporter mentioned this wasn't a real use case but was found during a certification/stress test. -- GitHub Notification of comment by bokand Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9786#issuecomment-1889525350 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 12 January 2024 15:38:06 UTC