But: We have a semantic problem. There’s nothing meaningful, other than proximity, to tell us (or machines) that the
p
tag that follows theblockquote
should 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 atfigure
:<figure class="quote"> <blockquote>It is the unofficial force—the Baker Street irregulars.</blockquote> <figcaption>Sherlock Holmes, <cite>Sign of Four</cite></figcaption> </figure>
Not only does the spec for
figure
perfectly align with our needs, it even comes with the convenientfigcaption
element; 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!
Update: at least someone agrees with me.
Post a Comment