Page 1








Was this helpful? Yes No Adobe Developer Connection / Dreamweaver Developer Center /

My Adobe Privacy

My cart Sign in

Understanding HTML5 semantics – Part 1: New elements by Stephanie (Sullivan) Rewis

If your business is like mine, you've been hearing a lot of HTML5 this and HTML5 that lately. Lots of talk about the "Flash killing" video element, animations with canvas, geolocation, and much more. In fact, the buzz around HTML5 has been extended to include things that aren't even HTML5 at all. All over the web, people are talking about the new expressive capabilities of CSS3 while calling them HTML5. Often forgotten in the overwhelming marketing buzz of HTML5 are the new elements introduced and other semantic changes. In this article, I'd like to help you understand and learn to properly use these not-necessarilyexciting, yet definitely very important new, semantic elements. While the subject may seem dry and boring, there's actually a new richness you can add to your markup with the proper use of these new elements.

Thinking in sections

W3Conversions Content Thinking in sections

Why do we have new elements anyway? Did we need them? Where did they come from?

Sectioning elements Related elements Older browsers, newer elements Where to go from here

Think about your code. Do you ever use <div id="nav">, <div class="header">, or <div id="footer"> ? That's exactly where these new elements came from. Millions (maybe billions) of web pages were spidered and the common class names were compiled. You can imagine, after seeing "div class=header" for the umpteenth time, as an analyst, you pretty much knew you were on to something.

Created 1 August 2011 Comments (0) Page tools

In fact, the above listed classes and IDs are three of the most obvious elements—header, nav, footer. And they make sense to most of us. Where it gets trickier, is adding article, section, and what in the world is an aside? More importantly, where do they go on the page? I won't discuss them all in this article, but some of the new elements introduced with HTML5 are (bearing in mind that a couple are still popping in and out of the spec):

Share on Facebook Share on Twitter Share on LinkedIn Bookmark





























Print Dreamweaver website


One of the first challenges when you receive the content for a website, is deciding which of the new elements are appropriate to use and where they should go (see Figure 1).

Figure 1. First you need to decide on the elements you want.

Most pages will have a header at the top, footer at the bottom, perhaps a nav just under (or inside) the header or maybe in a side column. But thinking in these terms is sooooo HTML4/XHTML. In other words, along with the new elements themselves, the HTML5 working group intended for our page content to be marked up according to what the content is. You shouldn't be thinking in terms of "where" the content exists on the page, but rather what relationship does this content have with other page content. And going even further, what is a particular piece of content's role in the page, section, and so on. These elements can be nested within each other. In fact, a header might find itself in a nav or a footer in an article. But before your mind resembles a markup contortionist, let's talk about the elements themselves. Four of the new elements are called sectioning elements. These are rather like new Lego pieces that snap in with the divs you currently use (and you absolutely will continue to use divs). They are article, aside, nav, and section.

The outline These sectioning elements create the outline of your page. In HTML4/XHTML, the outline was created implicitly by the heading levels in our markup. Divs had no effect on the page's outline. The result looked something like the outline for a term or research paper. Wikipedia shows an outline for every articleâ&#x20AC;&#x201D;and yes, it's based on their heading levels (see Figure 2). Each article begins with an H1, progresses to top-level H2 headings with nested H3, H4, and so on. The result is an implicit outline they place in the page to use as navigation. Using headings properly is helpful to people using assistive technology since they can request a list of your headings and then jump to the logical place on the page.

Figure 2. Wikipedia shows an outline for every article for ease of navigation.

With HTML5, the outline is created explicitly. Instead of headings, you have sectioning elements to create the sections of our document. These elements create the document's table of contents properly, regardless of the heading level it begins with. Sectioning elements can start with H1, but no matter what heading level a section begins with, the hierarchy descends from there. Using an H1 to begin each sectioning element is perfectly acceptable. It allows for logical organization so that chunks of code can be pulled from a CMS and used anywhere in a site while still retaining their proper semantic structure. For the time being, however—while assistive technology plays catch-up—it is probably best to use elements of the appropriate rank for the section's nesting level. Meaning—create the outline with sectioning elements, but temporarily continue to use the H1, H2, H3 hierarchy to begin those sections. If a portion of your content should not start a new piece of the outline, you should probably be using a div for it.

