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

On Sat, Jun 28, 2014 at 4:39 PM, Daniel Holbert <dholbert@mozilla.com> wrote:
> On 03/19/2014 12:23 PM, fantasai wrote:
>> 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) and specified
>> 'width'/'height' (which was another potential surprise point).
>>
>> The new definition for 'auto' is:
>>   # On a flex item whose overflow is not visible, this keyword
>>   # specifies as the minimum size the smaller of:
>>   #
>>   #  * the min-content size, or
>>   #  * the computed width/height, if that value is definite.
>
> I'm concerned about the second change described here -- the second
> bullet-point, which makes "min-width:auto" depend on the computed value
> of "width".
>
> (For simplicity, I'll stick with width/min-width/horizontal-flexbox for
> this email, but this all applies to height/min-height/vertical-flexbox
> as well.)
>
> This change concerns me for two reasons:
>
>  (a) Normally, 'min-width' works by influencing the used value of
> 'width'.[1]  This is a one-way relationship.  However, the change quoted
> above creates a cyclic relationship[2] between the properties, by
> adding a new channel of influence in the reverse direction. This adds
> complexity and makes the relationship between these properties more
> confusing.
>
>  (b) Until now, a flex item's 'width' property has had basically no
> influence on flex layout (in a horizontal container), since 'flex-basis'
> completely takes its place for sizing purposes.  (The one exception is
> when we have "flex-basis:auto", which clones 'width' -- but even then,
> we're really just dealing with the clone in flex-basis.)  But this
> change adds a new, more complex channel where 'width' subtly impacts
> flex layout. (by being one of the sources of "min-width:auto"'s used value)
>
> I assume the reason this change was added was to address situations like:
>   <div style="flex: none; width: 1px;">def</div>
> The old min-width:auto behavior would've made this flex item as wide as
> the text, instead of the specified 1px width, which was understandably
> confusing for authors.
>
> However, I think the change (making computed 'width' influence used
> 'min-width') is fairly broad as a means to address that narrow use-case,
> and perhaps too "magical".

Yes, you got the motivation correct.  min-width:auto isn't really
about enforcing a minimum width, but just a way to avoid degenerate
behavior in a particular case (shrinkable-by-default item next to an
item that's full of text).  We realized that this would create *more*
degenerate behavior with the item refusing to *ever* go below its
min-content width, even when you explicitly told it to do otherwise,
so we added the second line.

I don't want to reverse this behavior, but if it's too problematic for
min-width, perhaps we should just move this functionality to a new,
flexbox-specific property instead.

~TJ

Received on Sunday, 29 June 2014 16:45:36 UTC