1) I noticed the updated version (at least in the example) has no paragraphs within the `blockquote`. Under XHTML, `blockquote` could not contain naked text. Has that requirement changed in HTML5?
2) Did you consider providing `id`s for each `figure` as well, so they could be referenced from the surrounding copy or from other articles and sources?
On a semi-related note, have you moved to using `figure` for code blocks as well?
I’m curious if you considered using a <footer> tag inside the blockquote, per this article from HTML5 Doctor? It’s what I’ve been using, though I admit I prefer your idea of using CSS to include the em dash. It’s great to see some of the thinking that went into the details of the new design!
@aaron — I’d forgotten that about XHTML — yep, in HTML5 blockquotes no longer require any children elements.
I considered the IDs, but when deciding on the final pattern, some things fell by the wayside in favor of ease-of-production. It’s something more likely to be addressed on an individual basis as articles are produced.
Code blocks aren’t in figures, again mainly for simplicity, but also because the figured element is for content that isn’t mission critical to the piece, and code blocks are normally much more integral to an article than images or illustrations are.
@pat — we did, and I was leaning that direction. But in the linked discussion the HTML5 Doctor himself showed up to tell us that the spec had evolved past that recommendation.
Although it’s not ‘forced’ upon you, I’d still opt for using paragraphs inside blockquotes. It’s also used in the examples that W3C gives you, as well as other sources like MDN.
In case you have more than one paragraph as a quote, you need them anyway ;-)
Wrapping it in a figure is excellent indeed, but the figcaption is not semantically correct. It should be used to describe the figure (which in this case would be both the quote and the source.
I would opt for:
<figure>
It is the unofficial force—the Baker Street irregulars.
Sherlock Holmes, <cite>Sign of Four</cite>
<figcaption>Figure 1: the famous quote everyone knows.</figcaption>
</figure>
@pat Using footer inside the blockquote isn’t valid, according to an alert on the same page you linked. The blockquote is intended to contain a quote, not meta information about said quote.
@tim The figure element is one of the nice features of HTML5, since it provides a semantic container for different object types, such as images, tables, videos, and blockquotes. The figcaption is a bonus. I much like the combination over the old generic div technique.
Nice. We’ve done the same research in the last months and came up with the same conclusion: figure>blockquote+figcaption for Quotes — now we use almost the same code as you have here on all the in-article quotes on http://www.macprime.ch
What’s the strategy for supporting the old markup style too? Keep the CSS for both? Go back and update old posts? (manually, or with some script). Serve different CSS depending on age of post?
@chris coyier: There are some styles for supporting legacy CSS, but not many. We did some search-and-replace in the DB for simple patterns (like replacing div.illustration elements with figures) but we really need to go in and edit each article by hand. Over a decade of content, there have been a lot of hands and a lot of variations on approaches to the HTML.
Copy & paste the code below to embed this comment.
Anthony Ticknor
I love this markup pattern. I had recently started using something similar (sans cite and keeping the en dash inline). I’ll be cutting over to try this immediately the next time the opportunity arises.
Putting the blockquote in a figure seemed more like blockbloat to me at first, though I’ve come to appreciate this pattern. Looking at your gist of the different ways you use this pattern on ALA, I’m curious how you guys handle links in your figcaption.
https://gist.github.com/4489740#comment-761683
P.S. Would be great to preview comments before submitting them and know what html we can use in the comments. Markdown? HTML?
I can see the value of `figure` and `figcaption` to link the quote and author together but it just seems a bit of an afterthought or hack (not by you, more so by Hixie et al.)
I’d rather see a specific attribute for this (`@author`?) — just as we can currently use a `cite` attribute linking to a URL…
Surely the author should not be placed inside the `blockquote`, so we would need a new element for it. I agree with @adactio that the `cite` element should be a fine candidate, even though the Spec disagrees. Remember the old 24 Ways article? http://24ways.org/2009/incite-a-riot/
If `cite` was fine for marking up the author of a quote the only thing we would need is an attribute linking the two together (something like a `@source` attr. linking to a (block)quote ID?)
Thanks for giving us some insights in your considerations. Any specific reason you do not use the humble `q` element for inline quotes?
Oops. Only now I read https://gist.github.com/4345988 (I thought the other gist with the code examples was the only one linked). Many good points there (already mentioning Aria @describedby etc.).
This is interesting. I was struggling with semantically how to deal with the notion of ‘pull quotes’ (to use the print design term). I felt like Blockquote was the way to go but that didn’t help with the source. I actually thing that this patter with the addition of Figure and Figcaption works nicely. As Aaron pointed out it would be a nice addition to add IDs – that would be an interesting thing to add perhaps via JS in the WYSIWYG if you are writing in a CMS so that it would end up in markup but be generated automatically.
22 Reader Comments
Back to the PostAaron Gustafson
Two things:
1) I noticed the updated version (at least in the example) has no paragraphs within the `blockquote`. Under XHTML, `blockquote` could not contain naked text. Has that requirement changed in HTML5?
2) Did you consider providing `id`s for each `figure` as well, so they could be referenced from the surrounding copy or from other articles and sources?
On a semi-related note, have you moved to using `figure` for code blocks as well?
Pat Dryburgh
I’m curious if you considered using a
<footer>tag inside the blockquote, per this article from HTML5 Doctor? It’s what I’ve been using, though I admit I prefer your idea of using CSS to include the em dash. It’s great to see some of the thinking that went into the details of the new design!Tim Murtaugh
@aaron — I’d forgotten that about XHTML — yep, in HTML5 blockquotes no longer require any children elements.
I considered the IDs, but when deciding on the final pattern, some things fell by the wayside in favor of ease-of-production. It’s something more likely to be addressed on an individual basis as articles are produced.
Code blocks aren’t in figures, again mainly for simplicity, but also because the figured element is for content that isn’t mission critical to the piece, and code blocks are normally much more integral to an article than images or illustrations are.
Tim Murtaugh
@pat — we did, and I was leaning that direction. But in the linked discussion the HTML5 Doctor himself showed up to tell us that the spec had evolved past that recommendation.
Reinier Kaper
Although it’s not ‘forced’ upon you, I’d still opt for using paragraphs inside blockquotes. It’s also used in the examples that W3C gives you, as well as other sources like MDN.
In case you have more than one paragraph as a quote, you need them anyway ;-)
Wrapping it in a figure is excellent indeed, but the figcaption is not semantically correct. It should be used to describe the figure (which in this case would be both the quote and the source.
I would opt for:
<figure>
<figcaption>Figure 1: the famous quote everyone knows.</figcaption>
</figure>
Reinier Kaper
Sorry, my HTML doesn’t parse that well, but you get the gist of where the blockquote tags go ;-)
Grant Palin
@pat Using footer inside the blockquote isn’t valid, according to an alert on the same page you linked. The blockquote is intended to contain a quote, not meta information about said quote.
@tim The figure element is one of the nice features of HTML5, since it provides a semantic container for different object types, such as images, tables, videos, and blockquotes. The figcaption is a bonus. I much like the combination over the old generic div technique.
Reinier Kaper
I’m sorry, the attribution should not be in the blockquote of course. Why can’t I edit my posts? :-D
Reinier Kaper
Sorry, just delete my posts, I’m not thinking straight. The markup is fine.
Tim Murtaugh
@renier — comment editing is in the works.
Pat Dryburgh
Thanks Tim and Grant. I guess I have some more reading ahead of me. Thanks for the correction!
ＪＳＣＡ ☁
Loved reading the back-and-forth on the gist discussion of proper markup. Thanks for sharing!
michaelstrelan
The final HTML5 example is missing a closing cite tag.
Stefan Rechsteiner
Nice. We’ve done the same research in the last months and came up with the same conclusion: figure>blockquote+figcaption for Quotes — now we use almost the same code as you have here on all the in-article quotes on http://www.macprime.ch
Chris Coyier
What’s the strategy for supporting the old markup style too? Keep the CSS for both? Go back and update old posts? (manually, or with some script). Serve different CSS depending on age of post?
Tim Murtaugh
(I just fixed what looked like an unclosed cite tag in the snippet — I neglected to escape the closing cite tag.)
Tim Murtaugh
@chris coyier: There are some styles for supporting legacy CSS, but not many. We did some search-and-replace in the DB for simple patterns (like replacing div.illustration elements with figures) but we really need to go in and edit each article by hand. Over a decade of content, there have been a lot of hands and a lot of variations on approaches to the HTML.
Anthony Ticknor
I love this markup pattern. I had recently started using something similar (sans cite and keeping the en dash inline). I’ll be cutting over to try this immediately the next time the opportunity arises.
Brett Jankord 1
Putting the blockquote in a figure seemed more like blockbloat to me at first, though I’ve come to appreciate this pattern. Looking at your gist of the different ways you use this pattern on ALA, I’m curious how you guys handle links in your figcaption.
https://gist.github.com/4489740#comment-761683
P.S. Would be great to preview comments before submitting them and know what html we can use in the comments. Markdown? HTML?
David Hund
I can see the value of `figure` and `figcaption` to link the quote and author together but it just seems a bit of an afterthought or hack (not by you, more so by Hixie et al.)
I’d rather see a specific attribute for this (`@author`?) — just as we can currently use a `cite` attribute linking to a URL…
Surely the author should not be placed inside the `blockquote`, so we would need a new element for it. I agree with @adactio that the `cite` element should be a fine candidate, even though the Spec disagrees. Remember the old 24 Ways article? http://24ways.org/2009/incite-a-riot/
If `cite` was fine for marking up the author of a quote the only thing we would need is an attribute linking the two together (something like a `@source` attr. linking to a (block)quote ID?)
Thanks for giving us some insights in your considerations. Any specific reason you do not use the humble `q` element for inline quotes?
David Hund
Oops. Only now I read https://gist.github.com/4345988 (I thought the other gist with the code examples was the only one linked). Many good points there (already mentioning Aria @describedby etc.).
Jason Pamental
This is interesting. I was struggling with semantically how to deal with the notion of ‘pull quotes’ (to use the print design term). I felt like Blockquote was the way to go but that didn’t help with the source. I actually thing that this patter with the addition of Figure and Figcaption works nicely. As Aaron pointed out it would be a nice addition to add IDs – that would be an interesting thing to add perhaps via JS in the WYSIWYG if you are writing in a CMS so that it would end up in markup but be generated automatically.