Sectioning elements <section> The first, and most generic of the four new sectioning elements is section. A section represents a generic section of a document or application. According to the HTML5 documentation: "A section, in this context, is a thematic grouping of content, typically with a heading. Examples of sections would be chapters, the various tabbed pages in a tabbed dialog box, or the numbered sections of a thesis. A Web site's home page could be split into sections for an introduction, news items, and contact information." Remember, when an element is being used simply for styling purposes or as a convenience for scripting, a div should still be used. The section element is not that generic. It is defining a portion of your page that should create a new section of the outline of the page. As mentioned above, a site's home page—in an effort to lure the user into the different portions of content within the site—is a very common place to find several section elements. Informational pages may also contain several sections within. The code might be marked up like this:

<article> <hgroup> <h1>British Virgin Islands</h1> <h2>A bareboat charter wonderland!</h2> </hgroup> <p>Want to go sailing on your vacation? Among these Caribbean jewels, there are options for both beginners and experienced charterers…</p>

<section> <h1>Virgin Gorda</h1> <p>The Baths at Virgin Gorda are truly one of the most picturesque places in the Caribbean.<p> </section> <section> <h1>Norman Island</h1> <p>Whether it's snorkeling at the Indians or drinks and night life at Willy T's floating restaurant, the Bight on Norman Island gives you a full range of choices…</p> </section> <section> <h1>Jost Van Dyke</h1> <p>This small island contains several great evening activities including the Soggy Dollar Bar and Sidney's Restaurant…</p> </section> </article>

<article> There's been much debate on the web about the use of the article element. Originally the spec seemed a bit nebulous and confusing to some. With further clarification over time, the element has been defined as: "An article element represents a self-contained composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content." The confusion may partly stem from the use of the term article itself since that's typically what is called a type of writing you might find in a magazine, newpaper, or blog. But don't be thrown by the "in syndication" bit. This does not mean that an article only applies to a blog post or news article that is actually syndicated. It means that this article of content could stand alone if needed and you would have all the information you need to understand what it was and where it came from. One of the dictionary definitions of article is "an individual object, member, or portion of a class; an item or particular: an article of food; articles of clothing." So changing your thinking from the publishing industry's use of article to a more simple understanding of "complete object" or item might be the first step in providing some clarity. And now, of course, let me use a blog post as an example. I'm not trying to confuse what I just said in your mind, but there are some other things, which apply in this situation, and of course—an article is appropriate for a blog post. Remember the spec said that a "user-submitted comment" is also an article. There has been much argument about the validity of marking up a comment in that way. But a comment marked up as an article will be nested in its original article. It is not placed after the closing tag of the article it is commenting on. So it is seen semantically as an item relating to the original item it is placed within. That said, a comment typically is self-contained. It has the identifying information for the person posting it—a name and possibly an avatar; a time/date stamp; and their full comment. It could stand alone and be identified with who wrote it and when.

<article> <header> <h1>Anchoring isn't for beginners</h1> <p><time pubdate datetime="2009-10-09T14:28-08:00"></time></p> </header> <p>If you've ever chartered a 45ft catamaran, you know that mooring balls are your friends. They protect the coral and sea bottom from the constant abuse of frequently anchoring boats.</p> <p>...</p> <section>

<h1>Comments</h1> <article> <footer> <p>Posted by: Peg Leg Patooty</p> <p><time pubdate datetime="2009-10-10T19:10-08:00"></time></p> </footer> <p>Right! Mooring balls are for wusses! Pirates only use anchors! Arrrrr!</p> </article> <article> <footer> <p>Posted by: Ariel</p> <p><time pubdate datetime="2009-10-10T19:15-08:00"></time></p> </footer> <p>Thank you for thinking of what's under the sea. Even Ursula would be thrilled.</p> </article> </section> </article>

