The A List Apart Blog Presents:

More Thoughts About Blockquotes than are Strictly Required

Article Continues Below

As I started building the HTML templates for ALA v5, I tried to be as thoughtful as I could about the patterns I chose, especially for markup that was going to become part of the content of the magazine. Something I thought important to nail down was a useful and meaningful pattern for marking up blockquotes.

In the previous ALA, we used a long-standing pattern that’s been a convention since early in the the XHTML days:

     <p>It is the unofficial force—the Baker Street irregulars.</p>
     <p>— <cite>Sherlock Holmes, Sign of Four</cite></p>

Since we’re all HTML5 all the time these days, there are a couple problems with this:

  1. We were using the cite tag as a style hook to distinguish the quote from the attribution, but this no longer holds up as the specification for cite now specifies that people are not legitimate subjects for a citation — only “works” can be cited (books, articles, etc).
  2. That having been said, the citation doesn’t belong inside the blockquote anyway; according to the specification, the only content that can live inside a blockquote is the text being quoted.

I’d also like to get rid of the emdash — it’s pure ornamentation, and I’d rather it not be in my content.

Ok, no problem. Here’s what we could do instead:

<blockquote>It is the unofficial force—the Baker Street irregulars.</blockquote>
<p class="quote-citation">Sherlock Holmes, <cite>Sign of Four</cite></p>

This is valid HTML5, and the quote-citation class gives me a hook to insert an emdash (or whatever we like) via CSS:

p.quote-citation::before {
     content: "— ";

But: We have a semantic problem. There’s nothing meaningful, other than proximity, to tell us (or machines) that the p tag that follows the blockquote should be considered part of the same content (the class isn’t sufficient, according to the spec, and without the quote, the citation becomes a non-sequitur). So, we went looking for a semantic element to wrap this pattern in, and for a few reasons, we arrived at figure:

<figure class="quote">
     <blockquote>It is the unofficial force—the Baker Street irregulars.</blockquote>
     <figcaption>Sherlock Holmes, <cite>Sign of Four</cite></figcaption>

Not only does the spec for figure perfectly align with our needs, it even comes with the convenient figcaption element; a perfect container for our citation. I’ve given the figure a class because there are other kinds of figures — images, tables, etc etc. There are other details from the spec that we could have adopted (such as the optional cite attribute for the blockquote), but I wanted to keeps things simple for the folks marking up our articles.

(You can see part of the conversation we had about all this in this gist; it’s often smart — and fun — to take an idea to its fullest extreme before reigning yourself in.)

So, here they are, the official ALA blockquote patterns. A lot of thought for what might be a small detail, but in thinking about these things now we’re doing our best to ensure that our content is future-friendly, and not just our templates.

22 Reader Comments

  1. Two things:

    1) I noticed the updated version (at least in the example) has no paragraphs within the `blockquote`. Under XHTML, `blockquote` could not contain naked text. Has that requirement changed in HTML5?

    2) Did you consider providing `id`s for each `figure` as well, so they could be referenced from the surrounding copy or from other articles and sources?

    On a semi-related note, have you moved to using `figure` for code blocks as well?

  2. I’m curious if you considered using a <footer> tag inside the blockquote, per this article from HTML5 Doctor? It’s what I’ve been using, though I admit I prefer your idea of using CSS to include the em dash. It’s great to see some of the thinking that went into the details of the new design!

  3. @aaron — I’d forgotten that about XHTML — yep, in HTML5 blockquotes no longer require any children elements.

    I considered the IDs, but when deciding on the final pattern, some things fell by the wayside in favor of ease-of-production. It’s something more likely to be addressed on an individual basis as articles are produced.

    Code blocks aren’t in figures, again mainly for simplicity, but also because the figured element is for content that isn’t mission critical to the piece, and code blocks are normally much more integral to an article than images or illustrations are.

  4. Although it’s not ‘forced’ upon you, I’d still opt for using paragraphs inside blockquotes. It’s also used in the examples that W3C gives you, as well as other sources like MDN.

    In case you have more than one paragraph as a quote, you need them anyway 😉

    Wrapping it in a figure is excellent indeed, but the figcaption is not semantically correct. It should be used to describe the figure (which in this case would be both the quote and the source.

    I would opt for:

    It is the unofficial force—the Baker Street irregulars.

    Sherlock Holmes, Sign of Four

    Figure 1: the famous quote everyone knows.
  5. @pat Using footer inside the blockquote isn’t valid, according to an alert on the same page you linked. The blockquote is intended to contain a quote, not meta information about said quote.

    @tim The figure element is one of the nice features of HTML5, since it provides a semantic container for different object types, such as images, tables, videos, and blockquotes. The figcaption is a bonus. I much like the combination over the old generic div technique.

  6. What’s the strategy for supporting the old markup style too? Keep the CSS for both? Go back and update old posts? (manually, or with some script). Serve different CSS depending on age of post?

  7. @chris coyier: There are some styles for supporting legacy CSS, but not many. We did some search-and-replace in the DB for simple patterns (like replacing div.illustration elements with figures) but we really need to go in and edit each article by hand. Over a decade of content, there have been a lot of hands and a lot of variations on approaches to the HTML.

  8. I love this markup pattern. I had recently started using something similar (sans cite and keeping the en dash inline). I’ll be cutting over to try this immediately the next time the opportunity arises.

  9. Putting the blockquote in a figure seemed more like blockbloat to me at first, though I’ve come to appreciate this pattern. Looking at your gist of the different ways you use this pattern on ALA, I’m curious how you guys handle links in your figcaption.

    P.S. Would be great to preview comments before submitting them and know what html we can use in the comments. Markdown? HTML?

  10. I can see the value of `figure` and `figcaption` to link the quote and author together but it just seems a bit of an afterthought or hack (not by you, more so by Hixie et al.)

    I’d rather see a specific _attribute_ for this (`@author`?) — just as we can currently use a `cite` _attribute_ linking to a URL…

    Surely the author should not be placed inside the `blockquote`, so we would need a new element for it. I agree with @adactio that the `cite` element should be a fine candidate, even though the Spec disagrees. Remember the old 24 Ways article?

    If `cite` was fine for marking up the author of a quote the only thing we would need is an attribute linking the two together (something like a `@source` attr. linking to a (block)quote ID?)

    Thanks for giving us some insights in your considerations. Any specific reason you do not use the humble `q` element for inline quotes?

  11. This is interesting. I was struggling with semantically how to deal with the notion of ‘pull quotes’ (to use the print design term). I felt like Blockquote was the way to go but that didn’t help with the source. I actually thing that this patter with the addition of Figure and Figcaption works nicely. As Aaron pointed out it would be a nice addition to add IDs – that would be an interesting thing to add perhaps via JS in the WYSIWYG if you are writing in a CMS so that it would end up in markup but be generated automatically.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA