IE-first Responsiveness and the Minimum Viable Experience
How you can embrace the raw power of CSS to design for IE and fall-forward to modern technology
If you’re reading this you’re probably familiar with responsive web design, and the contingent that says you’ll fare much better if you design for the compact mobile experience before inflating it on the desktop.
The value of going mobile-first is that it’s much easier to design small and build it up into something bigger. More often than not you’re dealing with a very linear flow of content on a small screen, whereas on larger devices and laptops the most efficient use of real-estate requires a more fluid arrangement of elements. It’s much easier to design for that small experience and then make it bigger to suit larger screens than it is to shoehorn the big design into a small device. The only sacrifice is the additional mental cost required to take your usual design behaviours and turn them upside-down.
So it is with CSS Feature Queries, which are like responsive media queries only the responsiveness is now based on what CSS the browser can deal with.
You might notice a certain chicken and egg problem here, which is that you can’t use feature queries unless feature queries themselves are supported. Much like mobile-first responsiveness though, you just have to reverse your logic and it works exactly how you’d expect.
Enter IE-First Responsiveness.
IE-First responsiveness is where you write your default CSS to support IE, and then rely on the feature not supported by IE to add things only newer browsers can understand. This is novel in the sense that progressive enhancement traditionally only applied to Javascript, and when it came to presentation you were shit out of luck unless you accepted that you’d have to script part of the design.
Browsers don’t parse or render CSS they don’t understand, they just ignore it completely. This is both a blessing and a curse as it demands extra tooling to actually figure out errors in your CSS, but the laid-back approach to validation means features like this can actually exist in a backwards compatible manner.
This means that if you want to enjoy supporting modern browsers without tearing your hair out, you’ve got to treat your modern CSS as a progressive enhancement. This provides at least two huge benefits and one big why?
Failing fast
If you’re writing IE compatible CSS by default then you are totally avoiding the problem where you build your entire site or web-app in Chrome and, a week before deadline, open it up in IE and stare wide-eyed at the eldritch horror rendered before you. Check it in IE at the start and you’re staring into the abyss, but you’ve got time to close it off; check it in IE at the end and the abyss is staring into you.
You’ve already solved a plethora of bugs because you anticipated them at the start by offering a minimum viable experience, which you can then build up. Nobody is saying your site has to behave totally identically in IE to how it behaves in a much more modern browser.
Progressive enhancement
You’ve supported the worst case by default, and now CSS offers a very nice way for you to improve upon that for every browser that supports it, so you can start layering on the niceness. Before feature queries, supporting IE was like baking a cake with a chassis — just gotta make sure the sponge and the filling is good, and that you apply the icing in such a way that you can just swap it out for another icing if you’ve got a difficult customer.
Of course, the reality is that your cake filling and cake icing are bonded together in such a way that performing such a task pretty much makes the icing worse for everyone. Nobody cares about the cake at that point, it looks like shit.
In fact, a surprising amount of cross-platform development is like baking chassis-cake.
Begging the question
“But if I’ve gone to all the effort of supporting IE first, why would I bother writing even more CSS for newer browsers?”
If the experience in IE and in other browsers is functionally identical because of that CSS, then of course there is no reason to start using feature queries to do the exact same thing in a modern way. That’s just plain hard to maintain.
The thing with progressive enhancement is that what you add is an improvement to the user’s experience (ideally), and if you don’t need it then you don’t need it. It really is as simple as that.
The Minimum Viable Experience
Progressive enhancement and responsiveness isn’t a revolutionary concept, but I frequently encounter and raise questions about supporting legacy browsers like IE, and it is almost always secondary to the mission. It’s often a total afterthought because nobody really wants to deal with it if they don’t have to.
Designs are getting more beautiful and more complex and not all of this can be easily replicated in an older browser, or even a relatively recent phone if you can’t afford a brand new Samsung Galaxy or an iPhone. Sometimes developers will serve an IE-specific stylesheet using conditional comments, or even throw up its hands and redirect people to a modern browser, and it’ll either present a thoughtless, degraded experience or none at all.
Take a look at your analytics data and browser support stats and, if you find a legacy browser like IE topping the results and you’re considering a fresh design, why not try building for IE first and using the new feature queries to embellish it for the other users? The truth is that even when you do come up with a wonderful new design, you still have a margin of error where you’ll accept some deviation from pixel-perfection, and it’s much better in terms of the expectations you set to make sure the lower end of the experience is well accounted for, before you have to go back and tear apart your work to make it functional for most users.
It is always easier to build up than it is to build down.
