Icon Fonts Are Ruining Your Markup

Icon fonts are great. They’re more scalable than PNGs, they’re re-colorable in CSS, and it’s easier than ever to create them. But most of us are using them wrong, and it’s ruining your markup. Recognize this?

<span class="icon icon-calendar"></span>

This is fast becoming the de-facto standard syntax for inserting icons in your webdesigns. No need to fiddle with weird glyphs. No CSS needed to insert icons, even.


Hold up. The promise of CSS was that we could separate presentation from markup. We could create standardized, semantic and sensible markup, that could then be completely re-skinned solely by replacing a stylesheet. That was the whole point of the CSS Zen Garden. By using nonsense spans with verbose classes, that’s out the window, all in the name of convenience. I too have been bitten by the icon-font bug. I’m into them. I think it’s so great that I can re-color icons with a line of CSS. I like how they zoom, and how they have broader support than SVGs.

But they’re not SVGs. They’re not images. We shouldn’t pretend they were, or that they could ever be as accessible as images are.

Theoretically an icon from a font could be inserted in a semi-accessible way by outputting the actual glyph in the code to ensure copy/paste-ability. You’d also have to make sure to only use an icon that already existed in the unicode-table so screen-readers could make sense of them, thus severely limiting your options as a designer. Need a hamburger menu icon? Sorry, doesn’t exist in the unicode table. Pretty much all the benefits of using an icon font would be out the window at this point.

Rewind for a bit. Take a deep breath and think. Why are you using an icon font in the first place? Easy HiDPI and CSS colorability? Easy to show at multiple sizes? Fair enough.

Now pretend icon fonts didn’t exist, what would you do instead? Use a PNG or GIF as a CSS background, right? You’d treat the graphics as presentational elements. Visual aids. You’d keep it separate from your markup. You’d be able to reskin your whole site with a single stylesheet. You’d keep the markup as simple and semantic as that of the CSS Zen Garden. Hopefully you’d be a good person and worry about accessability where it mattered most: in the structure of your markup.

You can still use icon-fonts and have sensible markup while keeping the presentation separate. But doing so means you can’t rely on those bundled CSS helper classes. You have to do it manually; put in the work. Don’t treat icon-fonts like images. Pretend they’re sprites and keep them in your stylesheet. You’ll thank me.

CSS box-sizing; File under "really helpful"

When it comes to layouts, proper widths define whether or not you’ll get a headache. Especially when sizing input fields or textareas, setting the proper width is a challenge. This is due to the CSS box model, which calculates margins, paddings and borders outside of the box width.

A behavior which you can fortunately change:

box-sizing: border-box;

This changes your divs and block elements to calculate paddings and borders inside the specified width.

How to Target IE6, IE7, and IE8 Uniquely with 4 Characters [CSS Hacks]

Some interesting new CSS hacks:

body {
	color: red; /* all browsers, of course */
	color : green9; /* IE8 + IE9 and below */
	*color : yellow; /* IE7 and below */
	_color : orange; /* IE6 */

Sure, specific CSS should be served using conditional comments, but every so often, a good ol’ CSS hack is just so useful.

[Update]: The IE8 hack no longer works. Here’s a working one courtesy of Paul Irish:

@media screen {
	body {
		color: green; /* IE8 */
@media screen {
	body {
		color: green; /* IE8 and IE9 */

Gmails New CSS Buttons

This morning. Or perhaps yesterday. Well this week. Maybe. Google updated the buttons in Gmail. Where they used to be CSS and images, they are now pure CSS3 using border-radius and linear-gradient. Here’s what they look like now, and here’s what they used to look like.

This is interesting for two reasons. On the one hand, this leaves Internet Explorer users with a “gracefully degrading” less aesthetic solution, since IE support for CSS3 is a joke. On the other hand, it’s interesting because WebKit (Google Chrome and Safari) has a different CSS gradient syntax than that of Firefox, which incidentally also means that the buttons look different in Firefox. Fortunately, WebKit is soon to adopt Firefox’ superior CSS gradient syntax. Fast times at Google campus.

Forcing Scrollbars, 2010 Edition

One of the challenges in webdesign is preventing the slight jog that happens when you — in a centered HTML design — when you go from a page that needs a scrollbar, to one that doesn’t. Think about it — you go from the short contact page to the blog, and everything is offset to the left in the process, because the scrollbar takes up 18px. The solution, so far, has been to force the scrollbars by faking extra page height:

html { height: 100%; margin-bottom: 1px; }

Which has, for the most part, worked, even if it felt somewhat unnatural to scroll a page that doesn’t need scrolling. Fortunately, there’s a new method in town, which relies on CSS3:

html { overflow-y: scroll; }

This forces the scroll-pane even when not needed. The beauty of it is, it doesn’t add the actual scroll-bar until it’s actually needed. This works in Internet Explorer, Safari 3+, Firefox 3+, Opera and Chrome.

Special thanks Alexander Graf and also M. Slater who has a demo available.