Repository navigation
[css-contain-2] If element is in the top layer, are its contents necessarily relevant to the user #8514
Description
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
Activity
vmpstr commentedon Mar 1, 2023
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 commentedon Mar 1, 2023
I agree,
#inneris 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 commentedon Mar 1, 2023
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.
No, the spacer being in the dialog is the entire point of this test - putting the
autoelement 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 commentedon Mar 1, 2023
@tabatkins The contents are not directly "in the top layer" or these would apply:
https://fullscreen.spec.whatwg.org/#new-stacking-layer
https://fullscreen.spec.whatwg.org/#::backdrop-pseudo-element
Basically, the cases are:
content-visibility: autohas 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.content-visibility: autois itself in the top layer. Such thing has a::backdropcontent in the top layer, so this actually fits into the previous case.content-visibility: autohas 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 commentedon Mar 2, 2023
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 commentedon Mar 2, 2023
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
WPT: Update c-v top layer test expectation to not expect it to be rel…
WPT: Update c-v top layer test expectation to not expect it to be rel…
WPT: Update c-v top layer test expectation to not expect it to be rel…
tabatkins commentedon Mar 2, 2023
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.
WPT: Update c-v top layer test expectation to not expect it to be rel…
WPT: Update c-v top layer test expectation to not expect it to be rel…
WPT: Update c-v top layer test expectation to not expect it to be rel…
Bug 1819962 [wpt PR 38790] - WPT: Update c-v top layer test expectati…
WPT: Update c-v top layer test expectation to not expect it to be rel…
Bug 1819962 [wpt PR 38790] - WPT: Update c-v top layer test expectati…