But: We have a semantic problem. There’s nothing meaningful, other than proximity, to tell us (or machines) that the
ptag that follows the
blockquoteshould 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
<blockquote>It is the unofficial force—the Baker Street irregulars.</blockquote>
<figcaption>Sherlock Holmes, <cite>Sign of Four</cite></figcaption>
Not only does the spec for
figureperfectly align with our needs, it even comes with the convenient
figcaptionelement; a perfect container for our citation. Tim Murtaugh
Call me short-sighted, but how is using an element originally intended for images to enclose quoted text any less of a semantic problem?! I don’t see any reference to text in the current spec and no reason to extend it for this use only because the other options are slightly worse. This is a case where the spec should adapt to real-world use, not the other way around.
The element can thus be used to annotate illustrations, diagrams, photos, code listings, etc, that are referred to from the main content of the document, but that could, without affecting the flow of the document, be moved away from that primary content, e.g. to the side of the page, to dedicated pages, or to an appendix.
For the ‘Links’ section of my blog I am using a
cite tag to quote the author’s name at the end of the
blockquote and to link to the article URL. It might not be according to the spec, but it does show visible attribution for the readers and in this case I think it’s better than respecting some unfinished spec that is not even backwards compatible with the way people used
cite until recently. And don’t tell me I shouldn’t put the author inside the
blockquote, his name is mentioned in the article as well!