It’s all too common to see the incorrect HTML used for quotes in markup. In this article, let’s dig into all this, looking at different situations and different HTML tags to handle those situations.
There are three major HTML elements involved in quotations:
Let’s take a look.
Blockquotes
Blockquote tags are used for distinguishing quoted text from the rest of the content. My tenth grade English teacher drilled it into my head that any quote of four lines or longer should be set apart this way. The HTML spec has no such requirement, but as long as the text is a quote and you want it to be set apart from the surrounding text and tags, a blockquote is the semantic choice.
By default, browsers indent blockquotes by adding margin on each side.
As a flow element (i.e. “block level” element), blockquote can contain other elements inside it. For example, we can drop paragraphs in there with no problem:
<blockquote>
<p></p>
<p></p>
</blockquote>
But it could be other elements, too, like a heading or an unordered list:
It’s important to note that blockquotes should only be used for quotations rather than as a decorative element in a design. This also aids accessibility as screen reader users can jump between blockquotes. Thus a blockquote element used solely for aesthetics could really confuse those users. If you need something more decorative that falls outside the bounds of extended quotations, then perhaps a div with a class is the way to go.
blockquote,
.callout-block {
/* These could share styling */
}
Quoting with Q
Q tags () are for inline quotes, or what my tenth grade teacher would say are those under four lines. Many modern browsers will automatically add quotation marks to the quote as pseudo elements but you may need a backup solution for older browsers.
Typical quotation marks are just as valid for inline quotes as the element. The benefits of using , however, are that it includes a cite attribute, automatic handling of quotation marks, and automatic handling of quote levels. elements should not used for sarcasm (e.g. “you would use a tag for sarcasm, wouldn’t you?”), or signifying a word with air quotes (e.g. “awesome” is an “accurate” description of the author). But if you can figure out how to mark up air quotes, please let me know. Because that would be “awesome.”
The citation attribute
Both and blockquotes can use a citation (cite) attribute. This attribute holds a URL that provides context and/or a reference for the quoted material. The spec makes a point of saying that the URL can be surrounded by spaces. (I’m not sure why that’s pointed out, but if you want to anger the semantic code deities, you’ll have to do more than throw spaces around.)
<p>The officer left a note saying <q cite="https://johnrhea.com/summons">You have been summoned to appear on the 4th day of January on charges of attempted reader bribery.</q></p>
That cite attribute isn’t visible to the user by default. You could add it in with a sprinkle of CSS magic like the following demo. You could even fiddle with it further to make the citation appear on hover.
Neither of those options are particularly great. If you need to cite a source such that users can see it and go to it, you should do it in HTML and probably with the element, which we’ll cover next.
The citation element
The tag should be used for referencing creative work rather than the person who said or wrote the quote. In other words, it’s not for quotes. Here are the examples from the spec:
<p>My favorite book is <cite>The Reality Dysfunction</cite> by
Peter F. Hamilton. My favorite comic is <cite>Pearls Before
Swine</cite> by Stephan Pastis. My favorite track is <cite>Jive
Samba</cite> by the Cannonball Adderley Sextet.</p>
If the author of this article told you he’d give you a cupcake, and you him by name, that would be semantically incorrect. Thus no cupcakes would change hands. If you cited the article in which he offered you a cupcake, that would be semantically correct, but since the author wouldn’t do that, you still wouldn’t get a cupcake. Sorry.
By default, browsers italicize cite tags and there’s no requirement that a or
be present to use the cite element. If you want to cite a book or other creative work, then slap it in the cite element. The semantic deities will smile on you for not using either or elements.
But where to put the cite element? Inside? Outside? The upside down? If we put it inside the
or the , we’re making it part of the quote. That’s forbidden by the spec for just that reason.
<!-- This is apparently wrong -->
<blockquote>
Quote about cupcake distribution from an article
<cite>The Article</cite>
</blockquote>
Putting it outside just feels wrong and also requires you to have an enclosing element like a
if you wanted to style them together.
<div class="need-to-style-together">
<blockquote>
Quote about cupcake distribution from an article
</blockquote>
<cite>The Article</cite>
</div>
N.B. If you google this issue you may come across an HTML5 Doctor article from 2013 that contradicts much of what’s laid out here. That said, every time it links to the docs for support, the docs agree with the article you’re currently reading rather than the HTML5 Doctor article. Most likely the docs have changed since that article was written.
Hey, what about the figure element?
One way to mark up a quotation — and in a way that pleases the semantic code deities — is to put the blockquote within a figure element. Then, put the cite element and any other author or citation information in a figcaption.
<figure class="quote">
<blockquote>
But web browsers aren't like web servers. If your back-end code is getting so big that it's starting to run noticably slowly, you can throw more computing power at it by scaling up your server. That's not an option on the front-end where you don't really have one run-time environment—your end users have their own run-time environment with its own constraints around computing power and network connectivity.
</blockquote>
<figcaption>
— Jeremy Keith, <cite>Mental models</cite>
</figcaption>
</figure>
While this doubles the number of elements needed, there are several benefits:
It’s semantically correct for all four elements.
It allows you to both include and encapsulate author information beyond citing the name of the work.
It gives you an easy way to style the quote without resorting to divs, spans or wretchedness.
Not ! Those are for attention-grabbing modals. Dialogue, as in, conversational exchanges between people speaking or typing to each other.
Neither
nor nor are to be used for dialogue and similar exchanges between speakers. If you’re marking up dialogue, you can use whatever makes the most sense to you. There’s no semantic way to do it. That said, the spec suggests
tags and punctuation with or tags to designate the speaker and tags to mark stage directions.
Accessibility of quotes
From the research I’ve done, screen readers should not have any issue with understanding semantic-deity-approved ,
, or tags.
[VIDEO]
More “ways” to “quote”
You can add quotation marks to a
using CSS pseudo elements. The element comes with quotation marks baked in so they need not be added, however adding them as pseudo-elements can be a workaround for older browsers that don’t automatically add them. Since this is how modern browsers add the quotation marks there’s no danger of adding duplicate quotes. New browsers will overwrite the default pseudo elements, and older browsers that support pseudo elements will add the quotes.
But you can’t, like I did, assume that the above will always give you smart opening and closing quotes. Even if the font supports smart quotes, sometimes straight quotes will be displayed. To be safe, it’s better to use the quotes CSS property to up the intelligence on those quotation marks.
Now let’s look at quote levels. The tag will automatically adjust quote levels.
Let’s say you’re in an area that uses the British convention of using single quotes. You could use the CSS quotes rule to put the opening and closing single quotes first in the list. Here’s an example of both ways:
There is no limit to nesting. Those nested elements could even be within a blockquote that’s within a blockquote.
If you add quotation marks to a blockquote, know that the blockquote does not change the quote level the way a tag does. If you expect to have quotes within a blockquote, you may want to add a descendant selector rule to start elements within a blockquote at the single quote level (or double quotes if you follow British conventions).
blockquote q {
quotes: "‘" "'" "“" "”";
}
The last quote level you put in will continue through subsequent levels of quotation. To use the double, single, double, single… convention, add more levels to the CSS quotes property.
Many typography experts will tell you that hanging the quotation marks on blockquotes looks better (and they’re right). Hanging punctuation is, in this case, quotation marks that are pushed out from the text so that the characters of the text line up vertically.
One possibility in CSS is using a slightly negative value on the text-indent property. The exact negative indentation will vary by font, so be sure to double check the spacing with the font you end up using.
blockquote {
text-indent: -0.45em;
}
There is a nicer way to handle this by using the hanging-punctuation CSS property. It’s only supported in Safari at the time of this writing, so we’ll have to progressively enhance:
/* Fallback */
blockquote {
text-indent: -0.45em;
}
/* If there's support, erase the indent and use the property instead */
@supports ( hanging-punctuation: first) {
blockquote {
text-indent: 0;
hanging-punctuation: first;
}
}
Using hanging-punctuation is better because it’s less fiddly. It’ll just work when it can.
Why you’d need to do this, I’m not totally sure, but the quotation marks in a tag are added are pseudo elements in the UA stylesheet, so we’re able to select and style them — including animation — if we need to.
Wait, maybe we just solved the air quotes thing after all.
