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:
<blockquote>
<p>It is the unofficial force—the Baker Street irregulars.</p>
<p>— <cite>Sherlock Holmes, Sign of Four</cite></p>
</blockquote>Since we’re all HTML5 all the time these days, there are a couple problems with this:
- We were using the
citetag as a style hook to distinguish the quote from the attribution, but this no longer holds up as the specification forcitenow specifies that people are not legitimate subjects for a citation — only “works” can be cited (books, articles, etc). - That having been said, the citation doesn’t belong inside the
blockquoteanyway; according to the specification, the only content that can live inside ablockquoteis 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>
</figure>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.
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?
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!@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.
@pat — we did, and I was leaning that direction. But in the linked discussion the HTML5 Doctor himself showed up to tell us that the spec had evolved past that recommendation.
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:
Sorry, my HTML doesn’t parse that well, but you get the gist of where the blockquote tags go 😉
@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.
I’m sorry, the attribution should not be in the blockquote of course. Why can’t I edit my posts? 😀
Sorry, just delete my posts, I’m not thinking straight. The markup is fine.
@renier — comment editing is in the works.
Thanks Tim and Grant. I guess I have some more reading ahead of me. Thanks for the correction!
Loved reading the back-and-forth on the gist discussion of proper markup. Thanks for sharing!
The final HTML5 example is missing a closing cite tag.
Nice. We’ve done the same research in the last months and came up with the same conclusion: figure>blockquote+figcaption for Quotes — now we use almost the same code as you have here on all the in-article quotes on http://www.macprime.ch
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?
(I just fixed what looked like an unclosed cite tag in the snippet — I neglected to escape the closing cite tag.)
@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.
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.
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.
https://gist.github.com/4489740#comment-761683
P.S. Would be great to preview comments before submitting them and know what html we can use in the comments. Markdown? HTML?
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? http://24ways.org/2009/incite-a-riot/
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?
Oops. Only now I read https://gist.github.com/4345988 (I thought the other gist with the code examples was the _only_ one linked). Many good points there (already mentioning Aria @describedby etc.).
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.