Here we are again with another round of patient questions about HTML5. In this article, we’ll be covering AJAX, the eternal question of <div> or <section>, our old friend Internet Explorer, how to mark up multiple blocks of content in a sidebar, and using <header> with <hgroup>.

HTML and AJAX

Arie asked:

I’m still learning about html5 and javascript, I’m wondering how html5 makes doing a lot of the things currently done in ajax and javascript more simple. Is it by providing things like the canvas that unify ideas?

Certain parts of HTML5 will indeed simplify or reduce the need for JavaScript. One such area of improvement is Web Forms 2.0, which will handle client-side form validation in the browser and provide new input types (like <input type="email"> that checks for a valid email address). Of course, you’ll still need to validate your forms on the server, but at least the browser will catch the most obvious mistakes before the user actually submits the form.

Other parts of HTML5, like Web SQL Databases and <canvas>, are essentially JavaScript APIs. They may not cut down on your need for JavaScript, but they do provide a consistent interface to some powerful functionality and will enable your application or site to do more things within (or outside of) the browser.

Cheers, Rich

<div> or <section>?

Paul asked:

Hello

I see you are using divs on your website, I thought divs should be replaced by more semantic tags such as sections or article. what did I miss?

Thanks

Hi Paul,

Just like with HTML4, you shouldn’t use <div>s or <span>s where another, more precise element would fit the bill. But for grouping arbitrary content, <div>s and <span>s remain the way to go.

Thanks, Bruce

HTML5 and IE6

Adam asked:

Greetings HTML5 Doctor,

Is it at all possible to have a HTML5 layout while 30% of our users are running IE6? We are an IT company and our website is very large so having separate versions is completely impractical. HTML5 would allow us to move on and keep our markup a lot simpler but with no concrete guarantees regarding universal support is HTML5 ever going to get off the ground within 5 years while not having to resort to javascript solutions?

Simply change the doctype and you’ll be writing HTML5! If you want to use new elements, however, you’ll need to use JavaScript to support them (for all versions of IE up to IE8). The best place to start? Read Remy’s article on How to get HTML5 working in IE and Firefox 2.

I think we’re in a position to do something about this. By using the new doctype, block-level links, and new form input types (that degrade gracefully), we can start promoting HTML5 right now.

Cheers, Rich

Multiple blocks in a sidebar

Bart asked:

On my page (revora.net) I have a sidebar with content that I deem appropriate for the aside element. The sidebar contains several blocks of content. I’ve currently made the whole bar aside and made the blocks div. Is this correct, or should I do it the other way around?

It sounds like your first approach is correct. The <div>s might be <section>s or maybe <nav> elements though, depending on their content. I suggest you read our article (and the comments) on the <aside> element.

Thanks, Tom

Header with <hgroup>

Diego asked:

Hi,

This structure is right?

<section id="choose-tip">
   <header>
       <hgroup>
           <h1>Foo Bar</h1>
           <h2>Baz Bat Qux</h2>
       </hgroup>
   </header>
   <p>lorem ipsum</p>
</section>

What I mean is, if I have a HEADER with just 2 H(n) I need to put these into a HGROUP ? Or… I can remove the HEADER and leave just a HGROUP? What’s the better solutions for it?

Thanks for all,

Diego Tres

What you have is correct. Basically, in the document outline, you will only see “Foo Bar” as the heading for that section. “Baz Bat Qux” will be hidden from the outline.

You don’t have to use a <header> within your <section> or an <hgroup> within your <header>. Similarly, you don’t have to use a <header> around your <hgroup>.

To summarise, the best solution (if you don’t require the <h2> to appear in the document outline) is what you’ve already got.

Cheers, Rich

Got a question for us?

That wraps up this round of questions! If you’ve got a query about the HTML5 spec or how to implement it, you can get in touch with us and we’ll do our best to help.

Share and Save:

Your Questions Answered #7 originally appeared on HTML5 Doctor on April 20, 2010.

