Why you shouldn’t use webfonts instead of images

Warning: principled rant against sloppy design and bad coding about to start; kids these days! Get off my lawn!

There’s a terrible disease affecting modern web developers – Twitter.com has just fallen ill with it, and it could be a long time before they cure themselves.

Deleting all images, and replacing them with the dreaded “web font”.

It’s the wrong solution for the problem, it doesn’t do what you think it does, and it pisses all over some of the Web’s core principles. If you’re a web developer, and you respect your craft, you shouldn’t even consider this, not for one moment. Here, for instance, is how Twitter currently looks for me – ugly, and very hard to use!

Screen Shot 2014-04-15 at 10.18.17

GitHub was another recent victim of this disease. They’re still in recovery, but they at least made their site “slightly usable” by adding tooltips:

Screen Shot 2014-04-15 at 10.30.18

What’s going on?

The problem

Core Web principle:

Information is everything; presentation is optional. It’s acceptable to forego presentation, so long as everyone can access the information.

Effect: When you load a webpage, your browser requests every image separately. This is a long way short of the “most optimal” code implementation.

Is this a big problem? For most of us … Not really. The system works, it’s flexible, it’s powerful – it’s a little inefficient, but for the corporations that care there are plenty of hacks and optimizations they can deploy.

The other problem

Most artists should be creating Vector images most of the time, but the software vendors who made the editing tools for Vectors … all died out around 15 years ago. Back then, the advantages of Vectors were small, because most screens were low res.

We still haven’t recovered. There are many standards for bitmap image files, and two very popular ones – PNG, JPG. There are many standards for vector image files, but no popular ones.

Effect: web developers end up looking to Web Fonts as a de facto “vector image” standard.

SVG, or not to SVG?

There is an official Web/HTML approved vector standard – SVG – in wide use, with strong support in all current browsers.

