Why is Firefox Dicking Around With Flexbox Support?
You probably know that Flexible Box Layout, or Flexbox, is one of the shiny new layout modules offered up by CSS3. You’re also probably aware that it’s hot stuff. It even won a .net award for the best new web technology at this year’s awards! And let me assure you, it was well deserved.
For all the new toys and features that CSS3 has brought to the table, Flexbox is the one that genuinely has the potential to truly revolutionise the way we lay out our web pages. It’s that good.
Browser Support for Flexbox
As a result of its awesomeness, the browser vendors have understandably been particularly keen to get on board and offer up some support. This is good in terms of speeding up the module’s development, but it did lead to quite a messy situation initially when the spec’s development brought with it several wholesale changes.
The major browsers are gradually implementing support for the updated specification, but this transition period has created a bit of a mash-up of support for the old and new Flexbox syntax. Here’s a quick run down…
- Internet Explorer
- 10, old syntax,
11+, new syntax, un-prefixed
- 4-20, old syntax,
21-28, new syntax,
29+, new syntax, un-prefixed
- 2-20, old syntax,
21, new syntax,
22+, new syntax, un-prefixed
- 3.1-6, old syntax,
7+, new syntax,
- 12.1 (Presto), new syntax, un-prefixed
15+ (WebKit), new syntax,
Like I said, a bit of a mess. But we’re getting closer and closer to universal support for the updated spec with each new browser release. For a bit more on the differences between old and new, Chris Coyier (who else?) wrote a quick article about how to tell if you’re reading about the old Flexbox syntax or the new Flexbox syntax.
How Firefox Dashed My Dreams
As you can see from the preceding list, the new syntax has arrived in all current major browser versions bar IE, whose release cycle is obviously far less frequent than the others. Chrome, Safari and Opera all offer complete support for the entire Flexbox module through the
-webkit- prefix, which is fine. It’s understandable if they don’t feel comfortable dropping the prefix just yet considering Flexbox’s mutability in the not too distant past.
What’s not fine, in my opinion, is Firefox’s approach. It is currently the only browser to offer un-prefixed support; however, crucially, it lacks support for the
flex-wrap property which as you can probably guess, controls wrapping in your Flexbox layout.
Note: Firefox also lacks support for the
flex-flow property, but this is just a shorthand method of specifying the
flex-wrap properties, so wrapping remains the only issue.
The default value of
no-wrap, which ensures that all flex items will ‘flex’ their widths in order to fit on one line, which is one the main draws of this new layout mode. However, there will obviously be times when you need your items to wrap rather than flex; I’m going to use this very blog to illustrate the issue.
Why Wrapping Control is Needed in Flexbox
You may or may not have seen this blog’s home page, but it includes a few additional features in the top toolbar that aim to present the list of post excerpts in some more experimental ways (you won’t be able to enable these features if you’re on mobile by the way (or if you’re using a shitty browser)).
One of these features is a simple box layout mode, which I used Flexbox for in order to utilise its trivial support for dynamic, equal height columns. The following shot shows how Chrome handles things.
And here’s what happens if you remove the
flex-wrap: wrap; rule…
That’s right; if I included the un-prefixed Flexbox properties/values, this is how Firefox would render the layout. Far from ideal.
But the main annoyance here is that Firefox has removed my right to future-proof my CSS by including the un-prefixed properties. I can’t deliver these un-prefixed properties to future browsers that can handle them, including the upcoming Chrome 29, because the layout will break in Firefox. Which is really shit.
Prefixes exist so browsers can implement experimental properties. If you can’t provide full support, then for me, it should still be considered an experimental implementation and so these prefixes should remain intact.
From my point of view, it seems as if this is Firefox’s way of tackling the tendency for some developers to accommodate only WebKit browsers. Similarly to Opera, although they took a different approach by actually implementing support in their browser for the
-webkit- prefix. They have of course completely switched to the WebKit rendering engine since then.
Anyway, time to wrap up (sorry) my rant on Firefox un-prefixing prematurely. Sort your shit out FF.
About Stephen Greig
Stephen Greig is a 25 year old Freelance Web Designer/Front-end guy, currently living in Nottingham, UK. Stephen is also the creator of messivsronaldo.net and author of CSS3 Pushing the Limits, a book on advanced CSS3. You should follow him on Twitter where he talks about the web, sports, music and swears a lot. Stephen's also on Google+ if that's more your bag.