In traditional printed material like books and magazines, an image, chart, or code example would be accompanied by a caption. Before now, we didn’t have a way of semantically marking up this sort of content directly in our HTML, instead resorting to CSS class names. HTML5 hopes to solve that problem by introducing the <figure> and <figcaption> elements. Let’s explore!

The <figure> element

The <figure> element is intended to be used in conjunction with the <figcaption> element to mark up diagrams, illustrations, photos, and code examples (among other things). The spec says this about <figure>:

The figure element represents a unit of content, optionally with a caption, that is self-contained, that is typically referenced as a single unit from the main flow of the document, and that can be moved away from the main flow of the document without affecting the document’s meaning.

The <figcaption> element

The <figcaption> element has been the subject of much debate. The spec initially wanted to repurpose <legend> rather than introduce a new element. Other suggestions included <label>, <caption>, <p> or the <h1>–<h6> elements. <legend> was changed, so we then used a combination of <dt> and <dd> inside <figure> at Jeremy’s suggestion. Most of these suggestions failed since there was no backwards compatibility for styling with CSS.

Regular readers will know that a new element was recently introduced, namely <figcaption>. Who knows if it’ll stick, but for now here’s what the spec says about <figcaption>:

The figcaption element represents a caption or legend for a figure.

The <figcaption> element is optional and can appear before or after the content within the <figure>. Only one <figcaption> element may be nested within a <figure>, although the <figure> element itself may contain multiple other child elements (e.g., <img> or <code>).

Using <figure> and <figcaption>

So we’ve seen what the spec says about these elements. How do we use them? Let’s look at some examples.

Figure with an image

An image within a <figure> element without a caption:

Here’s the code for that:

<figure>
  <img src="/orang-utan.jpg" alt="Baby Orang Utan hanging from a rope">
</figure>

Figure with an image and caption

An image within a <figure> element with an explanatory caption:

and the code that we used:

<figure>
  <img src="/macaque.jpg" alt="Macaque in the trees">
  <figcaption>A cheeky macaque, Lower Kintaganban River, Borneo. Original by <a href="http://www.flickr.com/photos/rclark/">Richard Clark</a></figcaption>
</figure>

A figure with multiple images

Nesting multiple images within one <figure> element with a single caption:

The code:

<figure>
  <img src="/kookaburra.jpg" alt="Kooaburra">
  <img src="/pelican.jpg" alt="Pelican stood on the beach">
  <img src="/lorikeet.jpg" alt="Cheeky looking Rainbow Lorikeet">
  <figcaption>Australian Birds. From left to right, Kookburra, Pelican and Rainbow Lorikeet. Originals by <a href="http://www.flickr.com/photos/rclark/">Richard Clark</a></figcaption>
</figure>

Figure with a code block

The <figure> element may also be used for code examples:

Here’s the code for that:

<figure>
<blockquote><p><code>&lt;small&gt;&lt;a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/"&gt;Creative Commons Attribution Share-alike license&lt;/a&gt;&lt;/small&gt;</code></p></blockquote>
<figcaption>Using <code>&lt;small&gt;</code> around a <a href="http://creativecommons.org/choose/" title="Choose a License">Creative Commons license</a> link with <code>rel="license"</code></figcaption>
</figure>

Differences between <figure> and <aside>

We covered <aside> in an earlier article, but it is important to note the difference between the two. You should choose between <aside> or <figure> by asking yourself if the content is essential to understanding the section:

• If the content is simply related and not essential, use <aside>.
• If the content is essential but its position in the flow of content isn’t important, use <figure>.

Having said that, if its position relates to previous and subsequent content, use a more appropriate element — e.g., a <div>, a plain old <img>, a <blockquote>, or possibly even <canvas>, depending on its content.

Don’t stop there!

No need to constrain your <figure>s to images and code examples. Other content suitable for use in <figure> includes audio, video, charts (perhaps using <canvas> or <svg>), poems, or tables of statistics.

