Re: [css-contain] Layout containment and overflow

> On Feb 28, 2016, at 07:21, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> On Sat, Feb 27, 2016 at 9:48 AM, Florian Rivoal <florian@rivoal.net> wrote:
>> 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.
> 
> Ink Overflow can cause scrollbars iirc, so it's not.


Either you remember incorrectly, or I misunderstand something. From the spec: "Ink overflow is the overflow of painting effects defined to not affect layout or otherwise extend the scrollable overflow region".

This seems to be exactly what we want here.

> ~TJ

Received on Sunday, 28 February 2016 08:47:27 UTC