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

Re: [css-flexbox] min-width/height: min-content defaults for replaced items and overflow containers

From: Daniel Holbert <dholbert@mozilla.com>
Date: Wed, 30 Jul 2014 09:05:45 -0700
Message-ID: <53D917D9.6080901@mozilla.com>
To: fantasai <fantasai.lists@inkedblade.net>, Elliott Sprehn <esprehn@gmail.com>
CC: www-style list <www-style@w3.org>, Ojan Vafai <ojan@chromium.org>
On 03/19/2014 12:23 PM, fantasai wrote:
> On 04/22/2013 04:50 PM, Elliott Sprehn wrote:
>> Both of these have proven to be surprising behavior, instead I think
>> we should combine the behavior so the min-width is
>> min-content unless your overflow property computes to a value other
>> than visible in which case it should be 0.
>>
>> This special cased behavior gives a sensible result for <img> and
>> overflow: scroll as flex items.
> 
> Hi Elliot,
> Based on implementation experience from IE, the CSSWG has agreed
> to take your proposal. The 'auto' value has been restored as the
> initial value of min-width/height, and its definition modified
> to account for 'overflow' (as you recommended)

FWIW: I've implemented the new "min-width:auto"/"min-height:auto"
behavior in Firefox Nightly (letting 'overflow' & other sizing
properties suppress the min-content-sizing behavior), and I'm noticing a
recurring pattern in bugs filed for breakage caused by this change.

(I'm tracking issues where this has broken content with this meta-bug:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1043520 )

So far, the main cause of brokenness (in Firefox OS apps at least) has
been cases where a flex container has a really wide *grandchild* that
has "overflow:[non-visible]", e.g.:

 <div style="display:flex">
   <div>
     <div style="overflow:auto">ReallyLoo[...]ooongWord</div>
   </div>
 </div>

The new behavior only disables flex-item min-content sizing when *the
flex item* has 'overflow' set. That's not the case here, so we do
min-content sizing, which means the flex item gets a huge min-width (the
width of the long word), and it overflows its flex container.  The
grandchild doesn't get a chance to make use of its own "overflow:auto"
(so, no scrollbars show up on it), since *it* doesn't overflow its own
bounds.

I don't know if there's a way to address this use case to "do the right
thing" (making it backwards-compatible with content like this ^ that was
coded for a rendering engine without the flex-item min-sizing behavior).
There may not be anything we can do; even so, I want to mention this as
a "heads up" to content-authors & implementers, since it's the most
common reason (so far) for content breaking after this change.

~Daniel
Received on Wednesday, 30 July 2014 16:06:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:23 UTC