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

Re: [css-contain] Layout containment and overflow

From: Florian Rivoal <florian@rivoal.net>
Date: Sat, 27 Feb 2016 18:48:57 +0100
Cc: www-style list <www-style@w3.org>
Message-Id: <3DDB1939-C4C5-47D3-BE6C-9284947770C3@rivoal.net>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

> 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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:00 UTC