A few years ago, Dan Cederholm published a series of articles called Simplequiz in which he posed some options for marking up a specified piece of content and invited readers to choose the one they felt was the best way to mark that up. The value was in the comments in which people said why they made that choice and debated the options (which means it is THE LAW that you read the preceeding comments before adding your own). With Dan’s blessing, we’re running an occasional series of HTML5 Simplequizzes.
For the last couple of years, it’s been fashionable to have “fat footers” in websites. Take, for example, Jeffrey Zeldman’s footer:
We see an area with a svelte black background, containing a super-glammo set of six images, each of which has a caption and links to other sites that Zeldman has an interest in: conferences, books, articles, podcasts. Below those images is a copyright notice, some more conventional footer links (contact, subscribe, style switcher) and a blue stripe:
Being HTML5 ninjas, we know that we’ll wrap each image and its attendant caption within
<figcaption> elements – but what will we wrap the whole group of external links in?
Choose from the answers below please. Make sure you show your working out. Escape your HTML, please, or we’ll put a severed unicorn head in your bed.
Figures as direct children of the
<footer> <figure>…</figure> … <p><small>Copyright © 1995–2011 L. Jeffrey Zeldman.</small></p> </footer>
The figures in an
<aside> element nested in the
<footer> <aside> <figure>…</figure> … </aside> <p><small>Copyright © 1995–2011 L. Jeffrey Zeldman.</small></p> </footer>
The images in a
<nav> element inside the
<footer> <nav> <figure>…</figure> … </nav> <p><small>Copyright © 1995–2011 L. Jeffrey Zeldman.</small></p> </footer>
Images in a
<div> element immediately before the
<div> <figure>…</figure> … </div> <footer> <p><small>Copyright © 1995–2011 L. Jeffrey Zeldman.</small></p> </footer>
Images in an
<aside> element immediately before the
<aside> <figure>…</figure> … </aside> <footer> <p><small>Copyright © 1995–2011 L. Jeffrey Zeldman.</small></p> </footer>
Your answers below, please, with your rationale, by Friday 12th March.
87 Responses on the article “HTML5 Simplequiz 6: Zeldman’s fat footer”
I’d go with A
<aside>is used to include some “side notes” that are related to the content around it – in here it doesn’t fulfill this – random links
same goes for
<nav>which, AFAIK, is used to navigate through current webpage content
and u can clearly say it’s a part of footer – then why keep it outside the tag?
so, as i mentioned before, i’d go with A
A: I agree with stryju – the collection of images are an integral part of the footer – they’re not side notes, so an <aside> is semantically incorrect.
E for me.
Purely because the footer element should only really be used for copyright data and author information.. That’s my interpretation of the spec. With the aid of aside for the secondary/related content and images above.
I would say answer B.
The images aren’t part of the article or are article related.
They belong in the footer, but the footer has its own infomation. So i would put it in a aside too
@Gareth : aside is meant for content strictly related to surrounding
<aside>element, isn’t it?
in that case,
<aside>is used incorrectly
None of the above, or some combination of the above while using the SECTION element to encapsulate this thematic grouping of six content items.
E for me as well:
footerelement contains entire sections, they represent appendices, indexes, long colophons, verbose license agreements, and other such content … The
footerelement is not sectioning content; it doesn’t introduce a new section.”
I don’t consider this list of figures anywhere close to an appendix, index or colophon, so it doesn’t belong in the footer. Since these articles are related to the content on the page, the
asideelement makes more semantic sense than a
I’d use either B or E, but I think in the end E wins. Using aside seems to make sense since the content of these figures is clearly tangeantial to the document’s content.
Now, a footer typically contains links to related documents, and clearly ‘tangeantial’ is the opposite of ‘related’. Thus I’d not include the aside in the footer.
Using ARIA roles would make it even clearer:
I would use A as the content is a footer and therefore should be within the footer element. Each image, as mentioned above, should be in a figure element, and the copyright information is correctly within a small element.
My answer is "E".
As is demonstrated in "E", the <figure> elements in Zeldman's fat footer are enclosed in an <aside> element, making them secondary information semantically related, albeit tangentially, to the current document. The <footer> element should contain information only directly describing the the current document (ie. author, copyright, or links to related documents). I first thought about choosing "B" but thought better of it — why include an <aside> within a <footer>? Seems a bit of an oxymoron to toss secondary, tangential information within an element meant to contain information directly pertaning to the current document, no?
Answer "A" is ruled out because it lacks sufficient semantic information to describe the document's content… is this passable? I suppose. But it could better represent its markup, and assistive devices could potentially leverage additional semantics.
Answer "B" is ruled out for the reasons shown in my rationale above in support of answer "E".
Answer "C" is ruled out because I do not consider the six links in Zeldman's fat footer to be a "primary" navigation for the document.
Answer "D" is ruled out because, although potentially correct, it is not as correct as answer "E"; the <figure> elements are enclosed within a <div> which provides no semantic meaning and only serves as a potential handle for document styling.
C. The elements in the fat footer wrapped in a nav element makes the most sense and it’s how I’ve done it on a few sites already.
One thing I don’t agree with is the markup around the copyright notice. Not a fan of the tag because I think it leaks too much presentation into the markup. I know it’s valid, but I never use it for that reason. I can make the text “small” by simply styling a paragraph tag within the footer. But that’s just me nitpicking. :)
The nearest ancestor are all the articles above it, the images/links are related(?) to the articles, right? Pls correct me if im wrong :)
So still going for B
I’m not voting since I’m a HTML5 newbie, but I think in this case it would be useful to clarify some verbiage.
I think what Zeldman, etc have at the end of their webpage is not a footer, but a “bottom navigation section”. The footer of this page is actually the text block “Copyright © 1995–2011 L. Jeffrey Zeldman. Made in New York City. Powered by Happy Cog Hosting.
ISSN #1534-0309. About, Contact, Desktops, Subscribe (RSS). Choose dark orange or off-white color scheme.”
The section above (the one we’re voting on) is a navigation element that just happens to be below the main layout rather than in a sidebar or across the top. So we’re looking at two parts, not one part.
Does that sound right?
Actually, stryju, the aside element’s definition was extended from the original. Originally, the aside had the same characteristics of the print world’s sidebar, which means it would have to be more directly related to the content. Now, though, the element has been redefined to more closely match the web definition of sidebar, which means sidebar-like material can also be included in an aside.
Since this information is sidebar-like material, regardless of its page location, an aside element is the most appropriate container. I say it’s sidebar-like material because it reflects the web master’s interests, not necessarily anything specific to the content that’s in the page at any one point in time.
My first inclination, being an old web fart, would be to use a div, but HTML5 fairies will strike you with the purple flower curse if you use one with sidebar-like material, so aside it is.
Now, the footer is fairly precisely defined to include footer information related to its nearest sectioning content, in this case, we presume to be the weblog content. Author, contact info, copyright information, and other relevant material would be appropriate in the footer, but not the sidebar-like material represented in Zeldman’s fat footer.
So, I agree with Gareth: option E.
I would also go with A.
The images are part of the footer which is repeated on every page of the website. Semantically they are only footerlinks with a accompanying caption, thus A captures the semantic meaning the best.
B and C also make some sense with the above reasoning in mind but I guess the extra use of a wrapping element does not add any meaning to the html and so less is more and A wins.. :)
Even if visually it looks like the that content belong to the footer, its contents are complementary information, a sub-feature.
I’d like to agree on @William Lawrence’s comment – wrapping it in
<section>element would make it better – it would divide it from the content above
@Josh Lockhart : I have to disagree on pointing E as most accurate –
<aside>should be RELATED to content and i don’t see general links as related… maybe i’m wrong here, but that’s my POV
if that’s not up-to-date, then sorry… but i see aside as side informations RELATED to content ;-)
Want a hint at the answer I think Bruce is looking for? View the source of this very page. The “Quick Links”, “Social Links & RSS”, etc. are all in an aside tag & the copyright information is in a footer tag. That most closely resembles choice E for Mr. Zeldman’s page.
From the aside revisited article: “When used outside of an article element, the contents [of an aside] should be related to the site (e.g., a blogroll, groups of additional navigation, and even advertising if that content is related to the page).”
And from the glossary: “The footer element typically contains metadata about its enclosing section…”
The pictures links are not meta data for the website, but they are related to it in a similar manner to a blog roll.
For these reasons I would go for E
I must vote for E.
Since this is Mr. Zeldman’s personal blog and these figures are all related to things related directly to him (events, podcasts, books, podcasts, etc), I see them as belonging in an aside. But an aside not related specifically to an article or page on the site, but instead to the whole site.
One could argue for putting them into the footer for that reason (it’s site-wide as well). But I’m not sure that aside content fits into the definition of what belongs in the footer (though I wouldn’t dock anyone for choosing that).
Not a nav since it’s not navigation within his own site—but navigation within his own external group of things he’s involved in. And since they are tangentially related to the site, I’d skip the div as well.
That’s my logic anyway… :)
stryju, that’s not up to date. I would suggest the following:
If you look in the HTML5 spec, you’ll see an example of a blogroll in an aside element. A blogroll is typically a list of links to items of interest to the web owner, and hence the web site, but external to the web site. Though Zeldman uses figures, the concept is still the same: it’s a list of links of interest external to the web site.
I didn’t agree with the re-definition, but once “sidebar” was used with aside, it was doomed to be misinterpreted, and people starting using aside as “web” sidebar, not “print” sidebar.
The dual purpose nature of the element will cause problems in the future, as the following notes;
I’m torn on B vs. E, but I think I’m going to settle on E.
Assuming the footer is in the same section as the content, the footer is related to the content of the current page. An aside is tangentially related to the content surrounding it; since footer is a non-sectioning element, the aside is tangentially related to the current page regardless of being inside or before the footer.
However, the footer is more appropriate for content about the page, like the copyright, etc. So, since the aside is tangentially related to the page and not the information about the page, it belongs outside the footer.
Absolutely A. navs don’t make sense as they aren’t navigation links inside the site; asides don’t make sense because they’re not asides to the footer, which is the context they appear in.
I’ll go with E.
The figure implies “the content is essential to understanding it’s section”. But what’s it’s section?
If a div then this means the page content; so doesn’t work for me
If an aside then – with the update to the aside definition inferring secondary content – it probably works better.
If the aside is in the footer this makes it secondary content to the footer (usually reserved for copyright etc) and it feels too diluted so I would plump for an aside outside of the footer hence E.
But equally could work within an (albeit untitled) section.
Although I can’t add anything to the discussion,my initial inclination was E. The eloquent comments above helped me realize that it is the best option indeed.
But I was moved by something Bruce said:
If only style switcher were one of the “more conventional” links to find in a footer! Every website should offer this feature!
Since the footer can contain links to related documents, I think the images should be inside the footer. And I think that putting in into an aside doesn’t make sense. Aside to what, to the copyright? It would have to be an aside to content included in the same element – in this case, the footer.
If I must recode it, I would use a definition list. It’s mostly a matter of planning the content and what emphasis you want on it. Semantics goes hand in hand with SEO, with the main purpose and the points of focus on the page, with marketing and with UX.
I think given the example in your own article here:
It would have to be E. The content is related to the site, not the page, and it’s not part of the actual footer. This could easily be restyled to go vertically down the page in a normal sidebar fashion.
A, B, and C are all incorrect given that it’s not footer content. Leaving only using the DIV or ASIDE, and I think this qualifies for the use of ASIDE.
A is wrong because including that information in the footer element would be a violation of the intended use of the footer.
B would mean the contents of the asides were related to the footer in some way, why else would they be wrapped with the footer element?
C is out as the links may not actually point to links within the site, so can’t really be deemed site navigation, more like internet-wide navigation, so too broad in meaning/
D is a no-go because wrapping the figures with divs is as good as not wrapping them with anything, which implies the figures are directly related to the main content of the page, which they aren’t.
Nice article, Bruce, and *brilliant* discussion from everyone. So much to think about!
I like Stephanie’s point of view, which resembles the mixed browser compromise approach I’m actually using.
If it’s an aside, it’s an aside related to all the site’s content, not to an individual article.
So I put it in a div called “footer.”
My definition of footer differs a bit from Hixie’s, and that’s okay with me. I plead 16 years of designing professional websites.
Hixie is the editor in charge of the future of all the world’s HTML, a position he awarded himself, and which he earns by doing. But he is not a web designer or creative director.
I would argue that the current HTML5 definition of “footer” is too narrow; that it is based on only the narrowest of existing web design conventions; that it ignores best practices of the past five years in favor of a singularly narrow semantic purity—the kind of semantic purity Hixie and others railed against when they saw XHMTL 2 going in that direction.
Luckily HTML is now a stateless ever-changing virus instead of a specification. So eventually Hixie or someone will notice the design work being done by people like Veerle, Simplebits, Jason Santa Maria, and many others, and the definition of footer will change.
I’ll go with A. I think that in footer should be all content that is same on every page and is below the articles or other “middle sections”. I also like the variant with “section” element:
<small> copyright </small>
The links/ads are good asides (extra info) to the content of the site, which is “Zeldman”.
A footer is fairly flexible, but when it contains links I’d expect them to be internal.
Super secret option F.
You can use SECTION tags to enclose all the figures since they are all a related section of ads (for lack of a better term) of the footer.
I agree with those who say E. It seems to me that the use of something like
class="footer"stems from the fact that this thing is at the bottom of the page, and that HTML5’s footer element isn’t appropriate for the whole shebang. I agree that the collection of images and links is tangentially related to the overall content of the site, and is thus an aside to the whole site, not the particular article being viewed, if such a use of aside is allowed.
I’d have to go with A.
And I agree that the spec’s definition of footer is too narrow. It certainly makes sense to have all of the information that appears in black inside of
Given that, the photos should be wrapped inside of
.., but how do you mark up the captions under the figures? It seems like the
(figcaption) is appropriate here.
Couldn’t agree more, Jeffrey. I see no reason a site-wide footer shouldn’t contain site-wide related content (as we already place in a footer) except that the spec, as it currently stands, doesn’t give us that choice. Sometimes, you can get too narrow.
As I’ve been teaching this, I find great areas of confusion among designers/developers. The pure adoption of HTML5 semantics, as they’re currently written, may or may not be adopted. Group think could play a larger role than Hixie would like.
Whoops, didn’t escape my html correctly…
It makes sense to have the images inside <>, so why not put the text and links that are associated with these photos inside <>.
Ok, this is bad, but I’m trying to say “figure” and “figcaption”
Zeldman and Stephanie do have good points.
Again, though, we’re talking about footer, as we may think of it with documents outside the web, and footer as we think of it on the web.
If you enter _define:footer_ in Google, you’ll actually get the definition for both types with the same term. Me thinks this will end up the same as an aside: one term with two meanings, traditional and web. I’m not sure this is a good thing, but does seem to pave the paths trodden by designer feet.
Technically, though, and semantically, I actually agree with Hixie’s interpretation of footer.
I’d go for C as this matches with navigation to me. (http://developers.whatwg.org/sections.html#the-nav-element) It’s related articles, but it’s nav nevertheless.
For me, our HTML ‘newbie’ Jeremy Meyers made a great point when he observed that Zeldman’s footer:
Just because something is visually positioned at the bottom or end, or below rather than beside other content, doesn’t make it semantically function as a footer. On the principle of separating our presentation from our semantics, and that I could imagine a future in which this content is restyled into a sidebar rather than a footer, I wouldn’t enclose it in the site’s <footer> tag. So that’s A, B, and C out.
The block clearly represents content which is tangential to the site as a whole, in the same way as sidebar content is tangential.The fact that it is positioned below the content instead of next to it is irrelevant. An <aside> within the top-level of the document outline (i.e. not within a <section>) is therefore the best way to describe the content’s function and relation to the rest of the page.
On this basis I would opt for E. I think there might be an argument for a variation on C, but with the <nav> outside the <footer> tag. However, this clearly isn’t primary or major navigation, so unless the definition of <nav> changes, I think <aside> is more appropriate.
My initial gut reaction was ‘A’. However, after reading the comments and thinking about it more, I’ve got to agree with ‘E’. The images are clearly tangential stuff that Czar Zeldman is interested in, but they are not the ‘footer’ of the page.
Looking at zeldman.com as a whole, we see that it has a header, a section of articles, 2 asides (the current right side and the fat-footer images) and a footer. Inside the section would be articles, each (potentially) with header and footer elements.
If my line art holds up, I’m seeing the DOM as something along the lines of (not necessarily coded in this order):
| header + footer
aside (current right side)
footer (copyright, etc)
Yes that was my point. OT: to be clear, i’ve been a HTML dork since 1997 (netscape 0.9)…just haven’t done much with HTML5 yet :)
I’m with those who went for super-secret option F – sections inside footer – although I’m sympathetic to the arguments for B and E. Alternatively, super-secret option G might be section before footer.
Woah, woah, woah…
Before debating what the correct containing element is for this content, how about thinking about whether or not they should be contained in figure elements. I’m pretty sure they should not.
The whole point of the figure element is that it could potentially appear *anywhere* in the document: the top, the bottom, the middle. Taking any one of those pieces of content and putting them anywhere else in the page makes little sense. They are at the end of the document for a reason. They are not referenced from the main content of the document.
Just because you’ve got an image with some descriptive text doesn’t automatically make it a figure and figcaption.
I have to agree with Jeremy. The first thing I wondered about here was “Why are we putting these in a figure? Since these are relevant to the page but instead to the entire site I’m uncertain as to what the correct, semantic element would be. Section? Div? All I know is that figure doesn’t feel right.
The questionable use of figure was the first thing I noticed, as well.
menube in order here? With a
ulinside and each
menuis inappropriate (supposed to be reserved for applications?), I think the unordered list structure makes the most sense.
I think I’m looking at 6 asides inside a div followed by a footer
Good thing HTML5 is easy to interpret. Wrap that in a sarcasm tag.
+1 to Mr. Jeremy Keith.
Dale Cruse, ah come on now, HTML5 is _easy_ to interpret. Just look at all the different interpretations in this list?
Why, it’s so much fun, I think it could replace Charades at the number one party game.
…as the number one party game…as…as…
You all need edit capability in your comments for fumbled fingered types like me ;-)
a would use
>p<>small<Copyright © 1995–2011 L. Jeffrey Zeldman.>/small<>/p<
the figures are part of the footer, and are a section of the footer. Since there are several identical elements, it would make sense for me to make them into a list
and the copyright information would be in the footer of the footer
I would also make sure I put the brackets the right way :)
<footer>s aren’t sectioning content, so it makes no sense to have a
I agree with Jeremy regarding the
<figure>s. As far as the essence of the question goes, the links seem to belong in an
<aside>, as opposed to a
<footer>. As the spec says, (emphasis mine).
Figure should be used only if referenced from some other content, like in books.
Hint: think of the question as
Remember the beginning of HTML5. An analysis of the most common ids.
Why do we need those new elements?
– Because its smarter when everybody writes
<footer>instead of a
<p id=footer>or what ever.
And now, take a look at the original html. You will see that there is only the need for A.
I want it a footer. There is no need for more complex nesting.
When browsers or crawlers start treating those elements in a special way we have to rethink.
E without using
To me, it seems to be the less “hacky” solution.
Use the <address /> element.
<img src=”http://www.zeldman.com/i/whit2.jpg” alt=”” />
Whitney Hess makes the crowd fall in love with user experience at
<a href=”http://www.aneventapart.com/”>An Event Apart</a>. Photo ©
<a href=”http://www.flickr.com/photos/localcelebrity/” rel=”author”>John Morrison.</a>
<a href=”/copyright/”>Copyright</a> © 1995–2011 <a href=”/about/”>L. Jeffrey Zeldman</a>. Made in New York City. Powered by <a href=”http://happycoghosting.com/”>Happy Cog Hosting</a>.<br />
ISSN #1534-0309. <a href=”/about/”>About</a>, <a href=”/contact/”>Contact</a>, <a href=”/desktop/”>Desktops</a>, <a href=”/subscribe/”>Subscribe (RSS)</a>.
Choose <a title=”Default style (orange).” onkeypress=”setActiveStyleSheet(‘default’); return false;” onclick=”setActiveStyleSheet(‘default’); return false;” href=”/about/”>dark orange</a> or
<a title=”Switch styles (off-white).” onkeypress=”setActiveStyleSheet(‘offwhite’); return false;” onclick=”setActiveStyleSheet(‘offwhite’); return false;” href=”/about/”>off-white</a> color scheme.
<a href=”http://happycoghosting.com/” class=”hch”>
<img alt=”Happy Cog Hosting” src=”http://www.zeldman.com/wp-content/themes/zeldman-v2/i/hchsmall.png” />
The spec defines an address tag as the contact information for a document – and isn’t that precisely what those links are serving as? The source of confusion for using the <address /> tag is most people seem to think it’s used specifically for making up street addresses
Somewhat off the topic of the main question, but I defend my use of figure and figcaption in the example. The spec says
“Typically” does not mean “must be”.
I’d choose B as those link are not part of the main content of the page but still relates to it as they are pointing to Zeldman’s investments. The way I see it aside is a perfect match.
What’s more it’s in front of that huge black background at the very end of the page. This makes me think that it’s part of that fat footer element and the spec says the footer typically contains links to related documents which is exactly the case in here.
Looking forward to Bruce’s choice! :)
Love these Simplequizes! Keep on rockin’ guys!
But Bruce, for some of the six pieces of content, the text is *not* a caption for something else (images, in this case). The text *is* the content. The images support the text. If anything, the images are illustrations for the text.
Just because some text appears under an image/table/code doesn’t mean the figure element is the correct wrapper. If the text is not actually a caption, then a div would be a more appropriate wrapper.
For Jeffrey’s site, figure might be the right element some of the time but not others. It depends on the content. It *always* depends on the content.
Heads up @Jeremy. The tag references an article/section main content. Jeff’s footer images are tangential to the page’s (and web site’s) main content. Using figure#1, figure#2, figure#3 without reference to content doesn’t make sense. None of the above, wrap in a .
The figure tag references article/section main content. Jeff’s footer images are tangential to the page’s (and web site’s) main content. Using figure#1, figure#2, figure#3 without reference to content doesn’t make sense. None of the above, wrap in div .
Jeremy states “The images support the text.”, presumably presented as perspective on why it’s NOT like the figure element …when in fact, conventional uses of figure generally DO exist (as images w/captions) expressly TO “support the text” in the flow of main content.
I agree with Bruce’s take on this being intentionally self-contained (Zeldman’s original design goal).
E looks good to me.
Kevin wrote: “Jeremy states “The images support the text.”, presumably presented as perspective on why it’s NOT like the figure element …when in fact, conventional uses of figure generally DO exist (as images w/captions) expressly TO “support the text” in the flow of main content.”
You have misunderstood me. When I said “The images support the text” I meant “The images support the text *within the content that Bruce is suggesting be wrapped in figure element*” not “The images support the text in the rest of the page.”
Kevin wrote further: “…when in fact, conventional uses of figure generally DO exist (as images w/captions) expressly TO “support the text” in the flow of main content.”
Precisely. “In the flow of the main content” being the operative phrase.
Figure originally came about, several years ago, because people asked for a caption element that could be associated with an img element. It then _slightly_ morphed over time.
I believe we will find that both Bruce’s and Jeremy’s understanding of figure are correct.
Bruce is correct because his use most closely matches the original intent of figure, and one that is, technically, supported in the HTML5 spec text. Context of use, other than what can be mapped to a parsing algorithm, is more along the lines of a suggestion (even a strong suggestion) in the HTML5 spec.
Jeremy’s point about a figure having context, as if in “See Figure…” is also correct, and matches other text in the spec, as well as accepted typographical practice regarding “figure” in other mediums.
However, I just can’t find anything related to figure that makes Bruce’s interpretation incorrect, and that’s where I think Jeremy is “wrong” (thought, frankly, my understanding of figure more closely matches his). The phrase, “referenced as a single unit from the main flow of the document”, is ambiguous.
Does this mean, we should have the phrase, “See Figure” in the text somewhere? We’re getting dangerously out of scope for an HTML specification if we start to put in controls over the text in paragraphs.
Or does the “referenced as a single unit from the main flow of the document” mean that the figure is a unit contained in the document, the document being a web page? Well, kind of pushing it, but…this one actually maps if we consider the context from a purely technical perspective.
I strongly prefer Jeremy’s interpretation of figure. At the same time, I don’t think Bruce’s interpretation is “wrong”.
I would choose “None of the above”.
A “figure” (in its true sense) is a device used, primarily in scientific and technical documents, in support of statements and conclusions introduced in the main body of the text. Figures normally take the form of graphs but can also be of other types such as photographs.
As the elements in the footer of the document in question are clearly not intended to be used for this purpose then the use of the element is wholly inappropriate.
On the use of and elements; When so much effort and discussion has been expended over the last few years concerning the separation of content from layout, why are we now introducing elements that have no other conceivable purpose other than to self-declare their position in the layout?
I don’t think I’ll use them.
Doh!.. Try again.
I would choose “None of the above”.
A “figure” (in its true sense) is a device used, primarily in scientific and technical documents, in support of statements and conclusions introduced in the main body of the text. Figures normally take the form of graphs but can also be of other types such as photographs.
As the elements at the foot of the document in question are clearly not intended to be used for this purpose then the use of the “figure” element is wholly inappropriate.
On the use of “header” and “footer” elements; When so much effort and discussion has been expended over the last few years concerning the separation of content from layout, why are we now introducing elements that have no other conceivable purpose other than to self-declare their position in the layout?
I don’t think I’ll use them.
First, let me say that the answer is E. The fat footer is a presentational construct that in the example case is comprised semantically of an aside followed by a footer.
Now, since this thread has mutated into a discussion about the figure element … I have to say that, as is so often the case, I agree with Shelley. There does appear to be a mismatch between what the intent of the figure element is (i.e. strictly following typographic conventions) and what the specification text actually says if you read it in a legalistic-minded manner.
The problem I have with the strict interpretation of the use of figure that Jeremy Keith advocates is that the use case hardly justifies the element at all. The “see Figure 1” writing style is very rare on the web, indeed it’s hardly known outside of text books and research documents (and most of those I see on the web are PDFs, not HTML). One reason is of course that that the “see Figure 1” concept is a typographic device partly to deal with the practicalities of publishing on paper – fixed length pages with a desire not to have the figure span across the page boundary, and in the case of photographic plates, often to put the pictures on a different quality of paper. Neither requirement has any parallel on HTML pages.
In contrast, “captioned flow content” is commonplace, and would fully justify a dedicated element. If figure cannot be used simply to apply a caption to an image or other flow content, then if as a web author one wants to semantically associate a caption with a specific pair of images what is the alternative? As far as I can see, it’s <div aria-labelledby=”mycaption”><img src=”myimage1″><img src=”myimage2″></div><p id=”mycaption”>My Caption text</p>. I think that’s a very poor substitute.
I am in case convinced that the figure element will be widely used to caption flow content, and especially images, no matter what the spec says.
<li><img alt="..." src="..." /><p>...</p></li>
<p><small>Copyright © 1995–2011 L. Jeffrey Zeldman.</small></p>
@Tim: I think your suggested outline is pretty much spot on, apart from the section element which wraps the blog articles. It contains all the main content, not just a section of it, so I would go for
@Alohci: I think Jeremy’s point was that the text is not a caption, because it doesn’t describe or explain the image, it describes the external content being linked to. The image is effectively illustrating the text, whereas a caption would be the text supporting the image. I think your point about where to use the figure element is valid, but doesn’t actually apply in this case.
@Zeldman: Personally I’m fine with the semantics of footer, but maybe its name is the problem. Do you think there would be (such) an issue if it was called something else?
A, same reasoning as stryju in first comment. nav is not applicable here, similary aside is not applicable. And figures should be in footer. So A. I will additionally put them in ul , li, to make nice list.
Mr. Zeldman, I’m curious if anything in this article & related comments is compelling enough to make you want to change the code in your footer. If so, which approach makes the most sense to you?
David Gross, I have to disagree with you.
The images provide a graphic annotation of the external material they link, but the captions provide the necessary context for these images. I’m wary of linking Wikipedia, but the site’s style guide for captions is actually pretty good.
One of the requirements for a “good” caption is that it provides context for the graphic.
Currently, Zeldman has an item with a photo of himself and I’m assuming Dan Benjamin, with head phones on. OK, doesn’t tell me a lot. What? These guys like to put on head phones and Skype with each other? They’re forming a new band, and are in a recording studio?
Read the text associated with the graphic, though:
“Dan Benjamin and I interview UX guru Jared Spool in Episode 7 of The Big Web Show, our weekly video podcast on Everything Web That Matters.”
*bammo* … context. You know what the graphic means, and since it represents what’s linked, you also know the context of the graphic’s association to the external article.
The text (caption) provides the context to help us understand why the heck Zeldman decided to plunk this image into the page footer.
ok, thanks for updating me about aside ;-)
so – can we sum it up? which one “should” be used as it is considered “html5-a-ok”?
@Bruce – with the use of the word ‘typically’ within the spec, practically for every element – does this not trigger alarm bells because it would mean that every different interpretation could potentially be the correct answer?
I stand by my answer of E but reading comments and using the word ‘typically’ from the spec, any one of those answers could be correct and perfectly valid.
Alohci wrote: “I am in case convinced that the figure element will be widely used to caption flow content, and especially images, no matter what the spec says.”
I agree with you there.
E, but sans figure.
The items above the fine print are a list of links with incidental images. An aside is a good way to explicitly indicate their relationship to the page, which wasn’t really possible in HTML 4.
Each item is an annotated link. The associated images act as either graphic headers which could profitably be marked up as heading elements (e.g., “HTML5 For Web Designers”), or as supporting graphic elements that could be a plain img (portrait of Whitney Hess), or background-image (ALA flavour image which may or may not appear in the linked article). The figure element, whose main content is the figure, with caption as an optional accoutrement, isn’t appropriate (regardless of whether it’s referred to from the main text).
The answer is E.
The images in the fat footer are not a footer at all, they don’t finish off the page or section they are just content loosely related to the section they are in. Therefore the images should be held in a aside element and then the copyright would be the actual footer element.
Thanks everyone for the considered comments and debate.
The answer, I think, is E:
<nav>, because those links aren’t links to other pages in Zeldman’s site (or closely related sites).
<div>would be fine – you can still use
<div>– but it’s the element of last resort, and
<aside>is semantically the right choice, as it is defined
I consider that the
<aside>to be tangentially related to the whole of zeldman.com, so would put it immediately before the
<footer>rather than within it. The fact that its styled to look like the same block doesn’t alter those semantics (and you could facilitate syling them together by wrapping them both in a
<div>– did I mention that you can still use
In a comment, Zeldman wrote "I would argue that the current HTML5 definition of "footer" is too narrow; that it is based on only the narrowest of existing web design conventions." I’d argue the opposite, actually. I’d argue that
<footer>are not defined tightly enough. <footer> is defined
But what happens if I want to say, at the top of an article “This comment written by Bruce on 11 March”? A
<header>element would seem to be equally applicable:
Is there really a semantic difference between
I’m similarly interested in the debate that was prompted by my use of <figure> to wrap the images and explanatory text. I waver between agreeing with Jeremy, who called me out on it, and agreeing with Shelley (who thought I was right). Most importantly, I agree with Alohci, who says
I think that the definition of
<figure>will be used to caption such content. and that the spec should be clarified and widened slightly to allow this.
What do you think?
But, zeldman.com is not content per se. Imho, there is no more relationship between this <aside> and the content of that page than there is with the content of any other page within the site.
The spec says:
The way I understand this is that the relationship is between blocks of content in a same document. Saying that this content is related to the whole site makes sense, but I don’t think it justifies making that content an <aside>.
The sectioning nature of HTML5 allows for portable content. HTML5 elements prompt us to consider content hierarchy – to this end the DOM tree.
F. Image and caption twinned in a
<div>, grouped in an
<aside>element immediately before the
G. Image and caption in a
<figure>element, grouped in an
<div>for styling, immediately before the
H. Image and caption in a
<div>, grouped inside the
Ok, It has to be included inside the because it is called a “fat footer” not a “footer with some links above it” and also there is an obvious break in the page when it switches to black. So that knocks out D and E. The tag is used for site navigation not links to videos. You could put it in an but that really depends on if you think videos the author likes is some how related to the article. I would go with A.
If you break it down, this appears to be a footer menu to me.
—->li figure figcaption /li
–>p copyright /p
Jason, how does the menu element fit this circumstance?
Leave a Reply to Steve Adams