Philip Walton

> One weird thing here: in Chrome `flex-basis: 0%` works the same as `flex-basis: auto` That's not true. They render the same in your example, but they are actually very...

Well, maybe the word "fixed-height" is ambiguous. I probably should have said "definite height". By definite height, I mean the height (or max/min height) properties are either set or determinate...

> and the flex parent which holds the two columns to fill the remaining space. If the parent is filling the remaining space, then the parent would be `height: 100%`...

I'm not following you. The workaround suggested in flexbug 4 is about `0` vs `0%`. The bug you linked to only mentions `100%`. What about the flexbug 4 workaround breaks...

Can you please update this issue to conform to the [issue template](https://github.com/philipwalton/flexbugs/blob/master/.github/ISSUE_TEMPLATE.md). Saying the answer is at the end of a Stack Overflow question isn't particularly clear.

Hmmm, FF 51 displays the same as Chrome for me, but FF 52 displays as you show. That leads me to believe this was an intentional change to comply with...

I think there is still some dispute about the correct behavior here. [As it stands now](https://drafts.csswg.org/css-flexbox-1/#item-margins.), percentage-based top/bottom paddings resolve against `height` on flex items, not `width` like they do...

Thanks, please ping this issue once it's released in Safari.

Hmmm, yeah, it looks like IE11 treats the min size declaration as the items initial starting size and calculates free space after that. Have you discovered a workaround?

@JacobDB I don't add bugs to the list unless there's a workaround. Otherwise the list would just be a bug aggregate, and I want it to be a solutions list...