It may not always be appropriate to use the <figure> element, though. For example, a graphic banner should not be marked up with <figure>. Instead, simply use the <img> element.

Summary

As we’ve illustrated in this article, there are a lot of possibilities for the <figure> element. Just remember to make sure it’s the most appropriate element for the job. But you already do that for all your markup, right?

The figure & figcaption elements originally appeared on HTML5 Doctor on April 13, 2010.

We’re back with our first roundup of your questions for 2010. In this article, we’ll be covering a range of topics including sections and sectioning, the <img> element, scaling video, and a proposal for a <field> element.

Headers and sidebars

Ad asked:

Hello,

I have 2 questions:

1. If I have my main navigation above the masterhead would best practise be having the nav tag inside of a header tag with the h1 and h2 in a hgroup? Or should the nav and header tag be separate?

2. I am building a blog in HTML5. It has a blog-like sidebar with articles, contact info and about info in it. Would the best tag to wrap this in be section or aside?

Thank you so much for your time,
Ad Taylor

Placing your <nav> within your <header> is fine and valid. However, if it makes more sense to leave it outside, then you can do that too. You don’t need to put the <hgroup> inside the <nav> though.

See our articles on <header> and <nav> for more on this.

Regarding your second question, I would use <aside> (as we’ve done on the HTML5 doctor site) and then use multiple sections within that. Also see Bruce’s article on Designing a blog with HTML5.

Hope that helps.

Cheers, Rich

HTML5 <img> element

Martijn asked:

As you are, according to the slogan, “helping [me] implement HTML5 today,” I thought to bother you people with a spec. related question.

What should an UA do with an image without specified width and height attributes?

The dimension attributes part of the specification keeps stating “if specified” for every rule but doesn’t give any “if not specified”.

The part of the specification defining the img element itself does not state anything of importance about the dimension attributes apart from how the attributes in the DOM should be created by the UA.

Interesting is to note that they have omitted these attributes in all their img element examples.

In the dimension attribute section they go state the following.

– The dimension attributes are not intended to be used to stretch the image.

So we can only use them to make images smaller? This is odd as well so let’s say by stretch they mean to say both expending and shrinking in size. In this case the attributes can only be used for two cases:

1. To state the exact width and height of the image. Something that seems redundant unless not using those attributes means the UA can display the image at any size (which it might, as nothing about this is defined in the spec.).

2. To give a 0 in both attributes. By this I am telling the UA that the image is not to be seen by the user.

Am I missing something or is the specification missing this?

Looking forward to getting your prescription

Kind Regards, Martijn

If no dimension attributes are specified, the browser will leave no space for the image, and once the image has been loaded (after the rest of the page), it will then need to reflow the entire page, as that’s the first time it knows the size of the image. This can cause the content you’re reading scrolling off the page.

If you give the size of the image as attributes in the HTML, the browser will leave space and render the image there once it’s loaded without reflowing the page. On a mobile phone, reflowing the page unnecessarily drains the battery, and users can get vertigo from the page’s text jumping around to accommodate images.

Thanks, Bruce

Section and Sectioning

Yanoo asked:

Hi,

What do you mean when you are talking about “sectioning”? And why don’t header and footer require sectioning?

I think about section and sectioning like about part of something defined. News, comment, page content, sidebar, *header*, and *footer*. Is it bad representation?

Sectioning relates to the headings in some block of related content and defining what is related to what in a hierarchy of headings (<h1>–<h6>). The outlining algorithm can produce a table of contents from the nested <section>, <article>, <nav>, and <aside> elements.

Headers and footers themselves do not change the outline; a header or footer may contain no headings. If a header or footer does contain a heading, then that heading does come into the outline. See our article on the section element.

Thanks, Bruce

Scaling the Video

Ian asked:

Hi there,

Not sure if this question is an appropriate one, but any help would be really appreciated.

