- From: Chris Harrelson via GitHub <noreply@w3.org>
- Date: Tue, 30 Sep 2025 17:09:59 +0000
- To: public-css-archive@w3.org
> No, were talking about different loops. I'm talking about the interleaved style / layout loop, not the html rendering steps. > > That is, in WebKit this runs during forced layouts like getBoundingClientRect for example ([@fantasai](https://github.com/fantasai) or [@anttijk](https://github.com/anttijk) can correct me if I'm wrong). I see. I don't think that behavior is the best approach, because it will be slower (the browser will have to compute clips on every single forced layout) without any useful user or developer benefit that I can see. Updating the visibility during animation frame generation will still avoid the lagging across frames problem that @fantasai (rightly) mentioned. ---- On the topic of clips, I did say above that "I also don't think other clips need to be taken into account, because it's just a scrolling effect due to the user agent controlling scrolling, not any other visual effect", and it's probably true that they don't strongly *need* to be taken into account if it were inconvenient, but I don't see a harm in taking them into account. Further, such clips do indeed hide the thing visually to the user, so there is a user benefit to including clip-path and other clips in the computation. And since all browsers implement `IntersectionObserver`, which does include such clips, I think it should be straightforward and likely more performant to include them (it certainly is in Chromium). -- GitHub Notification of comment by chrishtr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12732#issuecomment-3353090334 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 30 September 2025 17:09:59 UTC