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)
https://drafts.csswg.org/css-contain/#containment-layout has this requirement:
It's ambiguous what this means for an element that has
contain:layout; overflow:autoand a tall child. E.g. this testcase: https://jsfiddle.net/knao5wu3/We (Mozilla) interpreted this spec text as follows for this testcase:
contain:layoutsays that this must be treated as ink overflow.(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:scrollto 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)