I’m going about updating my video website, chutney.ie, and would love to implement HTML5. I am interested in replicating the scaling effect/style used on the Mozilla welcome page.

Not being overly knowledgeable in this area, I would love to know how to begin — is this effect a Flash based animation, or something that can be achieved with HTML alone?

Again, any nudge in the right direction would be great.

Many thanks,

Ian

I’m not sure how Mozilla did it, but you can use some of the Webkit and Mozilla transforms on the <video> element. For example, you can cause the video to grow on hover — see this example in Chrome, Safari, or Opera. You can also use the :target pseudoclass to initiate animations. Alternatively, you can use a JavaScript onClick event to create the same effect.

You can also combine <video> and <canvas> to provide some interesting results (laying the <canvas> over the <video>). For more on the <video> element and what it can do, please read the Introduction to HTML5 Video on dev Opera written by Bruce Lawson and Patrick Lauke.

Cheers, Rich

We need a <field> tag

John wrote in and proposed a field element:

Hey there. First off thanks for the site. I was excited to find it. I spent a little time on the W3C site and honestly couldn’t figure out how to submit suggestions there. So going to submit mine to you guys and maybe you can pass it on (if it is good) or point me to someone that can help. Ok to the point:

We are getting nice new tags to with HTML5 (nav, footer, etc) to help us create more semantic code. I think what we really need is a field tag — after all what are fieldsets sets of?

Everyone wraps up their labels and inputs with some element. Some of us do this with UL, some people do it with DT/DD, some with DIVs and some people out there insist that a form is tabular data.

We are all just bastardizing these elements because there is no clear semantic wrapper for field elements of a form.

I think you get the point. I’m trying to keep this email short. If you think there is anything to this argument, I have a more detailed summary (with example code) at:

http://john.mirick.me/2009/10/what-is-really-set-of-shouldnt-we-have.html

I would love to hear your thoughts on this.

Thanks!
John

While a field element would be nice — it would stop the argument over how best to mark-up forms — you have to ask yourself whether or not it actually adds any semantic or functional value to an HTML document. Yes, wrapping inputs and their labels in a field would make things easier to read and drop the need for the for attribute on the label (since the relationship can be assumed), but doing so would not be backwards compatible. In theory, we could continue to add for until there is a suitable time to drop it, but again I question the value of such a tag.

The purpose of wrapping form input/label pairs is generally to ease styling. My personal stance is that unless there are case studies showing how such an element can add more value to HTML forms, this proposal won’t make it very far.

Regards, Mike

Got a question for us?

That wraps up this round of questions. If you’ve got a query about the HTML5 spec or how to implement it, you can get in touch with us and we’ll do our best to help.

Share and Save:

Your Questions Answered #5 originally appeared on HTML5 Doctor on March 2, 2010.

Since the HTML5 specification is not yet final, we can expect changes to improve on the good bits and cut out the bad bits. aside — a misunderstood good bit — has now been tweaked based on feedback from the web development community. In this article, we’ll take a look at what’s changed.

Aside redefined

When we previously discussed aside in “Understanding Aside“, its definition suggested that it should be used for content tangentially related to the content surrounding it, such as related reading links and glossaries. It did not appear to be an appropriate element for holding secondary content related to the site as a whole, typically known as a “sidebar”.

From the comments here and elsewhere, you can see this definition was not accepted by developers. The spec writers listened, and aside is now acceptable for secondary content when not nested within an article element.

Examples of aside in two different contexts

With the new definition of aside, it’s crucial to remain aware of its context. When used within an article element, the contents should be specifically related to that article (e.g., a glossary). When used outside of an article element, the contents 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).

The two uses of aside can be best illustrated with an example:

