# Collateral Damage


- Date: 24-Sept-2015
- Author: Prateek Rungta
- Tags: Progressive Enhancement, User Experience, Opinion, Performance, Typography
- URL: https://miranj.in/blog/2015/collateral-damage


With the release of iOS 9 and its support for content blocking APIs, there has been an [explosion of ad blockers][blockers] that are proving only too popular with users. This has kicked off the long overdue debate about the [malpractices of contemporary online advertisers][idlewords], and the [ethics of blocking said advertising][ethics]. There have been numerous interesting perspectives on this issue, and rather than recounting them here, I urge you to read them for yourself:

- [What Happens Next Will Amaze You][idlewords] *by Maciej Cegłowski*
- [Ad blocking](http://sethgodin.typepad.com/seths_blog/2015/09/ad-blocking.html) *by Seth Godin*
- [The ethics of modern web ad-blocking][ethics] *by Marco Arment*
- [Ad Blocking and the Future of the Web](http://www.zeldman.com/2015/09/18/ad-blocking-and-the-future-of-the-web/) *by Jeffery Zeldman*

[idlewords]: http://idlewords.com/talks/what_happens_next_will_amaze_you.htm
[ethics]: http://www.marco.org/2015/08/11/ad-blocking-ethics

Instead, I wish to draw your attention to web fonts. A lot (if not most) of the ad blocker apps also support blocking of web fonts. Some restrict themselves to blocking font hosting services such as [Typekit][] and [Google Fonts][gf], while others block all web fonts, self-hosted or otherwise. Designers, as some might have expected, have something to say about that.

[typekit]: http://typekit.com
[gf]: https://www.google.com/fonts

<blockquote class="twitter-tweet" lang="en-gb">
  <p lang="en" dir="ltr">
    The debate over content blockers is an important one for our industry. I just wish web fonts weren&#39;t caught up in it.
  </p>
  <p>
    &mdash; Jeffrey Veen (@veen)
    <small>
    <a href="https://twitter.com/veen/status/644999689763352577">September 18, 2015</a>
    </small>
  </p>
</blockquote>

<blockquote class="twitter-tweet" data-conversation="none" lang="en-gb">
  <p lang="en" dir="ltr">
    As a designer “Block Webfonts” makes me… happy sad.
  </p>
  <p>
    &mdash; iA Inc. (@iA)
    <small>
    <a href="https://twitter.com/iA/status/644858595159449600">September 18, 2015</a>
    </small>
  </p>
</blockquote>

<blockquote class="twitter-tweet" data-conversation="none" lang="en-gb">
  <p lang="en" dir="ltr">
    <a href="https://twitter.com/iA">@iA</a> Webfonts (woff) actually are lean in data: 15–30kb/font. Stupid to block them because that decreases reading experience.
  </p>
  <p>
    &mdash; Linotype (@Linotype_com)
    <small>
    <a href="https://twitter.com/Linotype_com/status/644859781493211136">September 18, 2015</a>
    </small>
  </p>
</blockquote>

So designers are not happy. But if you’re a user, chances are, [you’re][u4] [quite][u3] [relieved][u2] (or even [ecstatic][u1]) at the ability to block web fonts and experience a faster web. And web designers and front-end engineers have no one but themselves to blame for this.

[u1]: https://twitter.com/PeterssonJesper/status/644413985748615168
[u2]: https://twitter.com/JakeMoore/status/644293445528350720
[u3]: https://twitter.com/zacwest/status/644246065139478528
[u4]: https://twitter.com/sungo/status/644952897109798912

### How did we get here?

The web is primarily textual. [Typography][], thus, becomes an [essential component of web design][95 pc]. CSS features such as `@font-face` allow us web designers to enhance the typographic quality of our designs by giving us the freedom to use any font at our disposal. This is a good thing. No two ways about that (and more of the same, please).

But somewhere along the way, we forgot (or chose to ignore) that a user's experience of the web is made up of a wide range of factors, of which fonts are an important but not all encompassing part. Smooth performance and fast access to content are just as (if not more) important factors.


#### FOIT

Far too many websites, far too often started resulting in situations such as this:

[typography]: http://practicaltypography.com/what-is-typography.html
[95 pc]: https://ia.net/know-how/the-web-is-all-about-typography-period

<p class="bleed">
  <img
  alt="quartz home page with the base design rendered but no fonts and no readable text or headlines" src="https://miranj.in/media/opinion/collateral-damage/quartz-font-loading.png">
</p>

The page has been rendered. The content is available, but it isn't accessible to be read until the web fonts finish downloading. This behaviour is called *Flash of Invisible Text*, or FOIT.

FOIT is bad if you're on a low-speed connection, because the text might be the last thing that becomes accessible on the page. FOIT is worse if you experience bad latency or lose network connection altogether and the fonts fail to download, leaving you with blank spaces where the text might’ve been.

#### FOUT

There is an alternate method, which starts off with making the text available on first render using local fallback fonts from the user's system and applying the web fonts after -- and if -- they finish downloading. This behaviour is called *Flash of Unstyled Text*, or FOUT.

Default browser handling of `@font-face` embeds has changed over the last few years, but web designers have more or less had control over going the FOIT or FOUT route right since web fonts gained popularity [^1]. Sadly, most websites chose invisible (FOIT) over accessible. They chose to hide the text until their preferred typefaces would finish downloading, resulting in longer wait times for the user. They treated web fonts not as an enhancement but as a requirement, seceding the functional high ground for higher quality typography.

<blockquote class="twitter-tweet" lang="en-gb">
  <p lang="en" dir="ltr">
    Dear front-end developers,&#10;&#10;I’m on a train. I won’t mind a sudden switch of fonts, but I sure mind this endless wait for the fonts to load.
  </p>
  <p>
    &mdash; Souvik Das Gupta (@souvikdg)
    <small>
    <a href="https://twitter.com/souvikdg/status/549454212082302977">December 29, 2014</a>
    </small>
  </p>
</blockquote>

It shouldn't come as a surprise that people want to be able to read the news report in _Georgia_ or _Roboto_, or carry on with their shopping in _Arial_ rather than [stare at a blank screen][still words] for the rest of their train ride. Hence their joy and support for web font blockers.

[still words]: https://signalvnoise.com/posts/3404-reminder-design-is-still-about-words

---

The sense of dismay amongst designers hints at a deeper negligence. Why are designers disappointed on hearing that a certain feature might not be available to a certain subset of the people visiting their site? Is that not true for pretty much everything but the vanilla HTML we write? Or do we only concern ourselves for users with the latest software releases running on the most powerful hardware devices connected via the fastest networks?

<blockquote class="twitter-tweet" lang="en-gb">
  <p lang="en" dir="ltr">
    With iOS 9 now able to block web fonts, it may be time for my amazing new paradigm-shifting dev methodology I call &quot;Progressive Enhancement&quot;
  </p>
  <p>
    &mdash; Bruce Lawson (@brucel)
    <small>
    <a href="https://twitter.com/brucel/status/644445352192540672">September 17, 2015</a>
    </small>
  </p>
</blockquote>

Web designers should know better. Websites should not come with _minimum software requirements_. Websites [should not feel doomed][fontstack] if one, or two (or three, or more) of the enhancements are unavailable [in a certain browser][ios9]. Granted, typography is a vital component of web design given the percentage of text on our pages, but it should not come at the cost of the ability to read. The dependence on web fonts for delivering great reading experiences further highlights our [mis-treatment of those web users that fall outside our local map][map territory].

[fontstack]: http://artequalswork.com/posts/better-css-font-stacks/
[ios9]: https://twitter.com/TrentWalton/status/644556750008422400

Users are pushing back against the abusive practises of the online advertising industry. Some might feel that in between this fight, web font blocking is the unfortunate collateral damage, but I disagree. I feel the culprits are the websites that chose FOIT over progressive enhacement. In the process of users [reclaiming faster access to content][frustrated], even the FOUT style web fonts have been blocked. That is the real collateral damage.

[frustrated]: https://twitter.com/tobytripp/status/644885057564487681

[^1]: [Bram Stein](https://twitter.com/bram_stein) has a great slide deck on [the current state of web font loading and performance](https://speakerdeck.com/bramstein/web-fonts-performance). Bram is also the author of the [FontFaceObserver script](https://github.com/bramstein/fontfaceobserver), which is our weapon of choice to implement a [progressive font loading strategy](https://gist.github.com/rungta/fa39058f1d15d6d4ea95), based on [the excellent work done by Filament Group](http://www.filamentgroup.com/lab/font-events.html). Recommended reading for web designers and front-end engineers.

*[FOUT]: Flash of Unstyled Text
*[FOIT]: Flash of Invisible Text
*[CSS]: Cascading Style Sheets
*[HTML]: Hyper Text Markup Language

[map territory]: https://vimeo.com/63525054 "Ethan Marcotte - The Map Is Not The Territory"
[blockers]: http://www.loopinsight.com/2015/09/16/a-list-of-content-blockers-for-ios-9/

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>