Re: [css-contain] Layout containment and overflow

> On Feb 26, 2016, at 23:56, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> 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.

I agree it's the right behavior. Is #3 in anyway different from Ink Overflow as defined at file:///Users/florian/src/csswg-drafts/css-overflow-3/Overview.html#ink ?
If not (and I think it's not), let's reuse the term.

 - Florian

Received on Saturday, 27 February 2016 17:49:25 UTC