.flex-1 (and possibly others) requires min-width: 0

[geonanorch]

A quick bug report around flex:

You can easily reproduce the issue by setting different horizontal paddings for the flexbox items (e.g. in the flex-1 documentation sample): the items will have different widths (and box-sizing won't change that).

To solve it the .flex-1 class (and I guess other shrinking-relating classes) should include a min-width: 0 rule.

There are quite a few bugs still with flexboxes, and possibly other workarounds would be required...

[hacknug]

I agree there might be something we can do to help mitigate this issue. I think @benface has this on his custom reset so maybe he can share some of his insight? 😄

EDIT: Yup, it's there
https://github.com/benface/tailwindcss-config/blob/master/reset.css#L3-L4

[adamwathan]

Can you post a fiddle demonstrating the issue you are trying to explain? I think I know what you're trying to say but want to be 100% sure we are on the same page.

If it's the issue I think you're describing, I don't really think it's a bug per se, it's just the expected browser behavior:

https://stackoverflow.com/questions/34753491/how-does-flex-shrink-factor-in-padding-and-border-box

I agree it's unintuitive but Tailwind isn't really doing anything wrong here. If you want to get the behavior you get with flex: 1; min-width: 0 you just need to use the classes flex-1 min-w-0.

[benface]

Yeah @hacknug I put that in my reset because the default min-width for flex children (or min-height when the flex-direction is column) is not 0 like it is for all other elements, but auto, which prevents items from shrinking past their minimum intrinsic size (it is similar to min-content in that regard, but not quite the same: https://twitter.com/tabatkins/status/1066725586939211777). I find that unpredictable and I'd rather control overflow myself, hence the reset, but it's not a bug. More information: https://stackoverflow.com/questions/36247140/why-dont-flex-items-shrink-past-content-size

[4refael]

Although this is not a bug, I think adding min-width: 0 to flex-1 may not be a bad idea, because in 99% of the cases your intention is the columns to split evenly.

[geonanorch]

Hi all. Okay, strictly speaking not a bug, sorry about that.

Still, anything so counter-intuitive (gosh, not even applying border-box will make it behave as one would expect!) deserves handling.

@adamwathan I would still like to report this issue knowing it is not a bug: fixing it make the developer's life simpler and more efficient, which fits nicely with tailwind's aim (my understanding of it, at least).
Here the requested sample:

    <div class="flex w-16">
      <div class="flex-1 border">no padding</div>
      <div class="flex-1 border px-8">with padding</div>
      <div class="flex-1 border">no padding</div>
    </div>

[adamwathan]

Not planning to bake this in to flex-1, I think it makes more sense that it just does exactly what flex: 1 does.

[cgodo]

Sorry to resurrect this, but I spent a lot of time with issues about scrollbars with flex-1 items in column direction and maybe this info helps someone:

Tailwind flex-1

In Tailwind, flex-1 utility translates into flex: 1 1 0%.

The W3C recommendations specify that flex: <positive-number> should translate to flex: <positive-number> 1 0, but browsers like Chrome or Firefox, for example, translate flex: <positive-number> to flex: <positive-number> 1 0% (notice the percentage). I guess Tailwind team decided to follow browsers implementation rather than W3C recommendations in this case.

Wait, isn't it the same?

Nope. It's important to note that flex: 1 1 0% with a percentage is NOT the same as flex: 1 1 0 without a percentage, as some might think.

From W3C recommendations:

For example, percentage values of flex-basis are resolved against the flex item’s containing block (i.e. its flex container); and if that containing block’s size is indefinite, the used value for flex-basis is content.

In other words, using flex: 1 1 0% on an element with an indefinite container width is the same as using flex: 1 1 content, which in the majority of the cases it behaves the same as flex: 1 1 auto.

My scrollbar isn't working. Why?

A common issue related to all this would arise when using nested flex-1 elements and think they will size correctly with an inner scrollbar. This fiddle https://jsfiddle.net/hq8ukfdj/32/ demonstrates how the first case with flex: 1 1 0% does not show a scrollbar and the content overflows its container, while flex: 1 1 0 sizes and shows the scrollbar correctly.

So remember, if you see your nested flex-1 elements overflowing without a scrollbar, it might be related to this.

[geonanorch]

While this is a fine example of what is wrong with web "standards", I for one am grateful for the tip! 🙏

[alesmenzel]

@adamwathan Hi, sorry to open this old issue, but the flex-1 (flex: 1 1 0%) is a bit weird when used in column layouts where the height is indefinite, whats the reason for using 0% instead 0px as the latter would work in both row/column contexts?

[KianYang-Lee]

@adamwathan Hi, sorry to open this old issue, but the flex-1 (flex: 1 1 0%) is a bit weird when used in column layouts where the height is indefinite, whats the reason for using 0% instead 0px as the latter would work in both row/column contexts?

Cause that's what actually flex: 1 is?