<body>
  <header>
    <h1>My Blog</h1>
  </header>
  <article>
    <h1>My Blog Post</h1>
    <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
    eiusmod tempor incididunt ut labore et dolore magna aliqua.</p>
    <aside>
      <!-- Since this aside is contained within an article, a parser
      should understand that the content of this aside is directly related
      to the article itself. -->
      <h1>Glossary</h1>
      <dl>
        <dt>Lorem</dt>
        <dd>ipsum dolor sit amet</dd>
      </dl>
    </aside>
  </article>
  <aside>
    <!-- This aside is outside of the article. Its content is related
    to the page, but not as closely related to the above article -->
    <h2>Blogroll</h2>
    <ul>
      <li><a href="#">My Friend</a></li>
      <li><a href="#">My Other Friend</a></li>
      <li><a href="#">My Best Friend</a></li>
    </ul>
  </aside>
</body>

Conclusion

The aside element can now represent secondary content when used outside of an article. Keep in mind that aside — and, more generally, secondary content — does not necessarily mean “sidebar”. The style of the content should not dictate the use of the element. For content that is not the primary focus of an article (or page) but is still related to the article (or page), aside is what you need, regardless of its visual design.

Share and Save:

Aside Revisited originally appeared on HTML5 Doctor on October 28, 2009.

Much of HTML 5’s feature set involves JavaScript APIs that make it easier to develop interactive web pages but there are a slew of new elements that allow you extra semantics in your conventional Web 1.0 pages. In order to investigate these, let’s look at marking up a blog.

Firstly what we’ll do is use the header, footer, and nav elements to mark up the broad structure of the page. We’ll make the blog comments form much smarter by using the new data types and built-in validation available in HTML 5-aware browsers.

Then we’ll do some work on the guts of the page, using HTML 5’s article elements to better mark up blog posts and comments and show how to use the section elements to better structure accessible hierarchical headings on sites that are CMS-driven. As blogs are chronologically ordered, we’ll see what HTML 5 offers us for representing dates and times.

So take the phone of the hook, and make a cup of tea and we’ll get started.

header, footer, nav, article {display:block;}

Further refining the HTML 5 structure

The blog home page

An interesting thing about a blog homepage is that there are generally the last 5 or so posts, each with a heading, a "body" and data about the post (time, who wrote it, how many comments etc.) and usually a link to another page that has the full blog post (if the homepage just showed an excerpt) and its comments.

HTML 5 has an article element which I use to wrap each story:

The article element represents a section of a page that consists of a composition that forms an independent part of a document, page, or site. This could be a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, or any other independent item of content.

Let’s look in more detail at the guts of how I mark up each blogpost.

Anatomy of a blog post

The wrapper is no longer a generic div but an article. Within that is a header, comprising a heading (the title of the blogpost) and then the time of publication, marked up using the time element.

Then there are the pearls of wit and wisdom that consitute each of my posts, marked up as paragraphs, blockquotes etc., and is pulled unchanged out of the database. Following that is data about the blog post (category, how many comments) marked up as a footer and, in the case of pages that show a single blogpost, there are comments expressing undying admiration and love. Finally, there may be navigation from one article to the next.

Data about the article

Following the content there is some “metadata” about the post: what category it’s in, how many comments there are. I’ve marked this up as footer. I previously used aside which “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” but decided that it was too much of a stretch; data about a post is intimately related.

footer is a much better fit: “A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.” I was initially thrown off-course by the presentational name of the element; my use here isn’t at the bottom of the page, or even at the bottom of the article, but it certainly seems to fit the bill – it’s information about its section, containing author name, links to related documents (comments) and the like. There’s no reason that you can’t have more than one footer on page; the spec’s description says "the footer element represents a footer for the section it applies to" and a page may have any number of sections. The spec also says "Footers don’t necessarily have to appear at the end of a section, though they usually do."

Comments

I’ve marked up comments as articles, too, as the spec says that an article could be “a user-submitted comment”, but nested these inside the parent article. The spec says

When article elements are nested, the inner article elements represent articles that are in principle related to the contents of the outer article. For instance, a Web log entry on a site that accepts user-submitted comments could represent the comments as article elements nested within the article element for the Web log entry.

