Drop caps & design systems

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.

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.


Detail of a page from the Gutenberg Bible, showing a large illustrated letter “E” styled next to the main text

“Drop caps” are a very old design technique—one we’ve used for hundreds and hundreds of years.
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.

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:


Three pictures showing the same paragraph of text in Firefox, Chrome, and Safari. The first letter of the paragraph is visually much larger and offset to the left. In Firefox, the letter is aligned correctly; in Chrome and Safari, the letter is too low

The same drop cap, in three different browsers: Firefox, Chrome, and Safari. Can you spot the issue?

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.


Three pictures showing the same paragraph of text in Firefox, Chrome, and Safari. A red border has been added to the first letter, showing that in Chrome and Safari, the initial letter M is lower

Let’s add some borders to these drop caps, which highlights the alignment issue a bit better.

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:

Matthew watched the storm, so…

… 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?

Matthew watched the storm…

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

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?


Three pictures showing the same paragraph of text in Firefox, Chrome, and Safari. A red border has been added to the first letter, and the heights of all three letters are finally consistent

Simply by changing our approach to using a little extra HTML, we now have consistently-sized drop caps.

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.


In a typeface, an em square is the entire height of a glyph. There is space reserved at the top and bottom of the square for a glyph’s ascenders or descenders

Understanding the nature of the “em square” can help us better align our drop caps.

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.


Two images of text. The first is labeled “Before”, and shows a misaligned drop cap. The second image is labeled “after”, and shows a perfectly-aligned drop cap

With a little extra code, we’ve fixed our drop caps’ visual alignment issues!

And with that, our job was finally 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:

watched the storm, so…

—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.

watched the storm, so…

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.

aria-labelledby="word--first" role="text"> watched the storm, so…

The second part is the aria-labelledby attribute, attached to this bit of HTML that surrounds the whole block. That attribute points to the “real” first word, which is hidden with that imaginatively-named hidden class. But thanks to aria-labelledby, 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.

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 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.


Changes to custom styles are communicated to users in a Slack chat room. Users can also use a spreadsheet to review potential style changes, and they can access a list of approved styles

The result of our research led to a process that uses a Slack room to communicate upcoming changes, accompanied by reports and code snippets to help users assess and plan style modifications.

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.


Excerpts of articles taken from four visually distinct websites. Each article begins with a “drop cap” (a large, visually prominent letter)

A sampling of drop caps from four Chorus-powered websites: Polygon, The Ringer, Vox.com, and Eater.

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

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.

Source link

Write a Comment

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.