Re: [css-contain] Layout containment and overflow

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.

~TJ

Received on Sunday, 28 February 2016 06:22:26 UTC