My FeedDiscussionsHeadless CMS
New
Sign in
Log inSign up
Learn more about Hashnode Headless CMSHashnode Headless CMS
Collaborate seamlessly with Hashnode Headless CMS for Enterprise.
Upgrade ✨Learn more
The legacy support conundrum or why mini.css doesn't like Internet Explorer

The legacy support conundrum or why mini.css doesn't like Internet Explorer

Deactivated User's photo
Deactivated User
·May 5, 2017

Lately, I've been getting a lot of comments from people asking me why mini.css does not support legacy browsers and specifically the slow and (hopefully) dying Internet Explorer. At first, I just dismissed most of them, but lately these legacy supporters have grown more and more vocal about this, so I decided to finally address these concerns once and for all by explaining my view on the topic.

Just a quick look at the codebase or even the documentation is enough to figure out that the framework aims to be small and allow people to develop websites and web applications for desktop and mobile devices without having to stylize virtually anything. All of this is achieved using Flexbox, some creative CSS tricks (pun intended) and a lot of optimization in terms of what goes into the final stylesheet.

Here lies the first argument for why older browsers do not play well with mini.css and that is Flexbox itself. While it's a well-established part of any CSS stylesheet nowadays, it still seems to be one of those things that people argue about and have some difficulty adopting.

Why? Look at the browser support for Flexbox and you will soon understand that, while it seems like it's almost fully supported everywhere, certain browsers like IE have a large amount of bugs and other browsers like UC browser make no effort to implement the latest standard. While it's absurd to ditch them entirely and go for the latest and shiniest you can, development time is not unlimited and you have to strike a balance between practicality and legacy support.

But that's not all. Other features like object-fit are just not a priority for certain browsers (I'm looking at you, Microsoft). It's just ridiculous that in 2017, Edge has not even made the effort to implement this feature, while Chrome first added it in 2013. 4 whole years and this still isn't a thing for Microsoft browsers!

And when all of this is said and done and you've scratched your head for several hours and tried to write code that you cannot test due to not having legacy browsers to test it on or being on an entirely different OS, you remember about prefixes. Now, a sensible person would just use an autoprefixer, bloat their code and be done with it. But, like I said earlier, mini.css cares about size, because I spend a lot of time on my phone while on the bus and my internet connection is terrible.

So, I have to manually prefix the parts I want and actually choose the prefixes that make sense, because there is no point in using -webkit- for transitions anymore. Oh, and then you remember about styling progress bars and placeholders and you have to figure out the naming for every browser and all of that and then, after you suffer a mild panic attack, you realize that CSS is a mess and there is not way your framework can fix it.

Having suffered this procedure for hundreds of hours, I decided to drop support for IE officially, so that people do not expect their website to magically work on any old laptop. That was a hard decision, but one I stand by to this day. IE is a dying browser, it will go away soon and Edge is already taking its place. For the remainder of the time that IE is alive, 85% or so of the framework works pretty well in IE 11 (come on, what's the excuse for having an older version of IE if you're using it?), except maybe the odd image here and there and some column reordering rules.

It's not such a big deal that mini.css does not officially support IE and that's because it's just a temporary inconvenience and there is nothing I can remove that will break the browser's support, simply because there is none to begin with. About 85% support on IE 11 for a framework that states that it does not support IE is pretty good, provided that other frameworks that support IE work the same or worse on it.

If there's one takeaway here is that legacy browser support is a choice and quite frankly it's a difficult one. The problem is not if the developer wants or has the skill to code a framework that can support older browsers, but if these older browsers are cut out for the heavy lifting we expect from modern websites and all the crazy stuff we do with them. Sometimes, the answer is yes (about 85% of the time, apparently), other times it's not. We just have to accept those limitations or stop supporting old software.