W3C home > Mailing lists > Public > www-style@w3.org > May 2013

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 13 May 2013 13:59:37 -0700
Message-ID: <CAAWBYDCObh5JTscgKzeLFHY+MJGUqfv5KRL60YtbRXe=oJrUqg@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: www-style list <www-style@w3.org>
On Mon, May 13, 2013 at 1:25 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> On 05/13/2013 01:14 PM, Daniel Holbert wrote:
>>
>> On 04/22/2013 04:50 PM, Elliott Sprehn wrote:
>>>
>>> Recently the spec for flexbox was changed so that the min-width of flex
>>> items was no longer min-content
>>
>> [...]
>>>
>>> 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.
>>
>>
>> Note that before the recent "min-width:auto", Alex proposed a very
>> similar custom-min-sizing-behavior-when-overflow-is-set idea:
>>
>>   # One solution could be to fix exactly that - if
>>   # 'overflow' is not 'visible', 'min-content' is not 'auto' by default
>>   http://lists.w3.org/Archives/Public/www-style/2013Mar/0125.html
>>
>> ...and Tab said he'd be OK with that, but was worried about this
>> introducing an additional special case:
>>   http://lists.w3.org/Archives/Public/www-style/2013Mar/0133.html
>>
>> And then the CSSWG ended up passing on that solution (implicitly at
>> least) and dropping min-width/min-height:auto, which suggests that this
>> proposal wasn't compelling enough to go for.
>
>
> Yeah, I remember that concern about the non-obvious interaction with
> 'overflow'. I also remember asking if we were creating a different
> set of problems by removing automatic minimum, and Tab assured me
> that it was way less of a problem. Which Elliott just pointed out,
> is not true. :/

It is way less of a problem.  That doesn't mean it's not still a problem.  ^_^

The best solution would be to make "replaced elements" compute their
min-width/height to min-content.  But we can't do that, because
replaced-ness isn't known until after url resolution, which we've
agreed is too late for computed-value time.

Given that the best solution is out of reach, all the remaining
solutions suck in some way.  The current spec is a decent level of
suckiness, I think - it many cases it does the right thing.  It fails
when you have a replaced element and overflow, because they'll squish.
 But the fix for that is relatively close at hand - you just have to
fix the flexibility.  I think this is more obvious than fixing the
min-width/height (the solution to old problems) or potentially having
to fix 'overflow'.

~TJ
Received on Monday, 13 May 2013 21:00:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 May 2013 21:00:25 UTC