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

On Wed, Jul 30, 2014 at 9:05 AM, Daniel Holbert <dholbert@mozilla.com> wrote:
> 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.

Yeah, we don't think it's possible to address this in any sane way;
the author just needs to fix their content.  The point of the auto
behavior is that if the author gives us some indication that they've
thought about overflow, we'll let them do whatever they want;
otherwise, we'll set up some reasonably safe defaults.  In this case
the author *hasn't* thought about overflow on the flex item; they're
just relying on the overflow behavior of the grandchild to avoid it
overflowing.  If we trusted them and gave them a min-width of 0, it
would work, but we can't reasonably infer that this is safe. :/

~TJ

Received on Tuesday, 19 August 2014 00:34:26 UTC