[css-contain] Top layer interactions with content-visibility: hidden.

[vmpstr]

content-visibility: hidden skips its content which it defines as flat-tree descendants. Part of skipping the contents is that they are not painted.

When we put an element into the top layer, however, its box goes into a top layer stacking context which changes to a different topology than the flat-tree. (Note that I think this type of definition is well suited for CSS, so I think CSSWG is the proper body to decide this question)

We have three options, I think:

1. We don't create a layout object for top layer element in content-visibility: hidden subtrees, similar to what display: none would do.
2. We refuse to put the element into the top layer if it's in content-visibility: hidden subtree. The developer would need to try again when the element is not under content-visibility: hidden.
3. Show the element in the top layer list. This defeats some optimizations that content-visibility provides. It is also inconsistent with other approaches that hide content (neither display: none nor visibility: hidden would show the content, but content-visibility: hidden would)

I recommend option 1 since it would be the most consistent with display: none

/cc @chrishtr

[tabatkins]

Strong agree. Anything that diverges behavior from display:none (besides the differences we explicitly intend in the spec) should be looked at with extreme suspicion. So yeah, option 1.

[css-meeting-bot]

The CSS Working Group just discussed [css-contain] Top layer interactions with content-visibility: hidden, and agreed to the following:

• RESOLVED: Elements with ancestors of content-visbility:hidden will have no boxes while in top layer. If removed from top layer they get their box back

The full IRC log of that discussion

<dael> Topic: [css-contain] Top layer interactions with content-visibility: hidden
<dael> github: https://github.com//issues/6728
<dael> vlad: Content-visibility: hidden skip their contents meaning they don't paint. When element is in top layer changes topology of the tree so element is hoisted to root level
<dael> vlad: Prop is we should say it doesn't paint or generate layout box
<Rossen_> q?
<smfr> q+
<dael> vlad: could ensure it does generate and paint, but precludes a lot of the optimization
<TabAtkins> q+
<dael> vlad: Another is we refuse to allow in top layer, but also seems inconsistent
<Rossen_> ack smfr
<dael> smfr: The top layer spec says that top layer elements, containg block is inital contain block. Hoisted out of anything they're inside of. Why is content-visbility different?
<chrishtr> q+
<dael> vlad: It's hoisted out of all containment. There's no way to optimize performance of this b/c then have to always keep rendering up to date. Not sure how common case is. I was hoping this could have the same rule as display:none
<dael> smfr: That means we need a new concept in css that not containing block or z-order
<dael> TabAtkins: Just say decendents don't generate boxes liked display:none.
<Rossen_> q?
<dael> smfr: How does that impact rest of the dialog?
<dael> TabAtkins: You can't focus something that doesn't have a box. That gets skipped
<dael> smfr: I guess same as calling show dialog on display:none
<dael> TabAtkins: yes
<Rossen_> ack TabAtkins
<dael> TabAtkins: I put a comment in the issue. Except explicit difference in spec, anything that diverges from display:none should be looked at with suspicion. If there's no reason for difference should be same as display:none
<dael> chrishtr: I agree with that outcome
<Rossen_> ack chrishtr
<dael> chrishtr: Whated to clarify tricky situation is you have an element skipped by virtue of having and ancestor. You have a skipped thing with an unskipped ancestor which is bad. That's why Vlad said we'd lose optimizations. If you treat like dsiplay:none where it has a box but if in top layer it becomes like display:none
<Rossen_> q?
<dael> chrishtr: Consistent and simple. I don't think there's a concept to hoist something to the top of tree and make it visible
<dael> Rossen_: Validating an assumption, none of the content elements are a11y, right?
<dael> vlad: correct. Can be targets of aria label, but not exposed
<dael> Rossen_: Cool
<dael> Rossen_: Sounds like a good approach. Other thoughts?
<dael> smfr: content-visbility: auto implications?
<dael> vlad: That's the next issue
<dael> Rossen_: What is resolution?
<dael> Rossen_: Option 1?
<dael> vlad: yes
<dael> chrishtr: If there is a content-visbility ancestor there is no box. It's in the top layer, but has no box
<smfr> is the “it’s in the top layer” observable?
<dael> Rossen_: Prop: Elements with ancestors of content-visbility:hidden will have no boxes while in top layer. If removed from top layer they get their box back
<dael> Rossen_: Obj?
<dael> Rossen_: smfr does the irc question you have?
<dael> smfr: chrishtr said in the top layer, is that observable? If so, through dom?
<dael> chrishtr: Discussed if it was observable, but not sure
<dael> vlad: Right, I don't know the answer to this
<dael> chrishtr: Might be if you try...don't know
<dael> smfr: If it has a backdrop is that display:none too?
<dael> vlad: yeah, it would be same
<dael> chrishtr: Backdrop pseudo spec has an immediately proceeding box. And there's not box. Might need to clarify text but should be same
<dael> Rossen_: Obj?
<dael> RESOLVED: Elements with ancestors of content-visbility:hidden will have no boxes while in top layer. If removed from top layer they get their box back