#756: ContentVisibilityAutoStateChanged event
Discussions
2022-07-London
Yves: can't you do this already
Tess: yes, with IntersectionObserver etc., but it would be clunky & error-prone
[... discussion of what would happen if you had old code doing this the hacky way and new code doing this the new way on the same page ... we eventually concluded that they've covered the relevant concerns, at least as far as we can tell.]
2022-08-29
Yves: we asked about the issue of having a complex and (now) simpler way of doing the same thing and the possible bad interactions... would there be a way to mititage this issue we're raised. They've said they are aware but no way to mitigate.
Tess: at least on par with the rest of the platform... at least they are aware and thought about it. It would be nice if we could break the cycle but in this case...
Dan: they need a "please make sure this is documented"...
<blockquote>Hi @vmpstr,
Thanks again for bringing this to our attention. We're happy with your design and will close this review. We are hoping that you can note (non-normative text would be fine) the possibility of cycles with related features in the spec, so that authors can be warned, but we're not blocking the review on that.
</blockquote>Dan: close with satisfied?
Tess & Yves: Yes
OpenedJul 11, 2022
Hello TAG!
I'm requesting a TAG review of ContentVisibilityAutoStateChanged event.
This proposal is to add an event that would fire on a
content-visibility: auto
element when the rendering state of the element changes due to any of the attributes that make the element relevant to the user.Further details:
We'd prefer the TAG provide feedback as:
💬 leave review feedback as a comment in this issue and @-notify @vmpstr