These are headed with the date and the time of the comment and name of its author—if you want, you can wrap these in a header, too, but to me it seems like markup for the sake of it.

Times and dates

Most blogs, news sites and the like provide dates of article publication.

Microformats people, the most vocal advocates of marking up dates and times, believe that computer-formatted dates are best for people: their wiki says “the ISO8601 YYYY-MM-DD format for dates is the best choice that is the most accurately readable for the most people worldwide, and thus the most accessible as well”. I don’t agree (and neither do candidates in my vox pop of non-geeks, my wife, brother and parents).

I do agree with the microformats people that hidden metadata is not as good as visible, human-readable data and therefore elected not to use the pubdate attribute of article.

Therefore I’ve used the HTML 5 time element to give a machine parsable date to computers, while giving people a human-readable date. Blog posts get the date, while comments get the date and time.

The spec is quite hard to understand, in my opinion, but the format you use is 2004-02-28T15:19:21+00:00, where T separates the date and the time, and the + (or a -) is the offset from UTC. Dates on their own don’t need a timezone; full datetimes do. Oddly, the spec suggests that if you use a time without a date, you don’t need a timezone either.

There’s considerable controversy over the time element at the moment. Recently one of the inner circle, Henri Sivonen, wrote that it’s for marking up future events only and not for timestamping blogs or news items: “The expected use cases of hCalendar are mainly transferring future event entries from a Web page into an application like iCal." This seems very silly to me; if there is a time element, why not allow me to mark up any time or date?

The spec for time does not mention the future event-only restriction: "The time element represents a precise date and/or a time in the proleptic Gregorian calendar" and gives three examples, two of which are about the past and none of which are "future events". Although the spec doesn’t (currently) limit use of the element, it does limit format to precise dates in "the proleptic Gregorian calendar". This means I can mark up an archive page for "all blog posts today" using time, but not "all July 2008 posts" as that’s not a full YYYY-MM-DD date. Neither can you mark up precise, but ancient dates, so the date of Julius Ceasar’s assassination, 15 March 44 BC is not compatible.

I don’t expect this to be resolved. If you think as I do, feel free to mail the Working Group to express your feeling!

Hopefully, this brief article (geddit?) has given you a quick overview of how to use some of the new semantic elements. Let me know what you think!

Related Posts:

• Aside Revisited
• Native Drag and Drop
• The time element (and microformats)
• The section element
• Draw attention with mark

Share and Save:

Designing a blog with html5 originally appeared on HTML5 Doctor on June 30, 2009.

]]> http://html5doctor.com/designing-a-blog-with-html5/feed/ 140 http://html5doctor.com/understanding-aside/ http://html5doctor.com/understanding-aside/#comments Fri, 19 Jun 2009 13:00:21 +0000 Mike Robinson http://html5doctor.com/?p=154

HTML 5 offers a new element to mark additional information that can enhance an article but isn’t necessarily key to understanding it. However, in the interpretation of <aside> there lies confusion as to how it can be used, and with that there is demand for the Doctor to step up and clear the air. In this article I will look at what <aside> was created for, including sample uses and how not to use this useful, misunderstood element.

First, a look at how the HTML 5 specification defines <aside>:

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.

What can often trip-up someone reading the specification is the use of the word “sidebar”. I will go into detail about this later in the article, for now you should be aware that what is said there might not quite mean what you first think. Content within an <aside> should be stand-alone information that is related to the article in context. If your <aside> content meets this requirement, then you have a useful element to not only semantically wrap that content but to even hook CSS styles on.

How strict should this relationship be? Very. Good <aside> content examples include pull-quotes, a glossary or even related links.

Example Uses

As suggested in the specification, a pull-quote is an excellent example of a piece of content that is separate from the main article body but still related. Points of interest highlighted.

