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

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

From: Florian Rivoal <florian@rivoal.net>
Date: Wed, 1 Jul 2015 21:28:59 +0200
Cc: www-style list <www-style@w3.org>
Message-Id: <99C53420-8905-4074-8A38-AAF891FA9E7B@rivoal.net>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

> On 01 Jul 2015, at 20:20, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> 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
> -moz-hidden-unscrollable.

I'm curious too. What I gathered was that the goal was to avoid disturbing margin collapsing and have it fall out the same way it would with overflow:visible, not any particular interest in invisible floats peeking out. Not entirely sure what use cases this would matter for, though.

 - Florian
Received on Wednesday, 1 July 2015 19:29:33 UTC

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