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

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.

http://weibo.com/1397442732/BgJa9hM7M


以上
一丝


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
>
>