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

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

From: 一丝 <yiorsi@gmail.com>
Date: Mon, 4 Aug 2014 16:22:22 +0800
Message-ID: <CA+-d5ZoTtppgqW2zUTvdx-fW93oxE-SVzvB9Yyf4ZDOg+SbbGQ@mail.gmail.com>
To: Daniel Holbert <dholbert@mozilla.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, Elliott Sprehn <esprehn@gmail.com>, www-style list <www-style@w3.org>, Ojan Vafai <ojan@chromium.org>
This change for developers is really very painful. auto start in the
specification which increased, and then deleted, and now has added. There
are similar flex-basis auto → main-size. If there are no major issues at
this stage, it is recommended to start Flex2 soon.



2014-07-31 0:05 GMT+08:00 Daniel Holbert <dholbert@mozilla.com>:

> 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 Monday, 4 August 2014 08:23:11 UTC

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