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.

It's unbelievable to me that this still perplexes the masterminds at W3C and WHATWG. Footer feels like a hack to me, but my objection might fall under the heading of old dog/new tricks.

What is the problem with an exposed (other than Hixie's random dislike of it for no particular reason)?

<blockquote> 
<p>You know the golden rule, don’t you boy? Those who have the gold make the rules.—<cite><a href="imdb.com hunch-backed old guy in Aladdin</a></cite></p> 
</blockquote>

or, since P tag isn't really needed in this case:

<blockquote> 
You know the golden rule, don’t you boy? Those who have the gold make the rules.—<cite><a href="imdb.com hunch-backed old guy in Aladdin</a></cite> 
</blockquote>

Call me crazy but I never minded what HTML actually provides for:

<blockquote>
<p>Here is a quote</p>
</blockquote>
<p>–Joe Blow</p>

Yeah, lots of people are still using cite for people being quoted. I dunno that we’re likely to see the spec budge on it, but it is sort of the de facto.

I get real “be the change you want to see” about the new rich markup stuff, but speaking practically, going simpler certainly wouldn’t hurt anything. Hell, the whole HTML5 outline algorithm is “at risk” as things stand now; I’m not even sure how that’s gonna shake out in the end.

I just re-read HTML5 Doctor's Aside Revisited and I think Mat's original idea of using aside (instead of section) is better.

<aside>
  <blockquote cite="http://www.the-haystack.com/2012/07/09/great-works-of-fiction-presents-the-mobile-context/">
    <p>Let me make a long story short: just make quality, relevant content with appropriate tasks, and offer all of these to all users.</p>
    </blockquote>
    <address>Stephen Hay</address>
    <cite><a href="http://www.the-haystack.com/2012/07/09/great-works-of-fiction-presents-the-mobile-context/">Great Works of Fiction Presents: The Mobile Context</a></cite>
</aside>

I understand JZ's point about footer feeling like a hack, but checking the spec the latest definition of footer seems to support using it here, something like this:

<aside>
  <blockquote cite="http://www.the-haystack.com/2012/07/09/great-works-of-fiction-presents-the-mobile-context/">
    <p>Let me make a long story short: just make quality, relevant content with appropriate tasks, and offer all of these to all users.</p>
    </blockquote>
    <footer>
        Stephen Hay
        <cite><a href="http://www.the-haystack.com/2012/07/09/great-works-of-fiction-presents-the-mobile-context/">Great Works of Fiction Presents: The Mobile Context</a></cite>
    </footer>
</aside>

Perhaps overkill again, but semantically sound.

To Mat's point, if we were to take a "be the change you want to see" approach, I think this is what I'd recommend:

<blockquote cite="http://www.imdb.com/character/ch0000672/quotes">
    <p>You know the golden rule, don’t you boy? Those who have the gold make the rules.</p>
    <footer><a href="http://www.imdb.com/character/ch0000672/quotes">Crazy hunch-backed old guy in Aladdin</a></footer>
</blockquote>

While I'd rather err on the side of semantics, I'm still not crazy about any of these from a workflow standpoint. That said, I'm sure we can offer a simple tool in the CMS that editors can click to pre-populate the pattern for them.

Yeah; footer flags meta stuff—that’d work. You’d still want to make sure it falls inside of a sectioning element (article, section, aside, marquee, etc.) for the quote, else it represents the meta information for the entire document.

Y’know. Spec-wise.

(also not really marquee)

Ah, good point about the footer needing to be inside a sectioning element. If we wanted to use footer, it'd have to be something like this:

<aside>
    <blockquote cite="http://www.imdb.com/character/ch0000672/quotes">
        <p>You know the golden rule, don’t you boy? Those who have the gold make the rules.</p>
        <footer><a href="http://www.imdb.com/character/ch0000672/quotes">Crazy hunch-backed old guy in Aladdin</a></footer>
    </blockquote>
</aside>

If using aside is desirable, couldn't footer be outside of blockquote to be spec conforming while maintaining relationship between the content of blockquote and attribution within footer?

Yep, that's on the list for sure.

Wait, so now a quotation has to be inside an aside to justify use of footer? Jiminy Cricket. To my mind, this borders on parody. Sorry, I really think it is excessive.

Put the aside inside a section inside an article inside the DD of a definition list. Then throw the whole thing in a bag and drown it like kittens.

<blockbloat>

I don't think it's so bad, actually. Sticking to the spec, our pattern includes:

• aside (removing the content from the main, semantic flow of the article, if appropriate; section if not)
• blockquote
• optional p (only for multi-graph quotes, I'd think)
• optional footer with optional cite

At its simplest it looks like this:

<aside>
    <blockquote>Some intriguing text from the article.</blockquote>
</aside>

At its most complicated it looks like this:

<aside>
    <blockquote cite="http://www.imdb.com/character/ch0000672/quotes">
        <p>You know the golden rule, don’t you boy?</p>
        <p>Those who have the gold make the rules.</p>
    </blockquote>
    <footer><a href="http://www.imdb.com/character/ch0000672/quotes">Crazy hunch-backed old guy in <cite>Aladdin</cite></a></footer>
</aside>

The footer might seem like a bridge too far, but I like it because it's semantically useful. From the spec:

A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.

It's also useful as a hook for styling.

I really should update that article already >< I love the smell of semantics in the morning too, so forgive the intrusion, but here are some related thoughts, most likely too late to be relevant. Y’know, fwiw ^^

While I loved the neatness of footer in blockquote that we’ve been using on HTML5 Doctor, I can understand Hixie’s reasoning — it’s a problem when you want to quote an article etc which has a footer. Because of this we’re (well, I’m) planning to change all blockquotes at HTML5 Doctor to Hixie’s suggested figure pattern at some undetermined point in the future. For example:

<figure>
    <blockquote>
        <p>Let me make a long story short: just make quality, relevant content with appropriate tasks, and offer all of these to all users.</p>
    </blockquote>
    <figcaption><cite><a href="http://www.the-haystack.com/2012/07/09/great-works-of-fiction-presents-the-mobile-context/">Great Works of Fiction Presents: The Mobile Context</a></cite>, Stephen Hay</figcaption>
</figure>

(together with figcaption:before {content: "—";} etc.) Amusingly an important reason for wanting a wrapper element is because our blockquote style visually groups the citation with the quote, so a more Zeldman-friendly

<blockquote>
    <p>Let me make a long story short: just make quality, relevant content with appropriate tasks, and offer all of these to all users.</p>
</blockquote>
<p class="citation"><cite><a href="http://www.the-haystack.com/2012/07/09/great-works-of-fiction-presents-the-mobile-context/">Great Works of Fiction Presents: The Mobile Context</a></cite>, Stephen Hay</p>

wouldn’t cut it for us, although it’s one option Hixie suggests, and would work fine for ALA. We could just use a div wrapper, but figure + figcaption (or a sectioning wrapper plus footer) seems a nice way to make the association between quote and citation explicit. Another alternative would be ARIA’s aria-describedby property:

<blockquote aria-describedby="bq-1">
    <p>Let me make a long story short: just make quality, relevant content with appropriate tasks, and offer all of these to all users.</p>
</blockquote>
<p id="bq-1"><cite><a href="http://www.the-haystack.com/2012/07/09/great-works-of-fiction-presents-the-mobile-context/">Great Works of Fiction Presents: The Mobile Context</a></cite>, Stephen Hay</p>

(with p[id^="bq-"]:before {content: "—";} etc.), but figure seems more built-in vs ARIA’s bolt-on, and setting this up seems a little fiddly.

As blockquotes in ALA are main content I personally wouldn’t use aside, although @murtaugh’s code sample above would be perfect for magazine-style pullquotes (a phrase from the article repeated in large type, intended to tempt you to start reading). section also seems overkill to me as blockquotes don’t have headings, although admittedly this isn’t a requirement.

I wouldn’t use address for the quote’s author, unless it was used to provide contact info for the author, which would seem a little creepy to me ^_^ Using a Person Microdata or Microformat for the author might be worth it, but only if you could automate it, and this still seems a little overkill since you’ve just linked to an article of theirs:

<a itemscope itemtype="http://schema.org/Person" itemprop="url" href="http://www.alistapart.com/authors/h/stephenhay"><span itemprop="name">Stephen Hay</span></a>

The cite attribute on blockquote is also something I’d only add if it was automated (beware ye metacrap), and only in addition to a visible link.

There’s no one true pattern in the spec for this yet, so I don’t think any of these ways are wrong. It would be a great SimpleQuiz question for H5D actually…

PS Love your work, all — thanks for making the web a better place! \o/

Apologies for butting in, but this entire conversation seems bizarre, and I feel like you might be an example for others, so for the sake of the entire interwebs, I am forced to offer some sort of sensical intercession.

First, a blockquote is a quote that is more than four lines long that appears in the body of a work. So, semantically, if that's what you're aiming for, you would never use a blockquote for an aside. And you definitely wouldn't use figure.

Second an aside can be anything that does not appear in the main body of the work. Anything. It can be a pullquote, a chart, a sidebar, a whatever. Semantically, a blockquote would never appear in an aside as a pullquote.

For semantic purity, a blockquote would appear between two paragraphs:

<p>....</p>
<blockquote></blockquote>
<p>....</p>

In proper "style", the cite would be included as text within the preceding paragraph. To connect the citation to the blockquote you have the cite attribute. If, for stylistic reasons, you would like the cite to be repeated beneath the blockquote, then using figure is total bullshit. You want section.

<p>....</p>
<section>
     <blockquote>....</blockquote>
     <cite>....</cite>
</section>
<p>....</p>

That is a semantically pure blockquote.

Pullquotes are a different beast. Semantically, they are nothing. They are visual fluff designers use to add emphasis and move the eye around the screen in a pleasing manner. They have nothing to do with the content and can be removed, wholesale, with no impact on the content. So, for example, for small screens, you might hide pullquotes entirely.

You wouldn't create pullquotes using figure. Figure is something more akin to a footnote. Footnotes are not critical to the content, but they carry more meaning than pullquotes. Hell, they carry meaning. Puyllquotes HAVE NO SEMANTIC MEANING. So, that leaves aside for pullquotes. A semantically pure pullquote would look like this:

<aside>
<p>PULLQUOTE GOES HERE</p>
</aside>

It can go before your content, after your content, or in the middle. Who cares. It has no semantic meaning.

You'll notice no cite. That's because the pullquote is a quote pulled from the content you're currently reading. You don't need a citation. You'll also notice there's no q or blockquote. Q and blockquote are used to flag when you are using someone else's words in your work. A pullquote is your words from your work. Semantically, you do not need to identify the quotation. If, for visual style reasons, you would like your pullquotes to have visual quotation marks around them, and you don't want to actually type &#822x, then use content :before and :after.

So... that's how you use blockquote with semantic correctness. And that's how you create a semantically correct aside.

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.