Note that both the blog post (the parent article) and the comments (the child articles) are marked up with the new time element. According to the spec: "This element is intended as a way to encode modern dates and times in a machine-readable way so that, for example, user agents can offer to add birthday reminders or scheduled events to the user's calendar." Note the term machine-readable. It's becoming more and more useful to have data marked up so that machines are able to parse it and give you the ability to automatically use the data in your own programs or to create mashups for a variety of uses. This is one reason semantics are important. When machines understand the meaning of dataâ&#x20AC;&#x201D;and this includes search enginesâ&#x20AC;&#x201D;the data becomes much more rich and functional. You may also have noticed the Boolean attribute pubdate on the time element. According to the spec, this attribute "indicates that the date and time given by the element is the publication date and time of the nearest ancestor article element, or, if the element has no ancestor article element, of the document as a whole." To clarify, this indicates to machines parsing your data that this time element is the actual publication date of the comment or article. If you are using pubdate on the time element in the global footer of your page, that would indicate it is the publication date and time of the web page itself. On to the final two sectioning elements ... <nav> The third sectioning element relates to navigation of your site and its pages: "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. . . . the element is primarily intended for sections that consist of major navigation blocks." It's quite common in modern web markup to have a group of links to the main areas of the site (perhaps with drop-down choices), a group of links within a section of the site, and possibly a group of links that help you navigate through some pagination if the page is split into multiples. You may also have a group of links to other sites you recommend (a blogroll), a group of resource links on a specific subject and even a repeat of top-level links within the footer of your page (so users can avoid scrolling back up to the top to choose their next destination). The first set would be considered "major navigation" groups. They're all groups of links that a user needs to navigate the site, or a section of the site. They are groups you would want a user using assistive technology to be able to skip straight over (to get to the content first) or skip straight to when wanting to navigate

somewhere else. The second group should be carefully considered before deciding to mark them up as major navigation. Any group of links that link away from your site should probably not be marked up as nav—it depends on the intent of the links. If it is a group of links to sign up for events for your company, and they all link to Eventbrite, I would consider them navigation related to your site. But a list of links that you'd like to suggest as something they may also enjoy, like a blogroll probably isn't. It is not necessary to mark up the repetition of some of your site's navigation in the footer as a nav element. But it's not wrong either. Be aware that the nav element can contain a variety of styles of navigation—not just unordered lists. While unordered lists or P elements are certainly most common, you could also write your navigation as a block of poetry or prose. It's perfectly acceptable as long as the intention of the element is for the user to navigate. A quote from Ian Hickson (Chairman of the WHATWG) himself: "Don't use <nav> unless you think <section> would also be appropriate, with an <h1>Navigation</h1>." <aside> And finally, the last sectioning element—the aside. Clearly the name of this element grew from the section of the page people were calling sidebar, aside, or sidepanel. The "side" portion of those words actually represented where it was visually in the page. But the aside isn't meant to mirror that intent. Here's what the spec 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." Tangentially related? That simply means slightly related. When deciding whether content should be marked up as an aside, ask yourself a couple questions: Can it be considered separate from that content? Can you remove it without affecting the meaning of the document or section? While you certainly can use it to hold groups of navigation and advertising—whether they're on the side of the page or not—you can also use it directly inside a section or article it relates to. For instance, a magazinestyle pull quote might be marked up like this:

[quote] <p>If you've ever chartered a 45ft catamaran, you know that mooring balls are your friends. They protect the coral and sea bottom from the constant abuse of frequently anchoring boats. They're also one of the easiest ways to secure yourself while at sea avoiding the dreaded "anchor watch" that can keep you awake half the night.</p> <aside> <q>Mooring balls protect the coral and sea bottom from constant abuse…</q> </aside> <p>Learning mooring techniques isn't overly difficult. Communication is key between the person grabbing the ball with the hook and the sailor at the helm.</p> [/quote]

The pull quote could be removed without harming the article since it's merely repeating a quote from the article with special typography. You should not use an aside for parentheticals that should remain within the article. If it affects the article (or section) when removed, it's probably not an aside. Remember, in the case of all these new sectioning elements—don't stress! They've been created to give us new elements that are more descriptive of our content than a div can be. Try to be logical and look at intent. Mark up your site without looking at where things will go, but at what they are and how they relate to each

other. And then, let it go …

