ContentVisibilityAutoStateChanged event

[vmpstr]

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.

• Explainer¹ (minimally containing user needs and example code): explainer
• Specification URL: This will be an amendment to css-contain spec. I will update the issue once the spec text is available.
• Security and Privacy self-review²: self-review
• Primary contacts (and their relationship to the specification):
  • Vladimir Levin (@vmpstr, Google)
  • Tab Atkins (@tabatkins, Google)
• Organization(s)/project(s) driving the specification: Google
• Key pieces of existing multi-stakeholder review or discussion of this specification: CSSWG discussion
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5179553291436032

Further details:

• [x] I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: None
• The group where the work on this specification is currently being done: CSSWG
• Major unresolved issues with or opposition to this specification: None
• This work is being funded by: Google

We'd prefer the TAG provide feedback as:

💬 leave review feedback as a comment in this issue and @-notify @vmpstr

[hober]

@ylafon and I took a look at this during our London F2F this week and, broadly speaking, this seems reasonable to us. We're wondering if you've thought about this edge case, though:

Say you have a large website that many developers have hacked on. Before the introduction of this feature, someone does something roughly equivalent with IntersectionObserver and MutationObserver as you've alluded to. Later, after the introduction of this feature, someone does something else on the same site, with the same subtree, with the new element. Is there any risk that this new event handler could cause a cycle with the old code? Is there a way for the spec or the implementation to mitigate this?

[vmpstr]

So I understand correctly, do you mean if there's both an IntersectionObserver type of code and this new event handling? I can't immediately think of a situations where this can cause a problem where both handlers are triggered in a loop. The only way that would be possible is if one of the handlers changes layout of the page such that the affected c-v element keeps being toggled between skipped and not skipped states. But that seems like a behavior that could already be caused with only one of IntersectionObserver or this new event. IOW (and IMHO), nothing fundamentally changes now that there are two different ways to observe these state changes.

I hope that answers your question

[hober]

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.