[css-contain] Clarify spec text about contain:layout so that its ink-overflow effect on a scrollable element is clearer

[dholbert]

https://drafts.csswg.org/css-contain/#containment-layout has this requirement:

If the contents of the element overflow the element, they must be treated as ink overflow.

It's ambiguous what this means for an element that has contain:layout; overflow:auto and a tall child. E.g. this testcase: https://jsfiddle.net/knao5wu3/

We (Mozilla) interpreted this spec text as follows for this testcase:

• the tall child at that^^ testcase does overflow its parent (this is why a scrollbar is normally created, in the absence of containment -- because its contents overflow it).
• contain:layout says that this must be treated as ink overflow.
• ink overflow is not scrollable, by definition. Hence, Firefox does not create a scrollbar.

(You can test this in Firefox Nightly if you flip about:config pref layout.css.contain.enabled = true.)

Chrome does create a scrollbar, though -- they seem to have taken a different interpretation -- it seems that they're not considering the contents to "overflow the element" in this case, so they don't do any layout-containment-triggered "ink overflow conversion". i.e. they leave the scrollable overflow as being scrollable overflow. (Note that if I adjust the testcase to move overflow:scroll to an ancestor, then they match Firefox & stop creating a scrollbar. So I think they're only testing whether contents overflow the element in the context of whatever scrolling context the contained element and its siblings participate in, so to speak.)

I tend to think Chrome's interpretation is the more useful one here, in terms of making the contained element a lightweight "black box" from the perspective of its siblings/ancestors, but it is not at all clear to me that it's what the spec text is asking for. Could we clarify the spec text on this? CC @fantasai @frivoal (and @MReschenberg whose internship is over but who may still be interested to follow along and/or chime in)

[TalbotG]

Test with 'contain: layout' and 'overflow-y: auto'
http://www.gtalbot.org/BrowserBugsSection/CSS3Contain/contain-layout-ink-overflow-023.html

Test with 'contain: layout' and 'overflow-x: auto'
http://www.gtalbot.org/BrowserBugsSection/CSS3Contain/contain-layout-ink-overflow-024.html

Test with 'contain: layout' and 'overflow-y: scroll'
http://www.gtalbot.org/BrowserBugsSection/CSS3Contain/contain-layout-ink-overflow-025.html

Test with 'contain: layout' and 'overflow-x: scroll'
http://www.gtalbot.org/BrowserBugsSection/CSS3Contain/contain-layout-ink-overflow-026.html

I hope to do more tests with 'contain: layout' and, this time, with 'overflow-x: hidden' or 'overflow-y: hidden' later this week.

[tabatkins]

Ah, we intended that statement ("must be treated as ink overflow") to refer to contents that actually spilled out of the element, aka overflow:visible. The intention is just that the containing element doesn't project its contents' geometry outside of itself (and thus you don't need to care about the contents when figuring out the overflow bounds of the element).

If the containing element is scrollable, it already traps the geometry of its contents, so nothing needs to be done.

Hm, have to think on how to rephrase.

[TalbotG]

Test with 'contain: layout' and 'overflow-y: hidden' (with text)
http://www.gtalbot.org/BrowserBugsSection/CSS3Contain/contain-layout-ink-overflow-027.html

Test with 'contain: layout' and 'overflow-y: hidden' (with images)
http://www.gtalbot.org/BrowserBugsSection/CSS3Contain/contain-layout-ink-overflow-028.html

Test with 'contain: layout' and 'overflow-x: hidden' (with contiguous words)
http://www.gtalbot.org/BrowserBugsSection/CSS3Contain/contain-layout-ink-overflow-029.html

Test with 'contain: layout' and 'overflow: hidden' (with contiguous images causing line wrapping)
http://www.gtalbot.org/BrowserBugsSection/CSS3Contain/contain-layout-ink-overflow-030.html

Those are good first draft tests.

[frivoal]

Ah, we intended that statement ("must be treated as ink overflow") to refer to contents that actually spilled out of the element, aka overflow:visible.
[...]
If the containing element is scrollable, it already traps the geometry of its contents, so nothing needs to be done.

Hm, have to think on how to rephrase.

How about simply:

If the computed value of the overflow property is either visible or clip or a combination thereof, any overflow must be treated as ink overflow.

Then we need to adjust the tests mentioned by @TalbotG to make the overflowing element an overflow:visible descendant of the element with overflow: scroll or overflow: auto instead of being the same element, but otherwise the tests remain valid.

[TalbotG]

http://www.gtalbot.org/BrowserBugsSection/CSS3Contain/contain-layout-overflow-x-y-dhtml.html

[frivoal]

I think this change is meant to be a clarification, but the original was phrased sufficiently poorly that it is actually a normative change. Agenda+ to confirm that changing is OK.

[css-meeting-bot]

The CSS Working Group just discussed Clarify spec text about contain:layout so that its ink-overflow effect on a scrollable element is clearer, and agreed to the following:

• RESOLVED: Accept change in https://github.com/w3c/csswg-drafts/issues/3023#issuecomment-415885325 to clairfy ink overflow bit only appies to visible, clip or a combination

The full IRC log of that discussion

<dael> Topic: Clarify spec text about contain:layout so that its ink-overflow effect on a scrollable element is clearer
<dael> github: https://github.com//issues/3023#issuecomment-415885325
<dael> florian: I think this is sort of an editorial mistake. Makes a normative difference
<dael> florian: layout containement when on spec says overflow is treated as ink. Meant if overflow is visible it's treated as ink so if content escapes it doesn't trigger scrollbars on an ancestor. But if there is scroll we don't have a problem triggering scroll so if all is ink we never get scrollbars
<dael> florian: I think this is clarifying, but it is effectively a normative change. Are we okay with it?
<dael> astearns: Concerns?
<dael> dbaron: Think I'm okay. Gecko impl what it said now.
<dael> florian: He's the one that raised it with a comment that what Chrome does is more useful
<dael> florian: Some tests will need fixing too, but I'll do that.
<dael> astearns: Objections?
<dael> RESOLVED: Accept change in https://github.com//issues/3023#issuecomment-415885325 to clairfy ink overflow bit only appies to visible, clip or a combination