W3C home > Mailing lists > Public > www-style@w3.org > February 2016

Re: [css-contain] Layout containment and overflow

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sat, 27 Feb 2016 22:21:39 -0800
Message-ID: <CAAWBYDDHvpjyrs=UDu+A1fuQ8VnrCSpRyidxwrzD0kvcsL-rsQ@mail.gmail.com>
To: Florian Rivoal <florian@rivoal.net>
Cc: www-style list <www-style@w3.org>
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.

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

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:57 UTC