Does it work? Let’s see (http://caniuse.com/svg) …

Screen Shot 2014-04-15 at 10.45.46
Screen Shot 2014-04-15 at 10.45.33

… but many software companies ignore it. For instance, Apple allows programmers to use both PNG and JPG (why?) in core iOS, but not SVG (despite having a full SVG parser built-in to their web browser). Many programmers I speak to believe that SVG isn’t supported at all – FUD wins again.

The other, other problem

A core principle of the Web is that information is accurately described (the M in HTML). A recent trend in web development is “progressive enhancement”.

def. “Progressive Enhancement HTML”: a webpage written the way you were supposed to write it, instead of being hacked-together by unskilled monkeys

HTML has always been “progressive” – this was a core principle 20 years ago. But HTML was so easy to use and abuse that many of us (most of us? nearly all of us?) have been writing poor HTML most of that time. Shame on us (shame on me, certainly – been there, done that :( ).

But … the key point here is: Progressive Enhancement isn’t an “optional extra”, it is the Web. If you fight PE, you’re fighting the entire web infrastructure – and we know how that war will end.

…whatever. What about Web fonts?

So, when you remove an “image” and put a “web font letter” there instead, and change that letter so that the font contains an image you wanted …

…your HTML is now a lie.

Maybe you’re the kind of web developer who scorns blind people (and partially blind), who ignores the Internationalization features of software. You laugh in the face of Accessibility Standards, so you can reduce development time.

But HTML doesn’t make these things optional. They are so core to HTML that they are “always on”, even if you personally never use (need) them. One of the beautiful features of HTML is that if you do nothing, most of the Accessibility is automatically done for you.

With HTML, you have to go out of your way to prevent Accessibility. For instance: replacing images with magic-letters from a magic font.

You’re not blind; why does the Web Font fail?

The thing about custom Web Fonts is … the user can disable them.

Again, this is fundamental to the web. Partly for the Accessibility issue (who are you to decide which users require Accessibility? No. It’s for the user to decide).

But also to support the web principles of openness, and user-control (not corporation-control). My machine, my browser, my choice.

Just as you cannot prevent users from hitting the “View -> Zoom” menu option and making your web page take more or fewer pixels on their screen (I’ve worked with web designers – mostly ex-print designers – who HATED this, and felt it was a feature that should be banned) … you cannot force a crappy font on the user.

Information is everything; presentation is optional. It’s acceptable to forego presentation, so long as everyone can access the information.

In my case: I have a MacBook Air. While wonderful in many ways, they have tiny (11″), non-retina screens, and they’re laptops – so the screen is often further away than I’d like. When WebFonts came to CSS, a lot of the websites I use (art sites, design agencies) started using “beautiful but TINY” fonts that were unreadable. Game Studios still do this today, sadly – lots of hard-to-read but “edgy!” fonts and bad colour choices.

Sometimes, the only way I can do my day to day work is to disable the crappy 3rd party fonts.

Another solution?

SVG says “Hi!”. Think about it.

9 thoughts on “Why you shouldn’t use webfonts instead of images

  1. nobody

    I share your hatred for WF. And still, I had to re-enable them because while a lot of pages fail to use them properly (tiny, huge, or completely unreadable like http://zeroturnaround.com/blog/geekout-2014-announced-zeroturnaround-hosts-java-gurus-in-estonia/) I can tolerate this or manually disable them for this particular tab (remove appropriate styles from DOM), but some of the pages are completely unusable without WF enabled, like GitHub.

    And it’s funny what Twitter did, because their Bootstrap comes with glyphs in several formats to fallback in case of anything goes wrong.

  2. adam Post author

    LOL @ zeroturnaround.com – I had to set to 175% zoom before I could read the text properly.

    …or, with my WF-disabled browser, it JustWorked ™.

  3. lostdj

    It’s not about size for me, but some idiotic hinting/AA method which makes text to _blend_ with white background. Or maybe it is the size, or that is this font was not made with Windows font smoothing algorithms (ClearType?) in mind… It probably won’t look the same to you as to me, but http://snag.gy/eYpOQ.jpg

  4. adam Post author

    Yep, similar – but if I increase the font size enough, it gets to the point where the shapes become nicely defined + sharp and readable.

  5. Andrew Crystall

    “if you do nothing, most of the Accessibility is automatically done for you.”

    Sorry, I don’t believe that’s true at all – HTML 5 differs from XML and even SGML, and the design is a moving-target. It makes for an absolute nightmare for most screen readers – you can’t ignore the CSS and find your content easily (or at all) on many big websites these days, sadly.

    Basically, the old h1-6 headings structure is…important for accessibility. HTML5’s layout of web page elements is…more or less a judgement call, and things like make it near-impossible to do right in a screen reader. (What’s it an aside TO?)

    (It’s interesting to look at the way ePub3 handled this, as they explicitly called this stuff out, it’s one major reason they went with XHTML and push dynamic layout so strongly)

  6. adam

    Yeah, I meant: if you don’t mess around with CSS etc … then it’s done for you.

    If you replace tables with super-dynamic-and-hard-to-debug CSS wizardy … not so much.

  7. daemonburrito

    I love the rest of your blog, and have found your advice valuable, but I feel compelled to speak up about this, both as someone who has worked on the web, and as someone who cares about accessibility.

    All of the libraries that are in wide use (fontcustom, etc) do not replace markup with a random letter, as you seem to think. They all use CSS (usually :before). Without CSS, you would not see the webfont glyph. With a different presentation layer, you would not see them.

    In addition, take a look at github’s markup for the “Issues” glyph:



    Issues


    Beautifully accessible.

    Btw, I do appreciate your opinion on the relative elegance of the web, and that you don’t advocate replacing it with something more “efficient” over the wire, and less robust and flexible, as many systems and game developers are wont to do.

    (And did I read your last comment correctly, as advocating using tables for layout? This contradicts your earlier position on accessibility and a separate presentation layer.)

  8. daemonburrito

    Hmm… your blog seems to have eaten my code. Anyway, take a pick by right-clicking on the icon in Github. Notice the aria-* attributes and how the glyph is drawn with CSS.

  9. adam Post author

    Good points. Interesting too – are we at the point where degradation has to assume CSS exists?

    i.e. if even embedded systems are running basic CSS rendering …

Leave a Reply

Your email address will not be published. Required fields are marked *