[css-contain-3] Proposal: Add an event to fire when content-visibility: auto state changes

[vmpstr]

Right now we specify that content-visibility: auto skips its content when the element isn't relevant to the user. This means that the contents of the element will not be rendered by the UA. This is also a great opportunity for frameworks (e.g React) or general script (e.g. canvas updates) to stop, since the effect of these updates would not be rendered anyway.

However, to coordinate the starting/stopping updates, the UA should give the developer an signal (this proposed event) which would inform script that the rendering state changed.

The name is hard to come up with but I have a couple of proposals in the explainer:
https://github.com/vmpstr/web-proposals/blob/main/explainers/cv-auto-event.md

Happy to hear other suggestions or thoughts about this in general.

[tabatkins]

I'm in favor of just being big and verbose - this is something very specific and I don't think we should try to claim a generic name for it. So +1 for ContentVisibilityAutoStateChanged

[smfr]

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.

[FremyCompany]

1. Are we sure this is different from an IntersectionObserver?
2. How about ContentVisibilityStateChanged? This might apply to values other than auto in the future.

[chrishtr]

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 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.

[css-meeting-bot]

The CSS Working Group just discussed [css-contain-3] Proposal: Add an event to fire when content-visibility: auto state changes, and agreed to the following:

• RESOLVED: Add the new event with the name ContentVisibilityAutoStateChanged
• RESOLVED: Add a note about potential issues for a11y

The full IRC log of that discussion

<dael> Topic: [css-contain-3] Proposal: Add an event to fire when content-visibility: auto state changes
<dael> github: https://github.com//issues/7384
<dael> vmpstr: This is a prop for a new event for content-visibility: auto
<dael> vmpstr: content-visibility: auto right now skips rendering when element is offscreen or not relevant to use
<dael> vmpstr: Prop is expose and event that fires when this state changes
<dael> vmpstr: Motivation is some of the partner feedback. In particular they want to skip additional work when element is offscreen such as react update. Event is convenient way to do so
<dael> Rossen_: Catching up, did we establish event name?
<dael> vmpstr: We can talk about name. I have proposals and TabAtkins commented more explicit and verbose is better which I'm fine with
<dael> Rossen_: Backing up, can you remind me for the content-visibility: auto elements nested inside do they participate in a11y tree?
<dael> vmpstr: content-visibility: auto elements do participate in a11y. They're exposed as visible.
<dael> Rossen_: From PoV of a11y these events and content-visibility: auto has no meaningful meaning?
<chrishtr> whether the content is skipped affects layout
<dael> vmpstr: The event itself doesn't. The only potential difference is if script does something in response tot he event such as skipping react updates that eventually cause a different a11y tree.
<dael> Rossen_: Thanks. That's what I wanted to decipher here. If, as an author, I'm pausing a bunch of work on the event and I'm aware what impact pausing would have on a11y that could degrade the experience of assistive tech
<Rossen_> q?
<chrishtr> q+
<heycam> q+
<dael> vmpstr: It is a possibility. Currently the solution is to add own intersection observer and do the same thing but impossible to guess the margin content-visibility: auto has internally. but this could be done with intersection observer
<dael> chrishtr: Clarifying your point, Rossen_. I think you were saying exposing the event makes it easier for author to remove offscreen content from DOM?
<dael> Rossen_: That would be one more kind of aggressive change, yes
<dael> chrishtr: Yeah. Then I would repeat that it is already possible and virtual scrollers do it. Main value is it allow them to play with perf benefits. But if a site unmounts DOM that's far offscreen it would be less info for a11y tech
<Rossen_> ack chrishtr
<Rossen_> ack heycam
<dael> heycam: By the sounds of it this can be achieved using intersection observer already by watching for the same changes, maybe with some additional checks for focus. Wondering about firing of events and which lements fired to. One difference with intersection observer is you register on an element and sounds like this event should be dispatched to every element
<dael> heycam: Could be like the focus state of an element changes, would that mean have to dispatch a separate event to each ancestor?
<dael> vmpstr: I think I would like to dispatch this event to an element that has content-visibility: auto style on it when relevance of that element changes. Spec is element is relevent if in flat tree has an element that has focus. It's if the content-visibility: auto element with the element in the subtree has focus
<dael> heycam: I see. Okay
<Rossen_> q?
<dael> Rossen_: Additional feedback?
<dael> Rossen_: I guess you're looking for resolution to add this event, with name and shape tbd?
<dael> vmpstr: If no obj to content-visibility-auto-state-change I'd like to resolve on that. But also happy to resolve to add event
<dael> Rossen_: If no other feedback or additional comments to vmpstr then are there any objections to exposing such event?
<dael> Rossen_: Objections to ContentVisibilityAutoStateChanged as the name
<dael> heycam: Is there a way to query the content-visibility auto state?
<dael> vmpstr: No so the event would have that information on it
<dael> Rossen_: Hearing no objection on event or name
<dael> RESOLVED: Add the new event with the name ContentVisibilityAutoStateChanged
<dael> Rossen_: Still a bit concerned about if there is a way to add author guidance about potential degredation of a11y experience. I don't think that's the event itself, but the event might make it more confortable
<dael> vmpstr: Can add a note to the spec next to the event
<dael> Rossen_: Would love that
<dael> Rossen_: Thanks
<dael> RESOLVED: Add a note about potential issues for a11y

[chrishtr]

As discussed on the call, the event will need a parameter indicating whether the element is now in a skipped or not-skipped state. I suggest we call the event parameter skipped, and its type a boolean.

[noahlemen]

This is definitely crucial for being able to leverage content-visibility:auto to replace userland implementions of virtual scrollers.

For example, in our JS-based virtual scroller on Facebook, we use intersection observers to determine visibility – we then use this to control both rendering of the elements, as well as to flag these React components for deprioritized updates.

When attempting to use content-visibility:auto to replace this implementation, we currently lose out on the latter. We certainly could continue to use an intersection observer for this aspect of the functionality, but I think that is undesirable for the reasons @chrishtr mentioned.