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

On Mon, Jun 30, 2014 at 10:38 AM, Daniel Holbert <dholbert@mozilla.com> wrote:
> On 06/29/2014 09:44 AM, Tab Atkins Jr. wrote:
>> On Sat, Jun 28, 2014 at 4:39 PM, Daniel Holbert <dholbert@mozilla.com> wrote:
>>> On 03/19/2014 12:23 PM, fantasai wrote:
>>>> 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".
>>
>> 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
>>
>
> I've got one idea for an alternative...
>
> So, I'm assuming the old min-width:auto behavior caused author confusion
> primarily **when flex-basis was auto**. (That would make us defer to
> "width", but we'd confusingly stop deferring to it when it fell below
> the min-content size, with the old min-width:auto behavior.)

Yes.

> Based on that assumption, I think we could perhaps more narrowly scope
> the new min-width:auto behavior to address this use case case. In
> particular: instead of making min-width/min-height:auto pull from the
> computed width/height, we could instead make it pull from the computed
> "flex-basis", **when computed flex-basis is auto**.

Why not just make it always pull from 'flex-basis'?  I think having it
pull from 'width' might have been an accident.  That would have the
same benefits you cite in the rest of your email.

~TJ

Received on Monday, 30 June 2014 22:29:57 UTC