IE, Unicode, freakout boxes and CSS

November 2, 2008 / Dealing with special characters when Internet Explorer can’t.

Update: Raphael’s solution (e.g. font-family:"Arial Unicode MS",Helvetica,sans-serif;) works like a charm and is much better than the long-winded version I’ve written up here.

My site uses a check mark to denote a visited link. Unfortunately, when I first implemented that style my old friends IE6 and IE7 showed freakout boxes instead.

I have seen these little buggers before and on that occasion they won the round. Although I’m growing increasingly reluctant to hack my personal stylesheets for You Know Who, today I changed my mind about tolerating IE’s mangling of my intentions. (About 40% of visitors to my site use IE so a fair number of people see this.) Regarding freakout boxes I believe the IE development team and I are now even.^†

For whatever reason, sometimes when IE is asked to render a glyph that does not exist in the font that the stylesheet is saying it should be displayed in, it will give you a freakout box. Other browsers (e.g. Camino, Chrome, Firefox, Omniweb, Opera, Safari) deal with it more gracefully. I think they look for other fonts on the system that contain the glyph the page wants to display and use that font instead, just for that glyph. On OS X it’s Lucida Grande:

The check mark is actually specified in the stylesheet as generated content, rather than in the markup. Perhaps that is what is causing IE7 to choke in this case, because it is supposed to be better at “font linking” for characters in the Unicode BMP (Basic Multilingual Plane), which means characters in the range 0000–FFFF. Check marks are within that range, which makes me think it might be a generated content bug.

Here is the CSS that causes the problem in IE:

a:visited:after {color:#6699CC; content:"\00A0\2713";}

Which means, add a space and then Unicode character 2713, “check mark,” at the end of an anchor (link) element that has a pseudo class status of visited, and make it a certain shade of blue. From the figure above you can see that IE gets the content generation and colour to happen, but chokes on producing the correct glyph.

Earlier this year Eric Meyer wrote about font-family declarations and special characters and it got me wondering if I could fix this problem by specifying a font that IE would know did contain a check mark character—not necessarily the Unicode character, but a similar character. I chose Webdings (a Windows core web font), thinking that I needed something with a lot of symbols in it, and used the arcane Windows Character Map to tell me what the check mark character’s numeric value was. (I don’t know about Vista, but the OS X Special Character Palette smashes the competition on this.)

I then wrote a kludge for IE6 and 7 that replaced the declaration calling for the Unicode 2713 check mark after a link with the Webdings character 0061:

* html a:visited:after,
*+html a:visited:after {content:"\00A0\0061"; font-family:Webdings;}

I’m not using conditional styles for IE (everything’s in one stylesheet) so this rule uses the “star hack” for IE6 and the new star hack for IE7.

I was a little surprised to see that it worked:

Lastly, while writing this up I wondered if I was making it harder than it had to be: what if all I needed to do was specify another Windows core web font that contains the check mark character? Then all I’d need to do is use my hack to tell IE which font to use for that glyph. I used the Unicode Font Info tool to check each of Microsoft’s core fonts (other than Webdings) for the Unicode check mark character. It ain’t there.

I might be missing something in all this, but for now I’m going with the generated content bug theory, and using Webdings as the workaround.

† I’m not counting the fact that the Apple command symbol is not in any of Microsoft’s core web fonts. They can have that one.