- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 26 Feb 2016 14:56:13 -0800
- To: www-style list <www-style@w3.org>
During the Feb 17 telcon, an issue was brought up with "contain:layout" and overflowing content - a strict reading of the spec would imply that content overflowing a contain:layout container could cause the container's ancestor to overflow, possibly causing scrollbars to appear and affecting the layout. This violates the intended semantics of contain:layout. We came up with three options on the call: 1. Eh, let it happen. It's not too bad. 2. Layout containment always implies paint containment, so nothing can overflow. 3. Overflow is allowed visually, but it doesn't project its "geometry" past the layout-contained ancestor, so it can't trigger overflow past a layout-containment boundary. I talked to Levi, our 'contain' implementor, and he said he hates both #1 and #2, and that our code already effectively does #3 - when a contain:layout box overflows, its ancestors aren't informed, so they don't "see" the overflow and won't respond with scrollbars. Painting is still done normally, so the overflow shows up visually. So, I'm going to spec that. He brought up a further issue that I'm currently awaiting some clarification on - does the overflow hit-test or not? I don't think this counts as a "layout" effect, so I believe it should still absorb hit-tests. ~TJ
Received on Friday, 26 February 2016 22:56:59 UTC