Related elements There are a few elements that are closely related to the elements I've just discussed but that don't create a new section of the outline. The two most important are header and footer. <header> A header element, while it could find itself at the top of the page, is really more about identifying the importance of the content within it. (Don't confuse <header> with the <head> of your document or the heading elements— h1 , h2 , h3 , etc.) The spec says: "A header represents a group of introductory or navigational aids. A header element is intended to usually contain the section's heading (an h1–h6 element or an hgroup element), but this is not required. The header element can also be used to wrap a section's table of contents, a search form, or any relevant logos." You are allowed more than one header on a page. Your page will generally have one global header, but you may find the need for a header in one of the sectioning elements as well. Just remember, though a sectioning element will always have a heading element, it may simply be an h1 – h6 , possibly in an hgroup where appropriate. <hgroup> There's a new element called hgroup that has been in, and out, of the spec. Where it ends up remains to be seen at this point, but the hgroup element was created simply to be a wrapper (or shield) when there are two headings directly following one another, but only the first one should be included in the documents explicit outline. Consider a site name and tag line:

<hgroup> <h1>The British Virgin Islands</h1> <h2>Jewels in the Caribbean</h2> </hgroup>

In the outline of the document, the h1 element would appear, but the h2 would be shielded from the outline. <footer> As with header, you can have more than one footer element in a page. You'll likely have one global footer, but sectioning elements can also have footers. The spec says this: "The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like. When the footer element contains entire sections, they represent appendixes, indexes, long colophons, verbose license agreements, and other such content." When you're marking up a blog post, you may have information such as who wrote it and when it was written at both the top and bottom of the post. If you place that information in a footer, which is clearly appropriate, you'll want to use a footer each time. You would not place the information in a header at the top and a footer at the bottom. It is the same information, so it should be contained in the same element if it's duplicated. <address> Though not new, I'd like to mention the address element since it's likely to be used more with the new semantic elements. Don't be confused. The address element is not for your home, office, or business postal address. It's actually described like this:

"The address element represents the contact information for its nearest article or body element ancestor. If that is the body element, then the contact information applies to the document as a whole." This typically means an email address or a link to a web page about the author. Usually placed in a footer. If it's in the global footer, it relates to the whole page. If it's in the footer of an article, it relates only to that article. A postal address would only be used if it was, in fact, the contact information for that article. <figure> and <figcaption> The final element we'll look at is the figure element: "â&#x20AC;Ś optionally with a caption, that is self-contained and is typically referenced as a single unit from the main flow of the document. The element can thus be used to annotate illustrations, diagrams, photos, code listings, etc, that are referred to from the main content of the document, but that could, without affecting the flow of the document, be moved away from that primary content, e.g. to the side of the page, to dedicated pages, or to an appendix." The mistake many people make is in believing that their images should all be wrapped up in figures. In reality, the figure element should be thought of rather like an illustration in a book. It may or may not be a photograph. And it may or may not have a captionâ&#x20AC;&#x201D;depending on where it is in the flow of the content. It would be a perfectly logical use for a code sample or illustration for a tutorial on the web. If the figure element contains a caption (the figcaption element), it is within the parent figure element (see Figure 3).

<figure> <img src="virgin-gorda.jpg" alt="The boat as seen through the rocks at the Baths on Virgin Gorda."> <figcaption>The Baths at Virgin Gorda</figcaption> </figure>

Figure 3. The caption is within the parent figure element.

Older browsers, newer elements Modern browsers have no problem styling most of the new HTML5 elements. However, older browsers need a little hand holding. If you have the HTML5 pack installed in Dreamweaver (or you have CS5.5), you can open one of the new HTML5 layouts it now contains. 1. Go to File > New > Blank Page > HTML > HTML5: 3 column fixed, header and footer. 2. Make sure you've selected an HTML5 doctype and Click Create (see Figure 4).

Figure 4. Dreamweaver includes two new HTML5 starter templates.

At the end of the CSS (whether you've attached it or left it in the head of the document), you'll see this comment and selector:

/*HTML 5 support - Sets new HTML 5 tags to display:block so browsers know how to render the tags properly. */ header, section, footer, aside, nav, article, figure { display: block; }

Setting the display property to block causes older modern browsers to render the elements correctly. However, for older versions of Internet Explorer (IE), we'll need training wheels (that is versions earlier than IE9). IE won't recognize the elements unless they're injected into the DOM with JavaScript. It will properly render everything it recognizes, but leave the things it doesn't alone. This can cause an ugly mess. Note the following comment right at the close of the <head> element of the page:

<!--[if lt IE 9]> <script src=""></script> <![endif]-->

That link is in an IE conditional comment (a comment that only IE reads) for any version earlier than IE9. It

links to the tiny JavaScript file that makes IE behave. Have a look at the way this page is structured and at the new elements themselves. If you use the HTML5 templates in production, be sure to move the elements into their proper places for your site's semantic structure. If your asides do not map to sidebars and other large structural discrepancies, you might be better served to create a new, blank HTML5 page within Dreamweaver and use the powerful code hinting and code completion to create your custom page structure.

Where to go from here Remember, if your head is spinning with all these new elements and semantics—keep it simple. Content should simply be marked up based on what it is, not where it is. Think of your intent with that piece of content and what element best reflects it. And it's really okay to use a div when it's the most appropriate element. In Understanding HTML5 semantics – Part 2, I look at the differences between HTML4 (or XHTML—the terms are used interchangeably in this article) and the HTML5 document structure, including the addition of new global attributes. In Understanding HTML5 semantics – Part 3, I discuss some of the changes to older elements: some are obsolete, some have changed in semantic meaning, and a few have been reintroduced. To start using HTML5 and CSS3, see David Powers's three-part tutorial series, HTML5 and CSS3 in Dreamweaver CS5.5. To learn more about HTML5, CSS3 and the new related geolocation, storage and other APIs, refer to resources in the HTML5 Developer Center.

+ This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. Permissions beyond the scope of this license, pertaining to the examples of code included within this work are available at Adobe. More Like This What's new in Dreamweaver CS5.5 Introduction to media queries – Part 1: What are media queries? Turning a design into HTML and CSS using the Fireworks to Dreamweaver workflow – Part 1: Exporting the design Turning a design into HTML and CSS using the Fireworks to Dreamweaver workflow – Part 2: Modifying the HTML and CSS Styling and inserting a Spry Menu Bar 2.0 widget with the Adobe Widget Browser Simple styling with CSS Code editing in Dreamweaver From table-based to tableless web design with CSS – Part 1: CSS Basics Best practices with CSS in Dreamweaver CS4 Taking a Fireworks comp to a CSS-based layout in Dreamweaver – Part 1: Initial design

Tutorials and samples Tutorials Creating your Creating your Creating your Creating your

first first first first

website – Part website – Part website – Part website – Part

5 6 3 2

Samples Responsive design with jQuery marquee Customizable starter design for jQuery

Mobile Customizable starter design for HTML5 video Customizable starter design for multiscreen development Comments (0)


Comments are currently closed as we migrate to a new commenting system. In the interim, please provide any feedback using our feedback form. Thank you for your patience.

Products Acrobat Creative Cloud Creative Suite Digital Publishing Suite Elements Adobe Marketing Cloud Mobile Apps Photoshop Touch Apps Student and Teacher Editions

Solutions Digital marketing Digital media

Help Product help centers Orders and returns

Ways to buy For personal and home office

Company News room Partner programs

Web Experience Management

Downloading and installing My Adobe

For students, educators, and staff

Corporate social responsibility Career opportunities

Learning Adobe Developer Connection

For businesses, schools, and government

Industries Education Financial services Government

Choose your region Copyright Š 2013 Adobe Systems Incorporated. All rights reserved. Terms of Use | Privacy | Cookies Ad Choices

Adobe TV Training and certification Forums Design Center

For small and medium businesses

Special offers

Investor Relations Events Legal Security Contact Adobe

Downloads Adobe Reader Adobe Flash Player Adobe AIR Adobe Shockwave Player

HTML5 Sematics 1 - New Elements  

HTML5 Intro

HTML5 Sematics 1 - New Elements  

HTML5 Intro