Recently, a group of well known web designers issued a “Super Friends” declaration of support or HTML5, with an attached set of concerns. Most of the concerns had to do with the new “semantic markup” elements included in HTML5, such as section, article, and so on. I’ve not previously discussed these new semantic page markup elements, because I had other fish to fry. However, I decided to take a closer look at the elements, particularly at how I would use them for my Drupal sites.
Current Setup
Currently my page has a header, a footer, one sidebar, and the main content area. I have an H1 title for the page, and use H2 for weblog post titles, and H3 for sidebar titles.
I have a main navigation bar at the top of the page in the header, with a skip link for screenreaders. I also display an exploded view of my site navigation in the footer, in addition to copyright/about links. The sidebar contains additional navigational aids, such as links for monthly archives, recent writings, popular items, images, and so on.
All of the content areas are structured using a variety of unordered list items and DIV elements—all of which is typical, not only for a Drupal site, but also WordPress sites, and other CMS themed variations. I also use inline SVG for decoration.
Conversions: header, nav, and hgroup
Starting from the top, according to the HTML5 specification, I would use a header element to encapsulate the content that is currently contained within my DIV element given a class name of headwrap. This would include the top-level navigation, as well as the site title, which remains as an H1 header. According to the spec, the header doesn’t take part in the web page’s outline, which would map to what I would expect, both as a web designer and as a book author. In particular, as a book author, I wouldn’t expect the book title and subtitle to be part of the outline, nor would I expect the Table of Contents to actually display as part of the outline given in the TOC, and a book’s TOC, and a site’s navigation menu are synonymous.
In addition, I would also convert the DIV containing my site’s navigation to using the new nav element, wrapping it around the existing list items. From a Drupal perspective, the nav element maps to the Primary Links block that is standard with all Drupal installations. If I used the Secondary Links block, I would wrap also it in a nav element, and place it just below the main navigation menu.
Though I’ve seen several articles that list the nav element separate from the header, I would embed the nav element within the header, because I consider the main navigation to be part of the introductory text that the page header is supposed to contain. I think you could have them separate, but the key to determining whether they should be combined or separate is if the header part changes separately from the navigation section. If they’re not consistent with each other, they probably shouldn’t be grouped. If they are, they’re grouped. My main navigation and header contents never change, so I’m grouping them within header. Regardless of choice, the HTML5 specification does seem to support both variations of grouped and ungrouped header and nav.
My main navigation menu contains a skip link, which is a link that’s intended to take the person to the content area directly. There’s no harm in the link, and until screenreaders adapt fully to HTML5, I’ll keep the link.
Drupal also provides for a secondary title, or tagline area, which I don’t use. If I did, though, I would use the hgroup to group the H1 for the title and the H2 used for the secondary title. I know folks have had problems with hgroup, but as a book author, I’m aware of title and subtitle, and how they’re treated as one single entity, though with differing formatting. It really wasn’t a stretch to extend this concept to a web page, and the fact that hgroup just allows me to use two different heading element types, but treated as one unit. The element also ranks the headings within the hgroup by highest *header value, which is what I would expect.
Next comes the main content.
Conversion: Main content area, article and section
The main content is a little tricker, but again, I found if I looked at the HTML5 specification more as a book author, and less as a web designer, I felt a little more comfortable with the new elements.
Currently, all of my content, including header, sidebar, and footer, is wrapped in one big DIV element with a class name of rap. I wouldn’t change this, primarily because the overall wrapping has nothing to do with semantics, and everything to do with overall structure and presentation. It is actually synonymous with the body element, and used primarily to manage the margins of the content. Since the body element is, by definition, its own semantic element, defining the rap element using semantic markup is redundant.
For the actual content area, currently I have a DIV element wrapping all of the postings, and then list of one or more postings, each with an H2 header, a metadata section, the main content, and an inner footer containing other links, such as those for adding comments, number of page views, and so on.
After careful reading of both the section and article elements, as well as looking at past articles on the elements [1][2][3][4], I decided I would wrap the entire content area in a section element, though I’m ambivalent on this, and think that keeping it wrapped in a DIV would also work. The reason why I could keep the section as a DIV, is there is nothing about this section that is inherently useful, other than being a group of content. For each individual page, it’s actually redundant, because the main content area, and the article, would be synonymous. Since, there’s nothing semantically useful about the main content, the use of a DIV element would be acceptable, even preferred.
However, I thought about my use of the skip link, and the fact that it goes to the main content area. This, in a way, provides semantic justification to actually use a section element—it’s meaning extends beyond styling. The section is, according to the HTML5 spec, a thematic grouping of content, typically with a heading, possibly with a footer. One could even add a header, with “Main Content”, and there wouldn’t be anything out of the ordinary about it.
Converting the markup for the weblog post was a somewhat simpler task. It’s a given that each weblog post would be wrapped in an article element, especially since this type of element is used with content that can be stand alone, or pulled directly from the page and reproduced elsewhere. Think of syndication feeds, and what works for the web page, works for the feed, and hence, using article is a natural choice. How I would mark up the content within the article, though, gets a bit tricker. I had to put my web designer hat away, and put on my book author beanie with the rest of the content conversion.
Within the article element then, I would add a header for the title, and the address element for the author name. Since address is really meant for “contact” information, I would also wrap the author name in a link for the author’s contact page, or email address, I’m not sure which at the moment.
I have other material at the beginning of a weblog post that doesn’t seem to fit within any element, such as publish date, and taxonomy. And this is where things really get tricky.
Should I continue using a DIV element for this data? Or is this where I would use a new section? There is a time element, but it is described as a machine readable element for adding information to a calendar, and not appropriate for my date, at all. Plus, I use **RDFa for marking up all of my metadata such as this, and I’m not sure how Dublin Core data will work with the time element.
But hold on folks…the time element has a second definition, which is semantically different. There is an attribute, pubdate, associated with time. This is a boolean value. If set to false, then time is a calendar event; if set to false, then time is an actual publication date, if the time element is contained within and article. So I would use time but make sure that pubdate is set to true. I would also add my RDFa annotation to the time element.
I’m not entirely happy about the overloaded semantics of the time element, but grudgingly willing to use it. I’m not so bugged about the overloading to actually protest against the element, or refuse to use it, primarily because I really depend on RDFa to record my meaningful semantics in the web page.
As for the other material, such as the taxonomy items, I decided I would leave them in a DIV element, each with its own RDFa to annotate with the metadata information. I imagine I could use a section element, but frankly, it doesn’t feel right. The information really isn’t a new section, it’s just annotative data about the article. But since it is annotative about the article, I believe it, like the time element should be in the article’s header.
HTML Conversion: Aside, Figure and Legend
The rest of the article will be marked up with the usual mix of unordered lists, paragraphs, block quotes, and so on. Another change, though, will be the use of the new aside element. As a book author, I am aware of what a sidebar is, and how it’s used: it’s used to annotate text that doesn’t have to be included within the flow of the page, but could be pulled out and placed elsewhere, depending on page layout. The text itself is related to the main chapter topic, but it’s additional information that isn’t necessary in order to follow the flow of the main text.
It’s unfortunate that sidebar has another meaning in web page design, being use to refer to the a secondary column within the page flow that could contain navigational items, images, ads, and so on. What makes it doubly unfortunate is that the term sidebar is used to describe aside in the HTML5 specification, but the term is used as a book author or publisher would use the term, not a web designer.
Regardless, it could be a handy element, and I have no confusion about how it’s meant to be used, though I’m concerned that current discussions will redefine it’s use—to that of web design sidebar—in which case I won’t use it.
Another main content element impacted by HTML5 is how to annotate images. Currently, I use the img element to mark images. However, HTML5 introduces the figure element, which can be used to wrap the img element, and also a legend element, which provides the image’s caption. It’s meant to be used when the figure is such that it could be pulled, along with its caption, to a separate space within the web site, such as an appendix.
Again, thinking more like a book author and less like a web design person, figure makes perfect sense. You wouldn’t use it to wrap decorative images that you insert into an article to add a bit of color or flair, but you should use it when you reference the image from the text, or it serves an illustrative purpose.
There has been some pushback on figure primarily because legend has been redefined from HTML 4, where it was used with a form fieldset. However, I think of it less as a redefinition, and more of a extension of the same capability to new areas. My main concern is how existing browsers would handle the element when they parse it. That’s the real issue when you redefine or extend the purpose of an element in HTML5 that existed in prior HTML versions. Still, unless I find browsers throw a hissy fit, I would probably use figure and legend. I would also continue using the alt attribute to mark up the image for accessibility purposes. Speaking of accessibility…
HTML Conversion: Accessibility and ARIA
I am committed to making my pages as accessible as possible, and that also includes the use of the summary attribute for data tables, as well as using the newly defined ARIA annotation of HTML5 elements [5]. The changes to accommodate the new attributes, role and aria-* are extensive, and will require a careful perusal of their purposes, to ensure I understand how best to use them.
However, it shouldn’t be overly difficult to incorporate the ARIA annotation, especially with a tool like Drupal, and especially with Drupal 7, when we’ll have a much finer control of the page generation.
HTML Conversion: Article and Footer, Article and Comments
At the end of my weblog posts is more information, such as a link to add comments, comment count, page views, and so on. This data is currently enclosed in a DIV element. From my understanding of the HTML5 description, I should be using footer to encapsulate this information.
In addition, from my understanding of the HTML5 specification, I should use a section element to wrap the entire comment area, and then use article for each comment, each with its own little header and footer. It seems like a lot of elements, but all of these items are currently wrapped in DIV elements, so the number of elements will end up virtually the same after conversion.
This ends the description of the main content area. Other elements will be used in the main content, including SVG, possibly MathML, and video, code, pre, and ***dialog, but I’ll leave these for another time. Next up, is a discussion on the remaining two sections of the web page: the sidebar and the main page footer.
HTML Conversion: Sidebar and main page Footer
One thing I would definitely not do, is use aside for the web document’s sidebar. Not as it is currently defined, and if it gets redefined, I still wouldn’t use it.
The use of section to enclose the sidebar makes sense. If you think on it, my current document isn’t main content and sidebar—it’s two columns, with different data in each. So, if you use section for one column, you should use section for the other column(s).
Within the sidebar, though, I use DIV elements to manage the different display blocks. Technically I suppose I could use the section element for these, but I use DIV elements specifically to control the spacing, layout, and presentation of the data in the sidebar. To me, this fits the semantic purpose of DIV, which is a perfectly acceptable element. I will continue to use the DIV element when I’m grouping content specifically because I want to group them for a specific reason, and that reason is more to do with styling or ease of access than because of any semantic meaningfulness.
However, I will annotate the contents of the sidebar (or second column, if you will), with ARIA annotations, as well as RDFa, and make use of unordered lists to display lists of items. I’m not throwing semantics to the wind.
As for the page footer, it is odd to have a footer associated with each article, and then have a page footer. However, the content already has class names to mark the differences (including how each is styled), and I will continue with those class names. As a book author, I think of article footer as footnotes for a page, and web page footer as end notes for a chapter, or book. Gets me through the web designer angst with multiple footers in a page.
Currently my web pages have an exploded site menu contained in the footer. I suppose one should wrap this in a nav element also. Originally, the footer was defined in such a way that it couldn’t contain a nav element, but I gather that feedback on this item has changed the HTML5 author’s mind, and we can now use a nav element in footer. Hard to say, the information isn’t readily apparent to a web page author from the HTML5 document.
The footer will contain an address element with contact information, and probably a section to enclose the other data, such as copyright.
The overall page footer does make me wonder, though, whether I shouldn’t convert the overall DIV element identified as “rap” to a section because the footer element is associated with sectioned content, which includes article, aside, section, and nav. Actually, the more I think on this one, the more I think I’ll convert “rap” to a section element, too.
HTML Conversion: the remaining issues
I still have other content that I need to convert. This includes the page level navigation that’s at the end of a Drupal book, or at the bottom of archive and main pages. One would think to use the nav element, but the description of the element seems to preclude its use:
The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links. Not all groups of links on a page need to be in a nav element — only sections that consist of major navigation blocks are appropriate for the nav element. In particular, it is common for footers to have a list of links to various key parts of a site, but the footer element is more appropriate in such cases, and no nav element is necessary for those links.
This also makes me wonder about the use of nav to wrap my exploded site map in the footer, as described in the last section. The same goes for the sidebar links for archives, popular content, and recent writings: these are, technically navigation aids. However, they don’t seem to fit the constraints surrounding nav. In fact nav seems to be more about a site’s main menu than necessarily navigation, provided more as a way of eliminating the skip link than actually annotating navigation. The nav element definitely needs more clarification about its use. Right now, the description of when to use it is too vague.
I’ll have to think more on the use of nav, not to mention section, article, header, and so on. But I think I’ve made a good start on converting to an XHTML5 document. To continue, I would do what others are currently doing, and rename class and identifiers on my DIV elements to what their HTML5 equivalents will be, just to test out how it all works together, and still ensure proper CSS support in all browsers.
I’m not ready to convert to XHTML5 yet, though, not while there are unanswered questions, and unresolved issues. For instance, I did an HTML5 page with an inline SVG graphic served as HTML, which should be valid, though no browser currently renders inline SVG in HTML. However the HTML5 validator throws numerous errors. There are deep gaps in understanding between web page author and implementors, and among web page authors and implementors, about what is “valid” or “conforming” HTML5. Too deep, and too many to roll out for a production site. Perhaps after Last Call.
*The biggest problem I have with the new HTML5 elements is their names. Prior to HTML5, when we talk about header we were talking about a generic entity, page fragment, or concept. Now, when I mention header in context with HTML5, am I mentioning the element? Or am I referencing the concept? The same applies to section, article, and footer. Sometimes using common names is not the best solution when it comes to designing a new markup language. Still, we’ll have to hope that the context of use will be enough to differentiate between generic concept and specific element.
**Currently, I serve my pages up as application/xhtml+xml, so it’s no problem incorporating RDFa into the content. Contrary to the persistent rumor, XHTML is alive an well in HTML5 (though the encapsulation of XHTML within a document labeled “HTML5” has been caused considerable confusion). However, the RDFa community is currently working on a new draft of RDFa that will allow RDFa annotation in documents served up as plain HTML, too. This is important, because RDFa is incorporated, by default, into Drupal 7, as well as being the format most used for Creative Commons licenses, and some of Google’s new metadata search efforts. In many cases the documents involved are served as HTML, not XHTML. Whatever happens, and by whom, RDFa will exist in HTML5, regardless of whether the document is served as HTML or XHTML, and regardless of whether such use is deemed “conforming” or not.
***I dislike the dialog element. I do not like redefining the behavior for the dt and dd elements based on the container element (dialog or definition list element, dl). I understand about issues associated with redefining definition lists for dialogs, but the state isn’t improved when you redefine the semantics of dd and dt, depending on their container. Nothing is gained.
