In August, due to a twitter discussion with Molly, and of course while partying on a Saturday night, Dave Gregory and I were looking at whether the Flexible box layout module (still a working draft) is getting close to ready for prime time yet. Our hope was that it will solve some of the frustrations we have with layout—like columns that are equal heights and vertical centering. We read the spec and some good articles. It gave us hope. We started testing on our own. That’s when we realized how much is left to do here.
First, I’ll say that both webkit- and moz-based browsers did great in our simple testing of four equal-sized boxes—whose background colors fill each container. They were they equal width, and the color filled the container whether the content did or not. Good news! There is a difference in the height of the containers between -webkit and -moz which is related to their differing treatment of the bottom margin on the paragraph inside each box. I don’t know which one is right, but find it odd that when Webkit allows the margin to escape, it doesn’t push the next element away as can happen in a floated/non-floated layout. (But that’ll be another experiment.)
The demos shown on the Mozilla site appear to work, but in real life really don’t yet work as expected.The demos work because there’s not really content in the boxes—and in that situation, the flex box does work. But check our tests to create four equal boxes with content—especially content that varies in length. Less than wonderful.
On vacation (when else is there time!?), I was reading Zoe Gillenwater’s excellent book, Stunning CSS3. If you want a well-written, easy to understand, beautiful book on the new CSS3 capabilities, I highly recommend this one. Anyway, the last chapter of the book is about upcoming layout possibilities—most of which covers the flexible box model. It got me thinking about my earlier testing. I started playing around with having widths on one or more of the boxes. These results didn’t really do what I expected.
If I give three of the boxes a width, with one set to box-flex:1, it will fill the remaining space. It doesn’t seem to matter how much content is in them.
This seems to be the most reliable way to use the flexible box layout right now—to take up remaining space.
I then, bravely, placed box-flex:1 on two of the four boxes. This, as I read the spec, should have added up the widths of the two boxes where the width property exists and then equally divide what is left over between the two flexible boxes. If I had set one box to a value of 2 and the other to 1, it should divide it into thirds, giving 2/3 to the box with a value of 2. Instead, we went back to unreliability. The boxes don’t split the space left evenly, they seem to split it based on their content. This may be the way it should work, and I may be misunderstanding the spec, but it seems very unreliable as a form of layout.
- Two box-flex and two with widths (the widths are correct)
- Two box-flex which are not next to each other with the same results
Finally, I gave the first and last boxes pixel widths. The middle two both had box-flex:1. They have substantially different amounts of content. The larger literally suffocates the smaller amount of content—even though they should be splitting it more evenly as I read it.
- The second box is overflowing its boundaries even though each line is a single word—causing the page to be much taller than it should.
- A small increase in content made it slightly wider and the page is closer to the height it should be.
I’m playing with this and don’t feel I’m the definitive expert. But I do think something is far from correct in browser implementations—or the spec needs to be much more clear. Either the boxes should be split evenly, or they should be split so that they’re the same height, but widths are based on content within (though that’s not what I think I read in the spec). Currently, the odd splitting, based on content, but not even at all, is baffling me.
Update: Based on Zoe’s comment, I did a few more tests. If widths are given to all boxes and then box-flex is added to one (or more), the dividing of space between the boxes is reliable. It seems to be when you leave the browser to use the intrinsic width as a default that unmatched content amounts gives you extremely unreliable results.
- Equally sized boxes with 1 box-flex — extra 200px left in container
- Equally sized boxes with 1 box-flex — overage of 200px
- Equally sized boxes with 2 box-flex:1 — extra 200px left in container
- Equally sized boxes with 2 box-flex — one set to 1 and the other 2
Opera hasn’t implemented flexible boxes yet (they’re reportedly waiting for a more complete spec) and though this may be included in Internet Explorer 9, as you might expect it’s certainly not in any of the earlier versions. (Update: It appears it’s not made it into the RC which is feature complete.)