Browsers - Developer tools

Debugging Internet Explorer in 2019

Even though Microsoft has explicitly told the world to stop using Internet Explorer 11, many organizations still have a significant enough IE11 user base that they have no choice but to build their products to acquiesce to the aging browser’s idiosyncratic demands.

Whether you are new to the world of building the front-end for Internet Explorer 11 compatibility or you are an old hand who knows their way around all the IE11 pitfalls, read on to learn more about:

  • Choosing the right environment for debugging
  • Dealing with unsupported JavaScript
  • Tackling CSS layout issues
  • Understanding the IE11 debugger

Armed with these tips, one should be able to quickly solve problems in the instance when a web application works perfectly on everything but IE11.

Go beyond console.log with the Firefox Debugger

Promo art for the Firefox Debugger Playground: a styled insect with the words "go beyond console.log" below it.

console.log is no debugger. It’s great for figuring out what your JavaScript app is up to, but it’s limited to spitting out a minimal amount of information. If your code is complex, you’ll need a proper debugger. That’s why we’ve added a new section to the Firefox Devtools Playground that’s all about debugging. We’ve built four basic lessons that use the Firefox Debugger to examine and repair a simple JavaScript to-do app.

Developer-facing implementation errors

This is a great way to guide other developers who may use your code or components to use the correct elements for accessibility and other reasons:

In our script, we can detect the element nodeName and return an error message if it is not BUTTON. We use return to stop the remainder of the IIFE (Immediately Invoked Function Expression) from executing.

Code language: JavaScript

if (toggletip.nodeName !== 'BUTTON') {  
  console.error('Toggletip buttons need to be <button> elements.')
A screenshot of a browser's developer console with the error message 'Toggletip buttons need to be button elements.' shown.

CSS tests and error messages

In Inclusive Design Patterns I write about creating deliberate visual regressions to highlight code errors, and providing error messages in the developer tools CSS inspector.

The error we caught with JavaScript earlier can be caught using the CSS selector [data-tooltip]:not(button). We can highlight the erroneous element with a red outline, and provide an error message using the made-up ERROR property:

Code language: CSS

[data-tooltip]:not(button) {
  outline: red solid 0.5em;
  ERROR: Toggletip buttons need to be <button> elements.

Despite being an invalid property, the ERROR will appear in dev tools when the element is inspected.