Internet Explorer 10 bugs

With Internet Explorer 6 and 7 moving towards extinction, a brave new world is opening up in front end web development – Internet Explorer 8 is now the new least common denominator. Onwards to Data URI, CSS counters, CSS table layout, and CSS-generated content with pseudo-elements!

Oh, you knew there was going to be a catch. Let’s talk pseudo-elements.

Relative font-sizing of pseudo-elements

The brilliant thing about pseudo-elements in CSS is the fact that you don’t have to litter your HTML with more code to add some design-related elements. The brilliant thing about CSS3 is the ability to create image-looking elements purely through CSS. Combine them, and you’ll be doing web design straight through the browser via CSS.

For example, a common design pattern, a "play" icon overlay to let the user know they can click the element to play a video:

I Can’t Believe It’s Only CSS™! Well, believe it, it is. Here’s the secret behind the magic:

Now that’s all fine and dandy, but let’s pretend we want to modify this CSS rule in certain situations. Maybe we want the icon to be a bit smaller when it’s being shown in an aside. Let’s overwrite the previous font-size with a new one:

The way pseudo-elements work, there is only one ::before and one ::after pseudo-element per element. (By the way, the single-colon CSS2.1 selector format for pseudo-elements is being used in the example due to IE8 not understanding the newer CSS3 format.) Our new font-size is replacing the previous one, because it’s being set on the same (pseudo-)element. At least that’s how everyone except Microsoft sees it.

Here’s how our icon overlay looks now, Chrome 26 on the left, Internet Explorer 10 on the right:

See, this is why web developers can’t have nice things. Once again, Microsoft disagrees with everyone else on how the font-size cascades for pseudo-elements. Apparently they deem pseudo-elements to be self-cascading.

Instead of overwriting the previous font-size, the em-based font-size is being compounded with the previous, as if it was its own child element. Instead of changing the font-size from 3em to 2em, IE10 has multiplied them together to get 6em. That’s just great.

What does that mean? If you’re going to modify the font-size of a pseudo-element after first setting it, you have to use something other than relative units, so % and em are off the table. So you’re basically left with using px. The rem unit isn’t available until IE9...

I've filed a bug report with Microsoft regarding this, please verify my work and notify Microsoft that you can reproduce this error.

Mind your widths and heights

For rendering purposes, one should always define a width and a height attribute on images, so that the space can be reserved and the flow of the document determined before the image has loaded. In many cases, the dimensions of an image are dynamic or not known to the HTML author, so they cannot be set.

Perhaps, through author error or CMS error, a width or height attribute are set on an image with an empty value. According to the HTML specification, only non-negative integers are valid for these dimension attributes, an empty value is therefore invalid. What should a user agent do with an invalid value?

Microsoft seems to have decided that an invalid dimension should be treated as 0 – or 1. If you leave an empty height attribute on an image, Internet Explorer doesn’t ignore it and render the natural image dimensions (like all other browsers), but decides that the height should be given the value 1. Which makes it look like this:

Apparently Internet Explorer is written in a programming language that equates null with 1.