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

Re: [css3-flexbox] Revert min-width back to an initial value of 0

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 6 Mar 2013 09:22:56 -0800
Message-ID: <CAAWBYDBgevhEm_Ks-R_JonJ6La1O1VnM2qkWHJKX1RAgfA0VgQ@mail.gmail.com>
To: Alex Mogilevsky <alexmog@microsoft.com>
Cc: Ojan Vafai <ojan@chromium.org>, Boris Zbarsky <bzbarsky@mit.edu>, www-style list <www-style@w3.org>, Daniel Holbert <dholbert@mozilla.com>, Rossen Atanassov <Rossen.Atanassov@microsoft.com>
On Wed, Mar 6, 2013 at 4:17 AM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> ± From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> ± Sent: Tuesday, March 5, 2013 7:04 PM
> ±
> ± On Tue, Mar 5, 2013 at 6:15 PM, Ojan Vafai <ojan@chromium.org> wrote:
> ± > There doesn't seem to be any opposition to this. Can we change the
> ± > spec soon? I'd really like to make this change ASAP. We keep hearing
> ± > reports of people hitting this and getting confused.
> ±
> ± My only hesitation is that MS people haven't commented yet.  I'm explicitly
> ± pinging them in the CC list.
>
> You want to hear from Rossen, as I am no longer in the loop for usability concerns that you are describing.
>
> I did advocate adding 'auto' as default min-width though and I remember that it also came from usability feedback and bugs (which were impossible to fix, lacking support of either 'auto' or 'min-content'). Without that non-zero 'flex-shrink' was unusable (especially with the original linear formula).
>
> If I understand the reverse problem correctly (do I?), pretty much every time overflow on main axis is not 'visible', you want to add "min-width:0", otherwise when random content is added it can stretch the container and totally destroy the tight layout. Right?

Yes, you got it right.  Importantly, if you have multiple nested
flexbox ancestors, they *all* need to have their min-width explicitly
set to 0, because the 'min-content' value doesn't care whether or not
the child is overflowing with scrollbars - it'll still take the full
minimum size, which is larger than the child actually is now.  ^_^
This fact makes it *much* harder to tell what's going wrong, and to
figure out how to fix it.

> One solution could be to fix exactly that - if 'overflow' is not 'visible', 'min-content' is not 'auto' by default. It would solve the new issue while doing the right thing for the original use case... I am not psyched about it (it's a special case for a special case...), although if you now think of a case where 'min-content:auto' gives you unwanted stretch, it will be clear where the problem is and the fix is probably to change 'overflow', not 'min-width'...
>
> Of other proposed changes, "min-width:0" and "flex-shrink:0" are both defaults that don’t work in very large share of cases and will bloat stylesheets with overrides, which will make Tab unhappy...
>
> Anyway, you do want to hear from Rossen... For me personally, special casing overflow seems worth considering. Otherwise, anything will work, as long as "auto" or an equivalent is still available.

If a non-visible overflow actually changes the child's minimum size,
I'm okay with this, but like you I'm somewhat uncomfortable with
laying down a further special case here.

Regardless of what we decide, the Sizing spec is nearly ready, so
'min-content' will be available for explicit use.

~TJ
Received on Wednesday, 6 March 2013 17:23:47 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:06 GMT