Let’s get this out of the way up front: this is the most you’re probably ever going to read about drop caps.

—what are “drop caps,” you ask? Well.

A brief history of drop caps

Drop caps are a specific kind of initial letter, large letters that appear at the beginning of a block of text. Occasionally referred to as “drop initials” or “sunken initials,” drop caps might be intricately illustrated, or just set slightly larger than the rest of the text, but they’re always “dropped” over the side, with rest of the text flowing around them.

Photo by JMWK, on Flickr.

A drop cap is often used to signify that the reader’s moved into a significant new section, or that a new chapter’s begun. Drop caps are also incredibly old, appearing throughout the history of the printed page: in illuminated monastic manuscripts, in renaissance cookbooks, and even in more contemporary texts.

On the web, we use drop caps for similar reasons: both as a design accent, and as a visual cue to draw the reader’s eye toward an important piece of text. In the web’s early days, designers like Jason Santa Maria and Jessica Hische helped popularize the technique; more recently, Jason Pamental and Jen Simmons have showed us more modern techniques for bringing drop caps to the web.

The fault in our drop caps

Shortly after I started working at Vox Product, I was assigned a bug report regarding the drop caps in our websites. Here’s a version of the screenshots that were attached to that bug report, each showing the same text in a different browser:

Now, it’s possible you’ve already spotted the bug. But let me put borders around the letters; that should really highlight what’s happening.

Here’s the problem in a nutshell—and it’s technically two problems. First and foremost, the alignment of these drop caps isn’t consistent across these three browsers. In Firefox, we have a nice, tight box around the shape of our letter, which is the effect we’d really like to achieve. But unfortunately, Firefox is the outlier; while Chrome and Safari are sized consistently, their boxes are much, much taller than we’d like. And that’s the second bug.

So what’s happening here? Let’s peek at the code we were using to generate our drop caps:

<p>
  Matthew watched the storm, so…
</p>

…

p:first-letter {
  font-family: “Playfair Display”, serif;
  font-size: 5.5rem;
  float: left;
  line-height: 1;
  margin-right: 0.05em;
}

The colors and fonts will vary across each of our Chorus-powered sites, but the mechanics are the same. In our CSS, we used the :first-letter pseudo-element to select, well, the first letter of certain paragraphs, and then we’d style it—usually by applying a distinctive typeface, making it visually prominent, and floating it to the left.

As it happens, this is a very common pattern for creating drop caps on the web. But what happens if we change our approach a little bit?

<p>
  <span class="dropcap">M</span>atthew watched the storm…
</p>

…

.dropcap {
  font-family: "Playfair Display", serif;
  font-size: 5.5rem;
  float: left;
  line-height: 1;
  margin-right: 0.05em;
}
</code></pre>

Here, we’ve added a little more HTML to our paragraph—specifically, a span element that surrounds the letter (or letters) we’d like to style—and then we’re styling that new markup.

For the coders out there who feel this is a little more ungainly, I’ll agree with you! But let’s put all that aside for a second: what’s our design doing now?

Hey, would you look at that! We now have consistent heights across all three browsers, all by introducing that little bit of markup.

However, we still have to deal with our second issue: while the box heights are consistent, they’re all consistently too tall. We’ve got some ungainly heights above and below each letter. Can we close up those spaces, and make the drop cap a little more attractive?

It wasn’t until I found a blog post by Vincent De Oliveira that I figured out how to adjust this issue. Vincent showed me that every glyph in a font—every letter, every number, every punctuation mark—is drawn on something called an “em square,” a box that acts as a coordinate plane upon which each character’s drawn. And this is the cause of the second issue: the em square defines the space that’s being reserved for our drop caps, and that’s what’s making them appear a little too tall.

Each em square has space reserved at the top and the bottom for a letter’s ascenders and descenders. Here’s the thing, though: we don’t actually need that space for our drop caps. In fact, we want to remove those spaces from the bounding box, leaving just enough room for our letters. And since we’ve added that extra bit of markup around our drop cap, we can do exactly that with some extra CSS.

.dropcap:before,
.dropcap:after {
  content: "";
  display: block;
}
.dropcap:before {
  margin-bottom: -0.175em;
}
.dropcap:after {
  margin-top: -0.05em;
}

This code looks a little involved, I know. (In the very near future, tools like :initial-letter will make this work much easier, and much, much more precise.) But we’re doing just two things in this CSS. First, we’re selecting the empty space :before and :after the content inside our drop cap. Once we’ve done that, we’re using negative margins to pull the letter closer to the outer edges of the box. This effectively erases the extra spaces, and finally gives us what we wanted: consistently sized and positioned drop caps, in any browser you care to use.

And with that, our job was finally finished.

Our job was not finished

Here’s the thing: we’ve finished the visual treatment of our drop caps. But on the web, we’re not just serving sighted users. We’re designing for users who might not browse the web like I do—who might not see the web like I do. So what does this design sound like?

This is a recording of how our drop caps sound in VoiceOver on a Mac, which says “M! atthew watched the storm, so beautiful yet terrific.” Why is the word “Matthew” broken up into two separate syllables? As it happens, that’s because of the markup we introduced to fix our drop caps: some assistive technology—like the VoiceOver screen reader on Macs—notices the markup around our initial letter, and interprets it as a separate word. That’s why “M!” is read aloud, followed by the rest of the word: “atthew.”

Rather than focusing simply on the visual presentation of our drop caps, we need to revisit our approach. More specifically, the HTML for our drop caps should better describe our content, so that anyone can read it, regardless of their access needs.

After a bit of work, we landed on something like this:

