Should I try to use the IE version of Grid Layout? Revisited for 2018
In November 2016, I wrote an article in response to a question about Grid support in IE10 and 11. In that piece I wrote a quick rundown of what parts of the modern specification were supported in the older IE version. During a recent discussion onstage at An Event Apart, the issue of using the
-ms prefixed version came up. As Jeremy Keith has documented his thoughts on that discussion, I thought I would post mine as a response to his post and also as an update to my previous article.
Should I create a fallback version specifically for IE10 and 11?
It is possible to use the
-ms prefixed version to create a fallback, although it misses some features of the modern specification. The question really is, is it worth you going to that trouble for a diminishing number of visitors, when you will also need to create a fallback version for browsers which do not have grid and are not IE10 and 11. That’s three versions you are creating and, as Jeremy points out, it makes far more sense to make one fallback for everyone.
The only reason I would be considering using the
-ms prefixed version at this point, would be in the following situation:
- I need to do something which only grid can achieve.
- And, the
-msprefixed version would be overwhelmingly better than a simpler fallback.
- And, I have a large percentage of visitors in IE10/11.
If making your site look exactly the same in browsers which do not support grid as those which do support grid is that important, maybe don’t use Grid Layout. This is still a valid choice. That way you can use legacy techniques which work in modern browsers as well as legacy browsers. If you want to do something that can only be done with grid however, then you need to think about non-grid supporting browsers. This includes IE10 and 11.
In the majority of cases your float-based fallback will be just fine for all of the legacy browsers. If there was something that would be much better when using the
-ms prefixed version, I wouldn’t try and do my whole layout in grid. I’d use my simple float-based legacy fallback, and in one or two places where it made sense, throw in some
-ms prefixed grid to enhance the layout for IE10/11. Using the type of technique I describe in my article Pattern Library First makes that kind of component based approach much more straightforward.
An approach of enhancing browsers based on their capabilities will tend to get you the best results, whether the CSS in question is Grid, CSS Shapes or anything else. If you can enhance your layout for IE10/11 with judicious and careful use of the prefixed version, and you have the time to do so, that’s great. However you still need that float-based fallback, so start with that first.
Should I use Autoprefixer with Grid?
I would strongly suggest not.
To use Grid Layout with Autoprefixer means remembering which bits of the spec you can’t use and limiting your use of the spec. Then carefully testing to make sure Autoprefixer hasn’t blown up your layout in Internet Explorer because you accidentally used one of those bits. You are adding complexity and testing requirements, not taking them away, no matter how attractive being able to run something that promises to sort it all out for you might be. As the prefixed spec is so different, you can’t fix compatibility with an automated tool, this isn’t just prefixes. So you still have to remember a pile of stuff, in this case all of the things you can no longer use in order to use Autoprefixer. Does it really make sense, to take a spec which is implemented pretty much in entirety across modern browsers, and limit your use of it due to the fact that a particular old browser exists?
If using Grid in IE is so important to you, learn how Grid works in IE, and create fallback layouts with that spec, rather than hobbling your use of Grid in order to run Autoprefixer. However, with every month that passes, making special versions for two types of old browser makes less and less sense. Personally, I’d spend that time making my site more usable, accessible or beautiful for the majority of my users.
As Jeremy notes, the usefulness of a tool like Autoprefixer is diminishing, which is a good thing. It is becoming far easier to code in a way that supports all browsers, where support means usable in an appropriate way for the technology the user has in front of them. Embrace that, and be glad for the fact that we can reduce complexity based on the increasing interoperability of CSS in our browsers.