Of Blockquotes and Outlines

blockquote.md

( Conversation started here, with @murtaugh and @zeldman. )

Ah man, I got Opinions™ on this. I ususally go with something like:

<aside>
  <h1>Optional Heading</h1>
  <blockquote>
  	<p>It is the unofficial force—the Baker Street irregulars.</p>
	</blockquote>
	<address>Sherlock Holmes</address>
	<cite>Sign of Four</cite>
</aside>

aside provides sectioning context, address flags the author/owner of the current sectioning context, cite to cite a “work”, and blockquote because it’s… a blockquote. I’d probably bolt the emdash onto the front of the address with address:before { content: "—"; }, where it’s not really essential. This is all predicated on the pullquote being considered non-essential to the surrounding content.

The figure route could work too, but technically figure doesn’t provide sectioning context, so there’s two ways you could go with this.

<aside || section>
<figure>
	<blockquote>
		<p>It is the unofficial force—the Baker Street irregulars.</p>
	</blockquote>
	<figcaption>
		<address>Sherlock Holmes</address>
		<cite>Sign of Four</cite>
	</figcaption>
</figure>
</aside || /section>

aside if complementary but inessential to the surrounding content (like a pull-quote directly from the article), section if part to the surrounding content (an external quote directly referenced by the text).

That’s an awful lot of stuff, though, so the other way of doing it with figure:

<figure>
	<blockquote>
		<p>It is the unofficial force—the Baker Street irregulars.</p>
	</blockquote>
	<figcaption>
		<p>Sherlock Holmes</p>
		<p>Sign of Four</p>
	</figcaption>
</figure>

The figcaption flags the content as metadata for the rest of the figure, but you lose the specifics: “author” and “work” just become generic metadata.

I’m partial to the first one from an HTML5 outline standpoint.

I went through this semantic exercise independently just a few days ago and arrived at this markup pattern:

<article>
  <blockquote cite="http://example.com">
    <p>Multi-line quotation.</p>
  </blockquote>
  <footer>
    Author, <cite><a href="http://example.com">Title of work</a></cite>, 2013
  </footer>
</article>

Article seems most appropriate for use as a wrapper... and nesting articles establishes a semantic relationship between the two, insofar as I understand it. Figure does not seem appropriate to me given that the contents can be removed from the flow of a document without affecting its meaning. Usually that isn't the case with quoted passages. Footer is a good match for metadata... and I err on the side of caution in using cite in a way that conforms to the working draft of the HTML5 specification.

I'm a bit new at this but figured that I may as well link my work here since I didn't see this specific pattern mentioned in the discussion above :)

For those following along at home, ALA 5.0 is currently using:

<figure class="quote">
  <blockquote>Je ne suis pas monsieur Lebowski. C’est vous monsieur Lebowski. Moi, je suis le Duc.</blockquote>
  <figcaption><cite>The Big Lebowski, French version</cite></figcaption>
</figure>

from Translation is UX

---

@austingovella — Thank you for your intercession, but I have some minor quibbles (or, please excuse me while I 386 ;)

a blockquote is a quote that is more than four lines long that appears in the body of a work

While this may be your personal definition, there is nothing in the spec that supports either of these assertions. The spec’s first blockquote example is less than a line long. The content model of aside (and most other “block-level” elements) is “Flow content”, which includes blockquote.

you definitely wouldn't use figure

The spec’s third blockquote example is “a blockquote element […] used in conjunction with a figure element and its figcaption to clearly relate a quote to its attribution”.

For semantic purity, a blockquote would appear between two paragraphs

This is not in the spec, and I don’t understand why this would be more “pure” than, say, having a blockquote after a heading or before a list.

You want section

Your section-based example does not include a heading, although the spec states that a section “typically” has one. While this does not preclude using section, it will create an “Untitled section” in the document outline, which is preferrable to avoid for accessibility reasons. The spec notes “A general rule is that the section element is appropriate only if the element's contents would be listed explicitly in the document's outline.” This depends on the content, so while section is one potential option, it’s certainly not the only one, or even necessarily the best one.

Figure is something more akin to a footnote

While I understand this perception, I believe it is incorrect, as evidenced by the spec’s first figure example and third blockquote example.

A pullquote is your words from your work

While I agree that a pullquote quoting the article text should not use blockquote or q, quotations from other sources may be used as pullquotes, and there’s nothing in the spec restricting blockquote from being used for a pullquote.

---

@synapticism — I think article depends on whether you decide a blockquote is “a complete, or self-contained, composition”. My rule of thumb is whether you’d create an RSS feed with this content — I personally wouldn’t for almost all content (a quotes site notwithstanding), but you might. As with section, an article should typically have a header for accessibility purposes, and should be something significant enough to be listed in the document’s outline.

---

@murtaugh, @zeldman, @Wilto & Co. — Congratulations on the relaunch! I’m most impressed by the code and design, you’ve all outdone yourselves (and that’s saying something!) 💖

PS That blockquote example from the top should be lang="fr" 😉

Similar thoughts to Mr. Z.

There are simply too many elements, that's all. Just cut a few.*

Or perhaps I should. I really need to finish this new book. And find a publisher. Hmm...

*Apologies to http://www.imdb.com/title/tt0086879/quotes?item=qt0469793

Seriously, a quotation and a source for it, are just two things, therefore you should be able to mark them up with two elements. Any more and you're working too hard.