W3C home > Mailing lists > Public > www-style@w3.org > July 2015

Re: [css-overflow][css-containment] overflow:clip and BCFs

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 1 Jul 2015 11:20:03 -0700
Message-ID: <CAAWBYDBXe3Dy=+NQAupS69K5WLCSgy=cRRFd6=UVi5nkoK5iLg@mail.gmail.com>
To: Florian Rivoal <florian@rivoal.net>
Cc: www-style list <www-style@w3.org>
On Wed, Jul 1, 2015 at 8:34 AM, Florian Rivoal <florian@rivoal.net> wrote:
> overflow:clip is currently defined as the same as overflow:hidden, minus the scrolling abilities.
> This implies that it establishes a BCF.
> http://dev.w3.org/csswg/css-overflow/#valdef-overflow-clip
> Mozilla implements -moz-hidden-unscrollable, which is similar to clip, except that it does not cause the element to establish a BFC.
> Should we keep things as they are, or align with Mozilla?
> As a reminder, overflow:clip was introduced to be what overflow:visible computes to when contain:paint is specified. We could have achieved the same pain containment effects without this value, but having overflow compute to something other than visible allows the properties that depend on overflow not being visible to be used with non-scrollable paint containment (e.g. text-overflow). Had we not had it, you'd have to use overflow:hidden if you wanted paint:containment and text-overflow, inducing the browser into allocating a larger buffer than needed to prepare for potential scrolling, even though you intend no scrolling.
> As far as I know, the properties that depend on overflow not being visible are:
> * text-overflow
> * resize
> If there is a need for the element to establish a BFC for these properties to work normally, then we should to keep the spec as it is. If not, I don't have a strong opinion.
> Do they? Doesn't seem so to me, but I might be missing something.

If it doesn't establish a BFC, that means it can project invisible
geometry outside of itself, via a projecting float.  That's
ridiculous.  I'd love to hear the use-case behind

Received on Wednesday, 1 July 2015 18:20:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:18 UTC