- From: Chris Harrelson via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Jul 2022 16:16:25 +0000
- To: public-css-archive@w3.org
> Can you describe the exact timing of when this event is fired? We don't want it to reveal exactly when the UA does style updates or layout, so I would prefer that it fire during the "update the rendering steps" somewhere. It should fire during the same timing as `IntersectionObserver` callbacks, i.e. in a posted event loop task after the observer fires. (`content-visibility:auto` is [already defined](https://drafts.csswg.org/css-contain/#cv-notes) in terms of `IntersectionObserver` timings.) Therefore the feature would not expose the exact timing of style or layout. > * Are we sure this is different from an `IntersectionObserver`? It's not different. But this event allows a web app to subscribe to the implicit UA-internal `IntersectionObserver` without having to (a) add more javascript that duplicates it and slows down the page, and (b) reverse-engineer the (UA-dependent) margin chosen by the UA. > * How about `ContentVisibilityStateChanged`? This might apply to values other than auto in the future. This name SGTM. -- GitHub Notification of comment by chrishtr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7384#issuecomment-1176418942 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 6 July 2022 16:16:26 UTC