There's a new CSS layout module on the block. You've probably heard about it. It hangs out with all the cool kids who make cutting-edge websites. It even wins Best New Web Technology awards.
Of course, it's the Flexible Box Layout Module, or Flexbox for short.
It's amazing. It slices, dices and enables you to create flexible layouts that are perfectly suited to the utilisation of RWD techniques. OK, maybe not the first two, but definitely the last one.
With the potential to solve so many responsive layout headaches, I couldn't wait to try it out. During the past week or so, I had a bit of time while researching my next project to see if it was something I could use in production for a new client website.
Getting to grips
After reading Rachel Andrew's CSS layout modules pocket guide from Five Simple Steps a while back, I thought I'd just go for it and get building. I broke out my text editor of choice and got to experimenting. I always find that the best way to learn a new technique is to build something with it.
I struggled for a while until I discovered prefixes. As with most of the new implementations of CSS features, prefixes are added to proposed CSS properties in specific browsers to facilitate experimenting with them before the specification is fully nailed down.
I went off to do a bit more reading and checked out a one or two articles and demos. The pick of the bunch for me was 'Using Flexbox', from Chris Coyier's CSS-Tricks.
The article gives a great breakdown of exactly what you need to do to get Flexbox working in as many browsers as possible. Under the Browser Support subheading, it gives us the supported list of browsers, obviously, with the caveat of, 'If you do all this weaving, you can get':
- Chrome
- Firefox
- Safari
- Opera (12.1+)
- IE (10+)
- iOS
- Android
The issue of browser support
The sentence that says, 'If you do all this weaving', to me, is an issue. We have to jump through a bunch of hoops to get this amount of support and, as much as we may wish they didn't, previous versions of Internet Explorer still exist and will do for some time to come. As a result, the majority of customer-facing websites will no doubt have to support them for the foreseeable future.
If we're going to build layouts for the browsers that don't support Flexbox, we have to cater for them in the way we used to. Technically, this is the way we currently do things: using percentages, ems and floats combined with media queries to create flexible layouts that work across a multitude of devices, not only consisting of the smartphones and tablets we use today, but considering those that will be unveiled in the future.
What's wrong with what we use now?
There's actually nothing wrong with what we use now. What we use for older browsers will work for all of those browsers that support Flexbox too. So, are we overlapping our CSS techniques just to take advantage of a new technology just because we can?
If we build our layouts as we have done since the dawn of responsive design, and then use Flexbox over the top of that for those browsers that support it, are we now progressively enhancing our CSS?
As far as I'm aware (and feel free to correct me if I'm wrong), there is no planned deprecation of how we currently use CSS to lay out a responsive site. And if that did happen, imagine how much work would be created to amend all of those sites you work on to use Flexbox.
It's not you, it's me
I'm not ready to use Flexbox in customer-facing sites, or any site where we, as the designers and developers, are not in control of the end-user's working environment. And that's probably the majority of cases.
Don't get me wrong, I'm looking forward to the day where I can use Flexbox, without prefixes or the issue of browser support, but that may be some time.
When will you be taking the plunge?
Words: Westley Knight
Westley is a senior front-end developer with BDA with over 12 years experience. He blogs at meteoracle.co.uk and is now jumping into public speaking.
