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

dholbert has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-contain] Clarify spec text about contain:layout so that its ink-overflow effect on a scrollable element is clearer ==
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 the child overflows).
 - `contain:layout` says that this must be treated as ink overflow.
 - ink overflow is not scrollable; hence, Firefox does not create a scrollbar.

(You can test this in [Firefox Nightly](https://nightly.mozilla.org/) if you flip about:config pref layout.css.contain.enabled = true.)

Chrome seems to have taken a different interpretation -- it seems that they're not considering the child to overflow the element in this case, and they do create a scrollbar on this testcase.  (But if we move overflow:scroll to an ancestor, then they don't create a scrollbar. So they're only looking at overflow 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, 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 @MReschenberg

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3023 using your GitHub account

Received on Thursday, 16 August 2018 16:41:33 UTC