How to Deal With CSS Issues in IE When You Have No Idea How to Fix Them

I've been working closely with cross-browser compatibility issues for more than 5 years, and during that time, quite a few people changed on the project I'm working on. During this time, I noticed that developers are often only as proficient in CSS as they need to be to get a given job done, even if a person positions themself as a web developer. These issues are most often highlighted when it comes to supporting Internet Explorer.

For those who've never been deeply involved in such issues, I'll explain what makes IE so special and hard to work with. First of all, developers are not often using Windows as their OS on laptops/computers for development. To work with IE, to verify that it works as expected, you have to install VirtualBox with Windows on it.

You may also like: How to Build a Website Compatible With IE

The problem is that such an environment is not very handy to work in; it's slow for medium/large frontend applications, even if you have 16GB of RAM on the VM you're working on. 

Secondly, IE doesn't provide the best developer tools for inspecting elements. Yes, you can see what styles are assigned directly to elements. But, in comparison to Chrome Dev Tools, where you can see where style is inherited from, IE's offering pails in comparison. 

The third problem is that hot reload doesn't work for VMs. It takes some time to reload the application and navigate back to a place where the problem you're working on is. This isn't the end of the world, but time is wasted.

Tools like PostCSS can significantly improve your CSS/LESS/SASS codebase. They give you access to plugins, like autoprefixer, which will add vendor-specific (FF, IE, etc.) prefixesto your CSS.

Take the following style as an example: 

::placeholder {

  color: gray;

}

This will be transpiled to:

xxxxxxxxxx

::-webkit-input-placeholder {

  color: gray;

}

::-moz-placeholder {

  color: gray;

}

:-ms-input-placeholder {

  color: gray;

}

::-ms-input-placeholder {

  color: gray;

}

::placeholder {

  color: gray;

}

There are other interesting plugins you can check on their site: https://github.com/postcss/postcss.

Now, let's dive into the main part of this article. What do you do when you IE gives you trouble? In my experience, these problems can be divided into three different categories: 

• Some code changes were made, and the browser completely crash. If you're thinking, "CSS can't crash a browser," believe me — it's possible! Some combinations of CSS properties on a hierarchical level can lead to a crash in IE. In this scenario, it helps to remove code until the application starts working again.
  • To make this process relatively fast, I approach it with removing half of the code, if it is still broken, half of what is left. If the code starts working, I add back half of what I removed before. In some cases, after several iterations, I have a suspicious area and then a couple of more tries gives me the exact line.
• The second type of problem is when code perfectly works on Chrome, Firefox, but not on IE. In such cases, 100% of the time only reading/googling helped me to fix issues. I encourage you to do the same. Don't spend your time playing with properties. Almost always, I wouldn't have guessed or intuited the root of the problem on my own.
  • Sometimes, I forget about this rule myself and try to play around. It inevitably results in a bunch of wasted time. I know you can find a lot of bad ideas on Stackoverflow, opened Github issues threads, but always you'll find some great answer/article/explanation for your case. There are many people dealing with IE. You are not alone, and more often than not, the issue you're facing has been solved before. 
• The third type is when a developer thinks that they tried "everything" but it nothing helps. In this case, collaboration helps a lot! In our company, none of us are close to all-knowing when it comes to debugging IE issues. There were moments when people gave up on problems with configuring Selenium Grid to run on IE, fixing issues with flexbox on IE, icons, etc. Here's helps in this situation:
  • Give it to another person.
  • Join that person and look at it together. I remember the case when an article was written on solving a specific issue, and the developer reading the article just didn't catch the gist of the author was explaining even though the solution was described (not in a code :-) ). With another set of eyes, they were able to see how to solve the problem and implement that fix. 

I'm working on a project where we support IE. First, it was version 9. For the last five years, it's been 11. The codebase is, I would say, big. It's almost half a million lines of code. So far, we didn't use any specific CSS only for IE. It's always possible to find a solution to work for all browsers. It's possible to automate the whole process of testing it and keeping tests stable and green.

I know that it takes a lot of effort, but it has a real payoff. When the application has hundreds of different screens and cases, manual testing will acquire a lot of people's resources. We achieved that having no testers on a team.

One of the setups for tooling that we found helpful was Protractor with Selenium Grid. Protractor by itself has a lot of problems, so you need to understand the pitfalls inside it and know how to overcome it. Several issues include:

• Actions are treated by protractors as executed, but it just sometimes does nothing.
• Typing out of the shelf is terrible, especially in IE, as it skips letters during typing.
• Protractor does not always wait properly for a condition, especially when the page is changed, or you replace one component with another.

Hopefully, all of that is fixable, and it's possible to make it work for Chrome, Firefox, and IE. I recommend that you never use direct protractor code, but wrap it in some DSL, where you do it in two levels. The first level makes basic commands, like click, type, etc. For that, you can check out my project https://www.npmjs.com/package/protractor-base-dsl to get a basic idea of how to make operations stable.

If you want to have a separate article with a detailed explanation about this topic, I can do that! Leave a comment! The second level of DSL will do some business operations, like the open page, submit a form with provided values, etc.

Quite often, to find problems before fixing them, e2e tests help. When you run them and watch, you can find what you might have missed during development/testing/hardening. It is rare that anyone goes through all the pages manually to type all possible cases before release, even QAs.

Please share your thoughts and your own experience on this topic. I'd love to hear from you!

Further Reading

How to Develop a Web Application Compatible With Internet Explorer 11

7 Ways to Test Your Website on Internet Explorer on a Mac Device