Adventures in Website Design && Development – 5/22/14

As a practicing and learning Website designer && developer, I come across many Website creation related tools, examples, demonstrations, and concepts. When possible, I try to use these elements in my own work. Adventures in Website Design && Development documents my many findings and passes them along to you. In this way, we both are on an adventure to become better website designers and developers.

Have you ever visited a website that contained some code that might have been helpful except for the fact it was practically illegible because the font was really, really small? If you are unsure, maybe the following picture can help.


You have probably either selected the code and pasted it into an IDE or other text field where you can read it or left the page without caring. Why would someone intentionally do a thing like that? It makes the site design points decrease and reader retention diminish, not to mention a possible bad light shown on the designer(s) of the place.

Cut them a little slack will you? It is not completely their fault. They are simply trying to work around Internet Explorer’s wacky actions yet failing to double-check cross-browser compatibility and consistency. πŸ˜›

That is the topic of this edition of Adventures in Website Design && Development, which I have alternatively titled Internet Explorer, pre, and em. We are going to be exploring this scenario, why it happens, and how we can avoid making this mistake ourselves.

So what is really going on here? Obviously, I am going to tell you. πŸ˜› Bonus item: I have put together a live demo (works in all browsers thanks to some not-too-fancy coding) to help visualize this issue. Find it at I will be referring back to this demo throughout the remainder of this post, so keep this page open. πŸ˜‰

It all starts with the HTML <pre> element, used to preview code snippets while retaining any formatting. Think of it as the <p> element for code. It preserves formatting used by the code, and displays it in a looks-like-code font (usually a monospaced or non-proportional font, subject to designer override). It then transitions to the em value used for font-sizes, used by responsive web design to obtain a consistent font size on all screen sizes. Finally it transitions to Internet Explorer, which at version 11 is still the least HTML5 compliant browser and contains page rendering issues other browsers do not have.

Yes, I know I have been very vague so far. Allow me to explain this phenomenon right now.

Small note: this is not restricted to purely em values. This applies to “pure” px as well. I am simply using ems here for easier explaining and good website design principles as explained below. πŸ˜‰

As I alluded to earlier, expressing font sizes in ems is a great way to ensure text consistency between different browsers. If the web designer chooses (as I did on the Triangle Land GitHub Pages annex), they may change the “default” look (Exhibit A) of the HTML <pre> element, including changing the font size and expressing it in ems. For all other browsers, this is fine, as they have no “bone to pick” about it. Internet Explorer, obviously, does. You see, ems do their thing so to speak using relative measures. 200 pixels from the left side of the page on your 1080p, 25″ monitor looks very small, but the same location on a 720×1184 7″ mobile device might be a fourth of the way towards the middle of the screen. ems remedy this by calculating the size dynamically. This is the why it is popular in responsive web design. Internet Explorer, for whatever crazy reason it has, cannot understand the relationship between <pre> and em. So if I set the font-size to 1.1em, for example, Firefox and Chrome will correctly display the new size (Exhibit C), but IE will display it even bigger (Exhibit B)! In order to fix this, I change the value to 0.8em, which looks fine in IE (Exhibit D) but in every other browser, the text is nearly illegible (Exhibit E)! You can also see this in action by the computed font size for each box. IE’s 17.6px value for 1.1em is significantly larger than Firefox’s 14.3px (just 14px in WebKit). While not as significant, the 10.4px (WebKit 10px) value for 0.8em is just different enough from IE’s 12.8px.

Now that we know the problem and its cause, what are we going to do to avoid making such a mistake ourselves? The first thing is obviously to perform more thorough cross-browser testing. πŸ˜› Beyond that, you have some options.

  • Define your own styling for the <pre> element. It is not the easiest task in the world, but it can be done. If the browser’s <pre> element styling does not match your site’s design, or you want to slightly tweak the element, follow this route. The issue discussed here still applies, mind you, but depending on the font you use (assuming you do change it), the effects may be lessened). Popular website frameworks such as Bootstrap and Foundation may handle styling for you.
  • Use an alternative code display box. Instead of the pre element, a different code box may be used. Two noteworthy alternatives would be Alex Gorbatchev’s SyntaxHighlighter, which is even used on, or GitHub Gist, which can be embedded on pretty much any site (including
  • Use JavaScript and browser detection to adjust the size. You would first set the font size to the appropriate value for the browser most of your visitors will be using. Then, in some JavaScript run on page load, you detect the browser being used (by either feature detection or user-agent sniffing), and adjust the size accordingly. While this technically works, your visitors may see a slight delay between page load and JavaScript execution (refresh my demo page a few times for an example). While it may be only mildly annoying, it is better to “get it right” to begin rather than fix it “as you go”.
  • Leave it as-is. Seriously, just leave it alone. All browser’s default font size for the <pre> element is 13px (IE is the odd ball still, 13.33px). Setting the size to 1em resume Internet Explorer’s wacky behavior by using a 16px font. All other browsers continue to use the standard size. (It would actually take 1.24em in other browsers to reach IE’s size.) If the default design is not bothering you or mess up your site design, then do not touch it. As implied earlier, this looks the same on pretty much every browser.

Next time on Adventures in Website Design && Development: we look at another Internet Explorer rendering issue, this time related to one of a web designer’s best friends: vector graphics.

Same Triangle Time!
Same Triangle Channel!



One thought on “Adventures in Website Design && Development – 5/22/14

  1. Yes, I totally agree with you because every risk had a failure and success both. If you win then it will increase your confidence and if you loose and face some problems then don’t give up, resolve all the errors and win.

Comments are closed.