Choosing the right element for your markup is not a life-and-death situation. Nonetheless, I think HTML becomes easier to maintain and easier to read when content is marked up in a more meaningful manner, in line with the new developments in HTML5.
HTML5 has, as most of us know, introduced a new <aside> element, which I feel can replace the <blockquote> element in specific places where we would normally think a <blockquote> is more appropriate.
Rethinking Markup for Pull Quotes
Pull quotes have been used in print design for as long as many of us can remember. I’m sure they go back long before I was ever born. And online they have become a staple for many sites.
One site that comes to mind in the web dev niche, that uses pull quotes, is Nettuts+. Here’s a recent article that shows how they use pull quotes in their articles and tutorials. I’ve screen-grabbed their pull quote with the HTML visible in Chrome’s developer tools:
In the example above, and in many other cases, this is the kind of ‘quote’ that would be more semantically correct if placed inside of the <aside> element. To confirm this, let’s compare what the spec says about <aside> as well as what it says about <blockquote>:
Regarding <blockquote>, the spec says:
The blockquote element represents a section that is quoted from another source.
And for <aside> it says:
The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.
The element can be used for typographical effects like pull quotes or sidebars, for advertising, for groups of nav elements, and for other content that is considered separate from the main content of the page.
Notice two key points here: First, the <blockquote> element is not meant to be used for material quoting the same source where the <blockquote> is found (as is the case on Nettuts+). This seems to be changed from how it was defined in HTML4. Second, the definition for the <aside> element specifically says that it could be used for pull quotes, and that its content is “considered separate” from the primary content.
You Know You’re Using it Wrong If…
So to summarize why <aside> (and not <blockquote>) should be used for pull quotes, here’s how you can determine if you’re using these elements incorrectly:
- If you can remove an
<aside>from the page, and the content to which it’s tangential becomes incomplete, then you should not be using<aside> - If you can remove a
<blockquote>from the page, and the content around it is complete even without it, then you should not be using<blockquote>
So only use <blockquote> to quote external sources that are part of the primary content, not for ‘side’ content that’s decorative or is repeated in the primary content. The two quotes in this very article are legitimate <blockquote> content because without them the content would be incomplete.
If Nettuts+ were to change their markup to HTML5 (they’re currently using XHTML strict), then some of their blockquotes would now be inconsistent with the spec. Which raises the question: Doesn’t this go against the principle of HTML5 being backwards compatible with existing content? I’m really not sure, but this does seem to make many older pages somewhat obsolete — if only in a trivial way.
I would like to say one thing on this.
Do we really need to go by such rules about using blockquote and aside?
They are tags. We can always decide upon the way we wish to use them.
I agree completely.
Most of this HTML5 talk all around the Internet is lots of noise and almost zero information.
A web-page foremost is a type of DOCUMENT called “web-document” and as all documents, it should be crafted with semantics in mind. Its like correct Grammar for a writer. All the latest innovations that came after “Dark-age of IE-mentality” web-developing age, primarily focuses around this paradigm: semantics is “the Grammar” of new Web development, whether you are like it or not (whether you are “Grammar person” or not). Thus, I strongly believe that you *cannot* decide what tag should be used where and how – thats done by standards. Last time when “someone” did that (decide by “themselves”: check MSDN for tons of illusionary HTML non-sense as reference), we lost decades of potential progress in Web development.
:( This comment system really needs some Edit feature!
Not many comment systems have an “edit” feature. Whatever you want corrected, just tell me and I’ll fix it for you and I’ll delete any follow-up comments that ask for corrections.
And regarding what you said about semantics. I agree to some extent. But remember that semantics need to have a purpose, otherwise I wouldn’t worry to much about them.
To get that into the specs of each tag seems a little excessive… Tags aren’t always going to be used as defined, take the
<table>tag, it used to be used to format entire websites, when it was only meant to contain data. More currently, the<section>and<article>tags aren’t always used correctly, but people interpret them as they wish.Also, HTML5 tags are still open to change, so it may end up having a different definition. I just think changing something from
<blockquote>to<aside>would actually decrease the ease of maintainability and readability because everyone knows what a blockquote is, why change it? Even if it isn’t 100% semantically correct. It seems like an extremely small nit-picky thing.Well, the more I read about HTML5 the more confused I get. I already used it at a few projects of mine and I thought that I master it pretty good. But looks like that’s far from true …
I can’t think of anything that changes depending on aside v blockquote. As such, I think the semantic value of this debate is close to zero :(
Oh you and your rebellious ways! :)
Honestly? I agree with you and with the other commenters who implied that it’s just a small thing (which is why I called it “trivial” in the last sentence). But I would like to see the specification be rewritten to inform developers that none of this really matters. Otherwise, why even provide such concrete-sounding definitions in the spec?
So, what I get from your way of writing is that you believe that some code or set of rules need to be followed while using tags. Each tag needs to be used for what it is meant for. Am I correct? :) [Hope I didn’t offend you]
No, not necessarily. The HTML5 specification sets out some “rules”, and I do my best to repeat those. I do try to use them as suggested, but I don’t spend hours deciding, I just use whatever I think fits.
So, no I don’t necessarily think there should be a set of rules, but if the HTML5 spec is going to have them, and they still don’t matter, then I think it would be good if the spec made this clear.
In other words, the spec should say: “Using
<article>instead of<section>isn’t going to matter to screen readers, browsers, or any other machines, but here’s our recommendations for use.”Well, this is one thing I will go with you.
And I didn’t say earlier, but nice article. I really love this part.
Great point, Louis. But I am not really convinced regarding the use aside for pull quotes from the same text.
Firstly, because the aside-element is a section, a semantic div. When you take the most striking statement from your text and put it in a pull quote by using aside, it is segregate somehow, even if the aside-element is a child of the section where the text is in. If you don’t know the plan, would the markup tell you, that this is a pull quote from the text in the parent element?
Secondly, the quote is not tangentially related to the content. It is a copy of it. In reality, websites use aside for announcing related or even unrelated articles.
I am not sure, but there is a third point. The quote is a doublet of the running text. The statement is in the text and it is in the quote. So we can say, the pull quote is not content, it is design or ornament. Its intention is to draw the attention or to do some foreshadowing on what will be said in the next section of the text.
So, what comes in mind is the new b-tag. The spec says: “The b element represents a span of text to which attention is being drawn for utilitarian purposes without conveying any extra importance and with no implication of an alternate voice or mood, such as key words in a document abstract, product names in a review, actionable words in interactive text-driven software, or an article lede.”
Doesn’t that fit very properly to an eye-catching pull quote? If I were a news-magazine, using pull quotes all the time, I would mark the statement in the running text with b-tags, and write a jQuery-thing, that looks for the b-tag in the same element, duplicates it and puts the duplicate in pull quotes.
“But I would like to see the specification be rewritten to inform developers that none of this really matters.”
I think the best part of this article is actually just bringing it to more people’s attention. I guess you could go ahead and use it if working on something new but all in all the difference is well nothing.
I also agree with the comment by Belles Lettres and use of the b element.
This is a great example of how the meaning of “semantic” in web design and in the real world becomes alarmingly different — which serves as a really unsettling reality for an editor who works in the web design world.
For instance, a “block quote” in printed typography (at least in academic uses) is a quote of at least four lines, thus making the first quote used in the article not an appropriate use for a
<blockquote>tag. I certainly recognize that in the wide, wild world of the web four lines is just a ridiculously long amount of copy; I do not, however, recognize that quoting a single sentence requires such intense visual tagging.Nor do I think it semantically meaningful to call a pull-quote “tangentially related” to content. It’s literally part of the content, if repeated, and is designed to draw attention to the content. (Which, to my mind, proffers an argument for making pull quotes a CSS question, rather than an HTML one, since they’re a matter of presentation more than one of content.) That seems equivalent to calling an image or infographic that sums up an element of an article “tangential.” Sidebars too may be sometimes tangential, in that they don’t easily fit into the flow of an article, but they often provide extremely useful commentary or clarity that can’t really be considered separate from the content.
In short, to describe anything within the spectrum of things that don’t necessarily fit into the main content of an article as an “aside” is just plain semantically bizarre. After all, wouldn’t any taxonomy classing a pull quote and advertising under the same term seem ridiculous?
To me, then, the real question is “If HTML is for content and CSS for presentation, why would we worry what HTML tag is used for a pull quote?” And, if we were to keep in mind non-Web presentations, “Why is there a blockquote tag in the first place?” If it were just to cite an external reference, wouldn’t it juts be ?
I love the idea of an umbrella tag to contain other extraneous content. In this case, if the two tags were used as the author indicates, then you could isolate “content” from “other crap” that could make it much easier to re-purpose your content.
I actually like this type of arguments. Unlike Paul Irish. :)
There are a lot of gray areas in HTML5’s definitions for new elements and the accent that is put on related technologies rather then on semantics of the markup makes it look like HTML5 is just a bunch of tags you can sweep the floors with.
OK, maybe that’s a bit too much. :) Still, to read something like “They are tags. We can always decide upon the way we wish to use them.” really shows that HTML5 needs more semantics talks and less technical talks. “Terence Blacker: Not every adulterer is a villain” but semantics have now a bigger role in accessibility, and, as such, one should be careful about the vessel too.
Unless “Tags aren’t always going to be used as defined, take the
<table>tag, it used to be used to format entire websites, when it was only meant to contain data.” doesn’t rise a question mark in ones mind. If anything goes, than I too believe “the semantic value of this debate is close to zero”.One point I was making in an article of mine: “H-Section” (http://www.itmitica.com/en/articles/html5/h-section/) that has some relation with this article’s subject is that maybe “article element can also be thought off as as the superior blockquote element”?
I don’t personally classify both tags in the same category for there’s a major difference :
<aside>is a “wrapper” tag, meaning can contain other types of semantic tags.<blockquote>contains “data”, in other words text content, and isn’t meant to wrap other tags (ok, maybe or , but not much more).The HTML5 model is quite fantastic and extremely well designed since it provides semantic tagging that covers data AND structure :
<section>,<article>,<header>, and<footer>for example are meant to:– create a whole semantic-related structure once imbricated
– contain any semantic-self-defined block elements
So my answer to the debate “aside or blockquote” would be “both”, and a correct implementation would be :
In the example of Nettuts+ I agree
<aside>would be a better choice…As for generally replacing blockquote I’m unsure, if this was something that was semantically superior wouldn’t they have just removed blockquote from that HTML5 spec?
I think that this is going to come down to each individual situation and based on that what one you should or shouldn’t use.
Nice Share… this to show people how to use semantic html and not only use
<blockquote>for everything!The summary makes me shake my head and sort through the negatives to figure out if it’s correct or not. I’m not even sure this is what you’re trying to say, but this is my own summary:
– Asides should never be vital to the content. They supplement the content. (rephrasing, for example)
– Blockquotes ARE part of the content. It’s merely a visual way to distinguish longer quoted passages which are part of the content.
So when it comes to pullquotes, Asides are the way to go.
Unlike some of the other commenters, I do think this is an absolutely vital distinction not just for semantics of the markup, but for the entire visual presentation layer. Both are likely to be visually distinguished int two completely separate ways. The blockquote might be nothing more than a text indent possibly with tighter line-height. The aside is likely to literally be off to the side, maybe surrounded by a border and with a different background color.
How is this not an important distinction, then? Otherwise, you’ll still be classing one or the other to make them distinct. I mean, you can make ANY element behave the same, so obviously there’s a line to be drawn for semantic importance (you could just as easily do <p class=”pullquote”>, forget about the two tags discussed here)… and that being the case, the difference in meaning at both the conceptual and semantic levels, COMBINED with the difference in the visual presentation layer make this one of those cases where it DOES matter, in my opinion.
As a longtime journalist and newbie website designer, this makes sense to me if I substitute the words “block quote” for “pull quote,” that is to say one is “pulling” or “extracting” a salient quote from the copy. Similarly, substituting the word “sidebar” for “aside” makes more sense to me, from a journalist’s point of view.
The problem is that blockquotes have always been abused. If developers had used them in a similar way to the way they are used in print (an extended quotation from another source) then we wouldn’t have this problem. Instead they’ve been used either for presentational reasons or simply as tags to attach some CSS, so now we’re scrabbling around trying to fit this bodged use into something semantic, and struggling.
My opinion is that I love new tags. Anything that gives me additional, logical tags to utilize that are not only going to make sense to me but to others using my code, I am more than happy to employ them. I think the big issue with this topic, as with many, is a lot of people have spent a lot of time and practice doing things a certain way, so introducing new methods of doing similar tasks gives the impression they are all the sudden wrong. I don’t think that is the case or the purpose of this article. The way I understand the article is that it defines when the most logical circumstances are to use these new options in tendem, but that doesn’t mean any one has to.
The reality is that you CAN do most everything with classes, h1 and p tags that you can with the other elements, but it may not be the best way or the clearest. Especially if you are sharing code with other designers or developers.
I found this article to be very enlightening and my only question would be SEO related as far as the weight given to the two items. But there my not even be a real answer to that yet anyway.
Thanks to all that have posted though as the article plus comments have made for a very informative and interesting read!
Every time I read a new article on HTML5. Things get more confusing :P
I don’t mind the creation of tags such as aside and similar tags that allow me to just wrap a paragraph in a tag, as I do a blockquote, and it is automatically styled. What we need to go with each tag however, is a corresponding button on wysiwyg editors.
My company is developing WordPress sites for communications types and small business owners who have no knowledge of html. If they can’t type it in the tinymce editor, select it, and press a button – like they do with a blockquote – they can’t use it. Thus as a designer, I can’t create divs that, if they could add a class to their paragraph, could become a pull quote. If there is an aside button on the editor, I can style it and they can add it.
Hopefully, that is where this will go.
Why bother? I would use blockquote anyway.
In my opinion the correct use of tags like that becomes more and more important when you think of a website being accessable to people with Disabilities.
For instance: blind people can uses programs that read the content of a site aloud. When I remember that right, some programs look for the tags in order to decide, if and when to read it.
This is most important for tags like NAV, but for we don’t know how those programs will develop in the future and how they rely on the tags, let’s try to use them as “correct” as possible.
As I said: this is NOT that important with “aside” and “blockquote”, but some comments sounded like it was not too important how to use tags in general.
What do you think?
In theory, you’re correct, however, screen readers and other assistive devices currently have very limited benefit from the new semantic tags. And in some cases, the tags actually have been shown to hurt accessibility.
Some accessibility points are brought out in this article:
http://www.netmagazine.com/features/truth-about-structuring-html5-page
And this might also help:
http://html5accessibility.com/