<article>
    <header>
        <h1>Lorem Ipsum Dolor Sit Amets</h1>
    </header>
    <p>Aliquam erat volutpat. Vestibulum eleifend pellentesque urna, at
    sodales est faucibus sit amet. Praesent in mi dui. <q>Aliquam sed
    bibendum nisl. Mauris pharetra enim sit amet ipsum dictum placerat. Sed
    lacinia pulvinar iaculis. Nam sit amet hendrerit purus.</q> Sed a urna
    laoreet lorem pulvinar fermentum. Aenean vel luctus libero. Ut tincidunt
    metus sagittis ante viverra feugiat.</p>
    <aside>
        <q>Mauris pharetra enim sit amet ipsum dictum placerat.</q>
    </aside>
    <p>Nulla quis lacus non quam luctus vestibulum. Pellentesque imperdiet
    risus gravida ante consectetur fermentum. Vivamus et est nec risus volutpat
    elementum. Ut faucibus, lectus consectetur volutpat dapibus, quam diam
    luctus enim, vitae mollis enim purus non ante.</p>
</article>

For more about the <header> element see Richard’s article, “The <header> Element.

On a styled web page or, more common, in a printed article this would be represented visually as a highlighted quote to the side of the main article. This <aside> is related to the content but does not need to be part of the article body as it can be understood without the extra information, or in this case without the duplicate quote.

Another example would be a glossary of terminologies used in an article:

<article>
    <header>
        <h1>Web Technologies</h1>
    </header>
    <p>Curabitur dignissim lorem a CSS diam posuere tempor. Nam hendrerit,
    eros vel condimentum tempor, ipsum justo cursus justo, quis vestibulum
    turpis turpis sit amet tellus. Quisque quis PHP magna eget ipsum faucibus
    bibendum at non diam. Sed sapien est, cursus ac ullamcorper id, egestas vel
    urna JavaScript. Nullam aliquam dolor vitae quam pharetra auctor.</p>
    <aside>
        <dl>
            <dt>CSS</dt>
            <dd>A set of standards for styling documents presented on the
            World Wide Web.</dd>
            <dt>PHP</dt>
            <dd>A server-side scripting language suited to dynamic HTML document
            generation for the web.</dd>
            <dt>JavaScript</dt>
            <dd>A client-side scripting language used for manipulating HTML documents
            within a browser.</dd>
        </dl>
    </aside>
</article>

Incorrect use of <aside>

It is easy to confuse this element for something it isn’t, and as mentioned earlier the definition of <aside> can trip-up a few developers. The most common misconception of how this element should be used is for the standard sidebar. While there is usually a degree of relation between sidebar content and the content in an article, it is not enough to be considered fit for an <aside>. Navigation, ads, search boxes, blogrolls and so on are not directly related to the article and therefore do not justify the use of an <aside>.

In the definition of <aside> it is key to note that it refers to sidebars in printed media, such as a magazine or leaflet. A “sidebar” in a magazine might contain additional notes on the article in context, translating this to HTML 5 would consider this an <aside>. If the printed article on PHP had an ad for “Superior, Cheap, Web Hosting” as a sidebar, this would not be classified as an <aside>. In such cases, look at other elements for more semantic mark-up.

Closing Thoughts

Like any HTML element, when used correctly the <aside> element can be very useful in semantically marking-up page content. An <aside> can be used to enhance an article with additional information, or highlighting parts that the reader may find interesting. Asides are stand-alone, non-essential as part of an article but when used correctly it can be an extra level of information for your content. Don’t try to force content into an <aside>, if it’s not tangentially related to the article then it shouldn’t be there. HTML 5 offers many new elements to mark-up your web pages, use them wisely.

Related Posts:

• Aside Revisited
• You can still use div
• The hgroup element
• The dl element
• Semantic navigation with the nav element

Share and Save:

Understanding aside originally appeared on HTML5 Doctor on June 19, 2009.

]]> http://html5doctor.com/understanding-aside/feed/ 57