<p>
  <span role="text">
    <span aria-hidden="true">
      <span class="dropcap">M</span>atthew
    </span>
    <span class="visually-hidden">Matthew</span>
  </span>
 watched the storm, so…
</p>

—okay, okay. I’ll be the first to admit this looks like a lot of code. But amidst all the angle brackets and equals signs, there are only two things happening here.

<p>
  <span role="text">
    <span aria-hidden="true">
      <span class="dropcap">M</span>atthew
    </span>
    <span class="visually-hidden">Matthew</span>
  </span>
 watched the storm, so…
</p>

First, we’re treating the drop cap as a purely visual element. We’re surrounding the visual drop cap with the aria-hidden attribute, effectively hiding it from assistive technology. This prevents the “split” word from being read aloud in screen readers.

<p>
  <span role="text">
    <span aria-hidden="true">
      <span class="dropcap">M</span>atthew
    </span>
    <span class="visually-hidden">Matthew</span>
  </span>
 watched the storm, so…
</p>

The second part is the visually-hidden class, which we’ve applied to the “real” first word. That allows us to use some styles that visually hide the text in a more inclusive fashion. As a result, this word acts as a label for this entire bit of markup. So VoiceOver, and other assistive tech, will simply read “Matthew”:

With some richer markup in place, we now have a finished design for our drop caps—one that looks as good as it sounds. Once we tested the fix, I deployed it to all of our websites and, by extension, all of our readers.

Ninety minutes later, I reverted the fix, taking it off all of our websites.

Why we dropped our drop caps

For years, Chorus has had a feature that allows our editorial users to add custom styles to their stories. And over time, they embraced the feature, using the custom styles tool to enhance their visual storytelling. They could also use custom styles to address small bugs, or to make visual improvements to the underlying platform. Some editorial teams went so far as to document their most common style snippets, ensuring they could be shared as widely as possible.

You can probably guess where this is going. The presence of custom styles meant the “new” drop caps we’d built were colliding with custom styles that had been implemented on a large number of articles published on Chorus, causing countless tiny visual bugs. What’s more, the custom styles created by our editorial teams depended on the presence of specific markup on those articles. If we were to change the underlying markup on our pages, we would have broken their custom styling in unpredictable ways—including, say, by changing the way our drop caps were structured.

This meant that we were facing down a fairly thorny problem. As the team responsible for designing and maintaining Chorus, we needed to be able to ship improvements to our platform. But we needed to be able to do so without breaking the stories published on that platform, thousands of which had custom styles.

What’s a product team to do?

When the real work started

When I’m asked to describe design systems work, I say the word that springs immediately to mind is mapmaking. As designers like Matthew Ström and Alla Kholmatova have argued, every website has a design system underneath it. Take yours, for example: your website’s interface is built from a library of components, each shaped by a series of design decisions and business needs. Your design system may not be explicit—maybe you don’t have a polished pattern library, or a set of well-defined design principles, or maybe your documentation’s not as robust as you’d like it to be—but it’s still a system. And in order to improve that system, you have to research it before you can begin to gradually, slowly improve it.

So we began our research. We generated a report of every article that had been published with custom styles, and looked at trends to see how those styles evolved over time. We also met with several editorial teams, and listened to how they talked about custom styles internally: what documentation had they written? What rules did they use most frequently? Were their styles used to address bugs, to make design changes, or both?

What we learned was that for most people we spoke with, their use of the custom styles feature had gotten more consistent over time, and more conservative. In the early days of the feature, there was a healthy amount of experimentation, with styles used to dramatically reshape the visual presentation of stories. But as the years passed, that experimentation gave way to stability. Most teams relied on a handful of styles they’d copy into new stories to update colors to match some key art, to improve the legibility on a specific kind of heading, or, yes, to fix the alignment of their drop caps.

With this information at hand, we proposed this workflow:

• We documented the most commonly used styles, and created list of “supported” styles that we committed to monitoring. We also created a report of all stories that contained custom styles, which could be filtered by individual networks.
• Whenever we planned a change to the underlying code on our articles, we would update that list of sanctioned styles, ensuring there was always a canonical list of styles for them to reference.
• Simultaneously, we would inform users of any changes in advance, giving them time to evaluate whether it was worth updating old stories that might have used the old style snippets.
• We also added a warning to the custom styles tool, to clearly note that custom styles may break at any time.

Once our editorial users approved this workflow, we put it into practice. We announced a planned change to our drop caps, gave them time to coordinate, and then deployed the change to our websites.

And then, at long last, our new drop caps were finally live.

The work continues, as it always does

Since rolling out our new and improved drop caps, we’ve continued to iterate on them. (Including fixing a number of bugs that I, a professional web designer, introduced.) We’ve also discussed potential changes to the custom styles feature, in order to make it sustainable. But for my money, the real benefit of the work wasn’t the drop caps themselves, but the process that emerged from it. We can now make changes to our platform more confidently, thanks to clearer lines of communication between our Product team and our editorial users.

While the drop caps project was underway, I found myself thinking of a Robin Rendle post I like quite a bit, in which he talks about always striving to make a system just 1% better:

You might argue that all these 1% changes are distractions from much larger projects that might have an enormous impact.

My argument would be that those massive, revolutionary projects will never happen. Instead it’s best to slowly move towards where we want to, step by step, so that we gather momentum over time.

This experience was a reminder for me that most design systems work is rarely flashy or sudden. Rather, it involves communication, iteration, and slow, careful research. If you can do that mapmaking, and if you’ve got a good team to help you find your way, your design system will be in excellent shape. And so will your drop caps.