The blockquote element

The thing about magazines—physical, printed magazines, I mean—is it’s very easy to skip past content. Between your thumb and gravity, weeks of editorial work can be precipitately dismissed in fractions of a second. Flip, flip, flip, flip, flip. “Where the hell is my doctor? My appointment was ten minutes ago.”

You’d only stop to actually read if something caught your eye; an enticing turn of phrase, perhaps, in text large enough to boop a synapse. Editors will take quotations from articles and enlarge them for exactly this purpose. They call them pull quotes because they are pulled—out and up—from the article.

The web is quite a different medium. Which is why skeuomorphic emulations of magazines, replete with simulated page turning (read: cursor dragging), never became prevalent. Arguably, there’s also little point in highlighting some text to draw you in when the hyperlink you pressed already did that job. You’re only there because you already wanted to be.

So what is a <blockquote>?

The “block” part seems to denote a block-level element—which it is. For inline (or “text-level”) quotations, there is <q> instead. Both elements are based on the common HTMLQuoteElement interface.

Before HTML5, there was no requirement that the quotation had to be from an external source. From this standpoint, you could have used a <blockquote> as a pull quote, since pull quotes highlight text taken from the current article/context.

In fact, the default indented styling recommended for <blockquote> is what some folks erroneously consider the “pull” part, since it pulls the text off to one side. Before CSS became prevalent, <blockquote> was often used for this characteristic alone: authors called upon <blockquote> for any kind of text they wanted to see indented.

Even before HTML5, <blockquote> was designated for longer quotations. Indeed, the term “block quotation” precedes the <blockquote> element and the concept of block-level HTML elements. The Chicago Manual Of Style recommends block quotations are over 100 words in length, for example. From this perspective, the element is not really applicable to pull quotes, since these typically constitute a brief phrase or remark. It doesn’t help to clarify matters that some of the examples from the specification itself are not, in fact, very long at all:

<blockquote><p>I bet a narwhal would love that.</p></blockquote>

In HTML5, <blockquote> content “must be quoted from another source”. So that’s pull quotes completely out of the window, then. From an accessibility standpoint, this is a shame. Without an applicable semantic element to identify the bounds of a pull quote, a screen reader user would encounter what seems to be mere repetition. In the following example, the class="pull-quote" element would be read out like any other paragraph, including the paragraph containing the “un-pulled” version of the same text:

<p>In HTML5, `<blockquote>` content _“must be quoted from another source”_. So that’s pull quotes completely out of the window. From an accessibility standpoint, this is a shame.</p> 

<p class="pull-quote">A screen reader user might wonder why they are reading the same thing twice.</p>

<p>Without an applicable semantic element to identify the bounds of a pull quote, a screen reader user might wonder why they are reading the same thing twice.</p>

How to cite the source of a quotation is also somewhat unclear. The <blockquote> cite attribute is generally useless since it’s invisible and most screen readers also ignore it.

<blockquote cite="https://en.wikipedia.org/wiki/Block_quotation">
<p>The Chicago Manual of Style recommends using a block quotation when extracted text is 100 words or more, or approximately six to eight lines in a typical manuscript.</p>
</blockquote>

The <cite> element’s text is as visible as any other text node. The question is: where do we put it? Different versions of different specifications agree the citation cannot be inside the <blockquote> element. That would be to make the citation part of the quotation itself, which would be weird.

The WHATWG specification provides an example where the citation simply follows the <blockquote>. In fact, their example doesn’t even use the <cite> element. It relies mostly on an em dash (that many screen readers will not acknowledge).

<blockquote>
 <p>I contend that we are both atheists. I just believe in one fewer
 god than you do. When you understand why you dismiss all the other
 possible gods, you will understand why I dismiss yours.</p>
</blockquote>
<p>— Stephen Roberts</p>

In terms of accessibility, I consider this a bad practice. Related elements should generally be programmatically grouped so its clear what belongs to what. In which case, I prefer the accompanying example, which uses <figure> and <figcaption>:

<figure>
 <blockquote>
  <p>The truth may be puzzling. It may take some work to grapple with.
  It may be counterintuitive. It may contradict deeply held
  prejudices. It may not be consonant with what we desperately want to
  be true. But our preferences do not determine what's true. We have a
  method, and that method helps us to reach not absolute truth, only
  asymptotic approaches to the truth — never there, just closer
  and closer, always finding vast new oceans of undiscovered
  possibilities. Cleverly designed experiments are the key.</p>
 </blockquote>
 <figcaption>Carl Sagan, in "<cite>Wonder and Skepticism</cite>", from
 the <cite>Skeptical Inquirer</cite> Volume 19, Issue 1 (January-February
 1995)</figcaption>
</figure>

Older versions of the W3C specification used <footer> to house any citations. This <footer> would either belong to a <figure> containing a <blockquote> or to a <blockquote> itself. This appears to be consistent with the concept that both <figure> and <blockquote> elements are—like <body>—considered sectioning roots.

Theoretically, a sectioning root, like a sectioning element, can have a <footer>. However, this is not necessarily the way user agents interpret and implement <figure>s or <blockquote>s, meaning there are likely parsing inconsistencies. In fact, the concept of sectioning roots appears to have been removed from the specification in its entirety.

In which case, I would personally follow the <figure>/<figcaption> example. For especially long quotations, deserving of headings and other structured markup besides paragraphs, I might consider using a <section> (a sectioning element) with a <footer>. However, I would not transcribe the heading levels verbatim. The heading levels should befit the nesting level of the quotation within the parent page.

As for pull quotes, I’m not sure what to tell you. The <blockquote> element is technically incorrect and the omission of any kind of semantic demarcation would be remiss. I would tentatively suggest using an <aside> element. Since the source is the present context, making a citation redundant, I think I might actually label the <aside> with its own content. In screen reader landmark navigation, each pull quote would be listed by the brief text it contains, creating a collection of key phrases from the article.

<aside aria-labelledby="aside-quote-1">
  <p id="aside-quote-1">I have a migraine.</p>
</aside>

That has been fun. I have a migraine.

Not everyone is a fan of my writing. But if you found this article at all entertaining or edifying, I do accept tips. I also have a clothing line: