[css-contain-2] If element is in the top layer, are its contents necessarily relevant to the user

[vmpstr]

I am looking at the following test:
https://wpt.fyi/results/css/css-contain/content-visibility/content-visibility-with-top-layer-006.html

It essentially puts a dialog in the top layer. This dialog has a large spacer followed by a content-visibility: auto element. It then asserts that the content-visibility: auto element should be relevant to the user, as measured by its size.

The applicable text of the relevant to the user section says that the element is relevant to the user if:

Either the element or its contents are placed in the top layer.

It doesn't seem to apply here, because neither the content-visibility: auto element nor any of the descendants of the content-visibility: auto element are in the top layer. That is, unless "element being in the top layer" implies that all of the descendants of "element" are also in the top layer. That is, not, however my understanding of this.

Can someone please check my reasoning? :) If this looks correct, then I think the test expectations are not aligned with the spec

/cc @mrobinson @frivoal

[vmpstr]

I'm also wondering if the spacer was meant to be outside of the dialog, so that when not in top layer, it would be off-screen. This would bring the content-visibility auto element on screen when the dialog is placed in the top layer, and then the expectation is correct that it should be relevant -- due to intersection with the viewport.

[Loirooriol]

I agree, #inner is a content of an element in the top layer, but it's not directly in the top layer. Otherwise it would have a ::backdrop, would be laid out as a sibling of the root, etc.

[tabatkins]

The contents of the element are definitely "in the top layer", yeah. I'm not sure why the root element being placed in the top layer would make it relevant to the user, but its contents wouldn't be.

I'm also wondering if the spacer was meant to be outside of the dialog, so that when not in top layer, it would be off-screen. This would bring the content-visibility auto element on screen when the dialog is placed in the top layer, and then the expectation is correct that it should be relevant -- due to intersection with the viewport.

No, the spacer being in the dialog is the entire point of this test - putting the auto element in a position where it wouldn't normally be relevant, but still is due to being in the top layer. If the spacer was outside the dialog it wouldn't be exercising that part of the spec at all, but rather just the generic "element is in view" part.

[Loirooriol]

@tabatkins The contents are not directly "in the top layer" or these would apply:

https://fullscreen.spec.whatwg.org/#new-stacking-layer

Each element and ::backdrop pseudo-element in a top layer has the following characteristics: [lots of things that don't happen]

https://fullscreen.spec.whatwg.org/#::backdrop-pseudo-element

Each element in a top layer has a ::backdrop pseudo-element.

Basically, the cases are:

1. Element with content-visibility: auto has contents in the top layer. These contents would be reparented and escape containment, so it can be observable whether they are skipped or not. So we don't want to skip contents.
2. Element with content-visibility: auto is itself in the top layer. Such thing has a ::backdrop content in the top layer, so this actually fits into the previous case.
3. Element with content-visibility: auto has ancestors in the top layer. I see no need to prevent skipping its contents.

The spec covers cases 1 and 2. The test is for case 3.

[tabatkins]

Sure, it looks like specs are disagreeing on the precise terminology in use. I didn't say the contents of a dialog were in the top layer in the sense that Fullscreen is using the term - that spec is meaning the root element of each top-layer subtree. This does need to be cleaned up, but what I said is still correct - the intention is that the contents of a root top layer element are "relevant to the user" in the same way that the root top layer element itself is.

At least, that was my intention when writing it, but looking back at the issue that inspired adding that line (#6727), it appears that Anders was indeed just trying to solve your case 1/2.

In that case, I suppose I'm fine reducing it to just those two cases, and leaving case 3 alone. We'll have to change the WPT then (literally just expecting the opposite would be acceptable).

[vmpstr]

At least, that was my intention when writing it, but looking back at the issue that inspired adding that line (#6727), it appears that Anders was indeed just trying to solve your case 1/2.

Yeah that was my initial intent (and I'm Vlad <_<). Case 3 is just harder to implement and I agree with Oriol that there doesn't seem to be a pressing need in solving it. I believe the spec text is fine as is? I'm happy to update the WPT

[tabatkins]

and I'm Vlad

ahahaha, sorry, despite looking at the comment seconds before writing my response, my brain filled in that it was from Anders.. ^_^

And no, spec text probably isn't fine as-is given the question here and the fact that it was interpreted in this way for WPT; it's clearly ambiguous. We should define an "in the top layer" term and use it.