[cssom-view] API to expose skipped content state

[nt1m]

Currently there is no straightforward way to query the skipped content state, despite browsers having this info internally.

In the context of web extensions, it would be useful if you could query that state without invoking the layout of the element, which takes away from the content-visibility optimizations.

@vmpstr @rwlbuis

[Loirooriol]

Some past discussion in #6850 (comment)

[nt1m]

Perhaps it should just be an extension to checkVisibility to check for c-v: auto skipped content

[vmpstr]

I think this is a pretty good idea. We currently have

• The Contentvisibilityautostatechange event which is nice to checking when content-visibility: auto switches state
• The checkVisibility function that Oriol mentioned.

I don't know if we want checkVisibility to specifically check for c-v auto skipped content, since that content is still visible to a lot of features like find-in-page and accessibility. So saying it's not visible in checkVisibility is a bit misleading.

I wouldn't be opposed to a new function though.

/cc @josepharhar

[css-meeting-bot]

The CSS Working Group just discussed [css-contain-2] API to expose skipped content state, and agreed to the following:

• RESOLVED: Extend checkVisibility to expose content-visibility: auto state

The full IRC log of that discussion

<emilio> ntim: in Safari we have some reader detection code that does some visual analysis and performs layout in different subtrees
<emilio> ... we want an API to be able to skip hidden content for visual analysis
<emilio> ... because otherwise it cancels out optimizations
<vmpstr> q+
<emilio> ... ideally it'd cover content-visibility: auto and hidden
<emilio> q+
<astearns> ack khush
<emilio> ack khush
<astearns> ack vmpstr
<emilio> vmpstr: checkVisibility was close to cover this use case
<emilio> ... it deals with c-v: hidden
<emilio> ... I'd suggest extending checkVisibility
<emilio> ... content-visibility: auto content remains accessible to find-in-page / tab-navigation / etc so it's not "hidden hidden"
<emilio> ... so not sure if it'd be consistent with the model
<emilio> ntim: you can kinda query it with the statechange event
<emilio> ... but it's less convenient and you might miss some events
<astearns> ack emilio
<miriam> scribe+
<miriam> emilio: not opposed
<emilio> ... and I agree with vmpstr on extending checkVisibility
<emilio> ... but curious about the use case because it seems reader-mode should care about content-visibility: auto
<miriam> emilio: to check size you need to layout
<emilio> ntim: so we have a check for the element being small and skipping the content
<emilio> ... and the rest of the code doesn't care about layout
<emilio> ... but actually slows down the website because it lays out the skipped subtrees
<vmpstr> q?
<vmpstr> q+
<emilio> ntim: could be a separate method on checkVisibility even
<miriam> emilio: The element could be large, and you need to lay it out
<miriam> … kinda silly not to expose this
<emilio> ... it's a bit weird that with the statechange event being async you can observe an element being hidden before the state change arrives
<emilio> ... might cause some subtle bugs
<emilio> ... but anyhow it seems fine to expose
<emilio> q?
<astearns> ack vmpstr
<emilio> vmpstr: just to answer emilio, I don't think it's unique to this
<emilio> ... intersectionobserver has the same issue, where you could do your own math via gBCR
<emilio> ... I'd like to suggest not reusing checkVisibility for this
<emilio> q+
<miriam> emilio: why?
<emilio> vmpstr: to me the problematic word there is visibility
<emilio> ... because if you consider things like a11y it's there
<emilio> ... so claiming it's not visible is not entirely accurate
<emilio> ... visibility is a little overloaded
<astearns> ack emilio
<miriam> emilio: but that's true of all the other things CV checks
<miriam> ... things with opacity 0 are still in the visibility tree
<miriam> … as long as you opt in for content visibility auto, seems like you need to check that anyway
<emilio> vmpstr: I guess opacity would be similar to this, yeah, the other's won't
<emilio> astearns: seems there's consensus on exposing this, but not in whether to change checkVisibility or something else
<emilio> ... might be worth resolving on that and discussing the other thing in the issue
<emilio> fantasai: was going to say the same thing as emilio, checkVisibility is already a misnomer and was designed with this extension in mind
<emilio> ntim: I don't feel strongly either way
<vmpstr> +1
<emilio> RESOLVED: Extend checkVisibility to expose content-visibility: auto state

[AutoSponge]

APA will track this issue. We want to ensure that elements not rendered (e.g., display:none) but that could still end up in the AxTree (e.g., targeted by aria-describedby) are not conflated by developers to be "skipped" for AT.