[css-contain-2] Clarify what happens with scrollbars on elements that 'skip their contents'

[vmpstr]

The css-contain-2's content-visibility spec says that when the element skips its content, then

its contents ... are not painted (as if they had visibility: hidden) and do not respond to hit-testing (as if they had pointer-events: none).

The intent of this is to ensure that we don't need to render (style / layout) the subtree and thus we can skip this work. However, if the element itself is a scroller then having its contents be "as if they had visibility: hidden" is not sufficient for us to skip the work, since the size of the overflow is reflected in the scrollbar and the scroll thumb size.

I think we should clarify this. Ideally we can say something like "as if they had display: none", or maybe just explicitly says "and the size of the contents does not contribute to the overflow of the element or its ancestors"

[frivoal]

Since we're only talking about the contents of the element, not the element itself, then I think "as if they had display: none" is accurate.

Agenda+ to propose adopting that.

[frivoal]

Actually, having read #5869, I'd like to back away from my previous comment. With a visibility: hidden behavior, size and position of the element can still be queried by script and return sensible answers (potentially lazily computed), while a display: none would destroy the invisible layout.

Instead, we could go with something like:

When an element skips its contents […], no scrollbar or other scrolling mechanism is shown regardless of the value of the overflow property and of whether the content would overflow.

[Loirooriol]

If you use overflow: scroll; content-visibility: auto; contain-intrinsic-size: auto 0px, then when the element is visible the content size (without the scrollbars) will be recorded. When the element goes off the screen and skips its contents, the last remembered size will be used as the content size. If the scrollbars disappear, then the outer size will shrink, losing stability.

Of course the contents shouldn't be checked to determine whether overflow: auto needs a scrollbar, but I'm not convinced that overflow: scroll shouldn't trigger a scrollbar. It can just take space, it doesn't need to be painted.

Maybe it could be explained in terms of scrollbar-gutter? Like non-visible content-visibility forces scrollbar-gutter: stable or something.

[css-meeting-bot]

The CSS Working Group just discussed [css-contain-2] Clarify what happens with scrollbars on elements that 'skip their contents', and agreed to the following:

• RESOLVED: For elements in this situation we treat any overflow as ink overflow

The full IRC log of that discussion

<dael> TabAtkins: I believe the right answer is fairly clear.
<dael> TabAtkins: The core issue is current spec text says if element skips contents they are not painted (as if visbility hidden). But if it's a scroller you still have to perform layout b/c need to know if trigges overflow. Seems like oversight b/c don't want to require layout
<dael> TabAtkins: Obvious case is make it assume no scrollbars are required. Some talk about saying "as if display:none" but that's not accurate either b/c would trigger lazy layout
<dael> TabAtkins: I think best is say skipped contents are treated as ink overflow so do not ever trigger scrollbars
<dael> astearns: Other side effects of ink overflow beyond creating scrollbars?
<dael> TabAtkins: No, only around how large the overflow rectangle is which is only to calc scrollbars
<dael> astearns: Prop: Any overflow is treated as ink overflow
<dael> smfr: Normally when think about ink overflow think about triggering paint invalidation. Never anything painted. So treating as ink overflow maybe not best?
<dael> TabAtkins: Since there's a scroller ink overflow will get trapped by the scroller
<dael> TabAtkins: Big thing is actual overflow area will be 0 essentially. Things are clipped but also invisible
<dael> smfr: Describe in terms of overflow:clip?
<dael> TabAtkins: I little reluctant to define in overflow b/c make sure do not stomp on existing overflow. Talking about in terms of ink allows us to avoid. If you think ther'es problems with ink we can look into it. At first blush want to stick with ink
<dael> astearns: Other concerns?
<dael> astearns: Prop: For elements in this situation we treat any overflow as ink overflow
<dael> astearns: Obj?
<dael> RESOLVED: For elements in this situation we treat any overflow as ink overflow