HTML5 Doctor » nav http://html5doctor.com helping you implement HTML5 today Wed, 01 Feb 2012 09:28:11 +0000 en hourly 1 http://wordpress.org/?v= Avoiding common HTML5 mistakes http://html5doctor.com/avoiding-common-html5-mistakes/ http://html5doctor.com/avoiding-common-html5-mistakes/#comments Tue, 26 Jul 2011 13:38:05 +0000 Richard Clark http://html5doctor.com/?p=3494 Between curating sites for the HTML5 gallery and answering readers’ questions here at HTML5 Doctor, I see a host of HTML5 sites and their underlying markup. In this post, I’ll show you some of the mistakes and poor markup practices I often see and explain how to avoid them.

]]> Between curating sites for the HTML5 gallery and answering readers’ questions here at HTML5 Doctor, I see a host of HTML5 sites and their underlying markup. In this post, I’ll show you some of the mistakes and poor markup practices I often see and explain how to avoid them.

Don’t use section as a wrapper for styling

One of the most common problems I see in people’s markup is the arbitrary replacement of <div>s with HTML5 sectioning elements — specifically, replacing wrapper <div>s (used for styling) with <section>s. In XHTML or HTML4, I would see something like this:

<!-- HTML 4-style code -->
<div id="wrapper">
  <div id="header">  
    <h1>My super duper page</h1>
    <!-- Header content -->
  </div>
  <div id="main">
    <!-- Page content -->
  </div>
  <div id="secondary">
    <!-- Secondary content -->
  </div>
  <div id="footer">
    <!-- Footer content -->
  </div>
</div>

Now, I’m instead seeing this:

<!-- Don’t copy this code! It’s wrong! -->
<section id="wrapper">
  <header>  
    <h1>My super duper page</h1>
    <!-- Header content -->
  </header>
  <section id="main">
    <!-- Page content -->
  </section>
  <section id="secondary">
    <!-- Secondary content -->
  </section>
  <footer>
    <!-- Footer content -->
  </footer>
</section>

Frankly, that’s just wrong: <section> is not a wrapper. The <section> element denotes a semantic section of your content to help construct a document outline. It should contain a heading. If you’re looking for a page wrapper element (for any flavour of HTML or XHTML), consider applying styles directly to the <body> element as described by Kroc Camen. If you still need an additional element for styling, use a <div>. As Dr Mike explains, div isn’t dead, and if there’s nothing else more appropriate, it’s probably where you really want to apply your CSS.

With that in mind, here’s the correct way to mark up the above example using HTML5 and a couple of ARIA roles. (Note: you may need one <div> depending on your design.)

<body>
  <header>  
    <h1>My super duper page</h1>
    <!-- Header content -->
  </header>
  <div role="main">
    <!-- Page content -->
  </div>
  <aside role="complementary">
    <!-- Secondary content -->
  </aside>
  <footer>
    <!-- Footer content -->
  </footer>
</body>

If you’re not quite sure which element to use, then I suggest you refer to our HTML5 sectioning content element flowchart to guide you along your way.

Only use header and hgroup when they’re required

There’s no sense writing markup when you don’t have to, right? Unfortunately, I often see <header> and <hgroup> being used when there’s no need for them. You can get up to speed with our articles on the <header> element and the <hgroup> element, but I’ll briefly summarise:

  • The <header> element represents a group of introductory or navigational aids and usually contains the section’s heading
  • The <hgroup> element groups a set of <h1>—<h6> elements representing a section’s heading when the heading has multiple levels, such as subheadings, alternative titles, or taglines

Overuse of header

As I’m sure you’re aware, the <header> element can be used multiple times in a document, which has popularized the following pattern:

<!-- Don’t copy this code! No need for header here -->
<article>
  <header>  
    <h1>My best blog post</h1>
  </header>
  <!-- Article content -->
</article>

If your <header> element only contains a single heading element, leave out the <header>. The <article> ensures that the heading will be shown in the document outline, and because the <header> doesn’t contain multiple elements (as the definition describes), why write code when you don’t need to? Simply use this:

<article>  
  <h1>My best blog post</h1>
  <!-- Article content -->
</article>

Incorrect use of <hgroup>

On the subject of headers, I also frequently see incorrect uses of <hgroup>. You should not use <hgroup> in conjunction with <header> when:

  • there’s only one child heading, or
  • the <hgroup> would work fine on its own (i.e., without the <header>).

The first problem looks like this:

<!-- Don’t copy this code! No need for hgroup here -->
<header>
  <hgroup>  
    <h1>My best blog post</h1>
  </hgroup>
  <p>by Rich Clark</p>
</header>

In that case, simply remove the <hgroup> and let the heading run free.

<header>
  <h1>My best blog post</h1>
  <p>by Rich Clark</p>
</header>

The second problem is another case of including elements when they’re not necessarily required.

<!-- Don’t copy this code! No need for header here -->
<header>
  <hgroup>  
    <h1>My company</h1>
    <h2>Established 1893</h2>
  </hgroup>
</header>

When the only child of the <header> is the <hgroup>, why include the <header>? If you don’t have additional elements within the <header> (i.e., siblings of the <hgroup>), simply remove the <header> altogether.

<hgroup>  
  <h1>My company</h1>
  <h2>Established 1893</h2>
</hgroup>

For more <hgroup> examples and explanations, read the detailed article about it in the archives.

Common mistakes with the figure element

Ah, <figure>. The appropriate use of this element, along with its partner-in-crime <figcaption>, is quite difficult to master. Let’s look at a few common problems I see with <figure>.

Not every image is a figure

Earlier, I told you not to write extra code when it’s not necessary. This mistake is similar. I’ve seen sites where every image has been marked up as a <figure>. There’s no need to add extra markup around your images for the sake of it. You’re just creating more work for yourself and not describing your content any more clearly.

The spec describes <figure> as being some flow content, optionally with a caption, that is self-contained and is typically referenced as a single unit from the main flow of the document. Therein lies the beauty of <figure>, that it can be moved away from the primary content — to a sidebar, say — without affecting the document’s flow.

If it’s a purely presentational image and not referenced elsewhere in the document, then it’s definitely not a <figure>. Other use cases vary, but as a start, ask yourself, Is this image required to understand the current context? If not, it’s probably not a <figure> (an <aside>, perhaps). If so, ask yourself, Could I move this to an appendix? If the answer to both questions is ‘yes’, it’s probably a <figure>.

Your logo is not a figure

Segueing nicely on, the same applies to your logo. Here are a couple of snippets that I see regularly:

<!-- Don’t copy this code! It’s wrong! -->
<header>
  <h1>
    <figure>
      <img src="/img/mylogo.png" alt="My company" class="hide" />
    </figure>
    My company name
  </h1>
</header>
<!-- Don’t copy this code! It’s wrong! -->
<header>  
  <figure>
    <img src="/img/mylogo.png" alt="My company" />
  </figure>
</header>

There’s nothing else to say here. It’s just plain wrong. We could argue until the cows come home about whether your logo should be in an <h1>, but that’s not what we’re here for. The real issue is the abuse of the <figure> element. <figure> should be used only when referenced in a document or surrounding sectioning element. I think it’s fair to say that your logo is rarely going to be referenced in such a way. Quite simply, don’t do it. All you need is this:

<header>  
  <h1>My company name</h1>
  <!-- More stuff in here -->
</header>

Figure can be more than an image

Another common misconception regarding <figure> is that it can only be used for images. This isn’t the case. A <figure> could be video, audio, a chart (in SVG, for example), a quote, a table, a block of code, a piece of prose, or any combination of these and much more besides. Don’t limit your <figure>s to images. Our job as web standards affectionadoes is to accurately describe the content with our markup.

A while back, I wrote about <figure> in more depth. It’s worth a read if you want more detail or need a refresher.

Don’t include unnecessary type attributes

This is probably the most common problem we see in HTML5 Gallery submissions. While it isn’t really a mistake, I believe it’s best practice to avoid this pattern.

In HTML5, there’s no need to include the type attribute on <script> and <style> elements. While these can be a pain to remove if they’re automatically added by your CMS, there’s really no reason to include them if you’re coding by hand or if you have tight control over your templates. Since all browsers expect scripts to be JavaScript and styles to be CSS, you don’t need this:

<!-- Don’t copy this code! It’s attribute overload! -->
<link type="text/css" rel="stylesheet" href="css/styles.css" />
<script type="text/javascript" src="js/scripts.js"></script>

Instead, you can simply write:

<link rel="stylesheet" href="css/styles.css" />
<script src="js/scripts.js"></script>

You can also reduce the amount of code you write to specify your character set, amongst other things. Mark Pilgrim’s chapter on semantics in Dive into HTML5 explains all.

Incorrect use of form attributes

You may be aware that HTML5 has introduced a range of new attributes for forms. We’ll cover them in more detail in the coming months, but in the meantime, I’ll quickly show you a few things not to do.

Boolean attributes

Several of the new form attributes are boolean, meaning their mere presence in the markup ensures the behaviour is set. These attributes include:

  • autofocus
  • autocomplete
  • required

Admittedly, I only rarely see this, but using required as an example, I’ve seen the following:

<!-- Don’t copy this code! It’s wrong! -->
<input type="email" name="email" required="true" />
<!-- Another bad example -->
<input type="email" name="email" required="1" />

Ultimately, this causes no harm. The client’s HTML parser sees the required attribute in the markup, so its function will still be applied. But what if you flip the code on its head and type required="false"?

<!-- Don’t copy this code! It’s wrong! -->
<input type="email" name="email" required="false" />

The parser will still see the required attribute and implement the behaviour even though you tried to tell it not to. Certainly not what you wanted.

There are three valid ways for a boolean attribute to be applied. (The second and third options only apply if you’re writing XHTML syntax.)

  • required
  • required=""
  • required="required"

Applying that to our above example, we would write this (in HTML):

<input type="email" name="email" required />

Summary

It would be impossible for me to list here all the quirky markup patterns and practices I’ve come across, but these are some of the most frequently seen. What other common markup mistakes have you spotted around the web? Which areas of HTML5 require further clarification? We’d love to help get the wording or examples in the spec changed to make them a little more specific, so leave your thoughts below, and don’t forget to escape your HTML!

Thanks to Ian Devlin, Derek Johnson, Tady Walsh, the HTML5 Gallery curators, and the HTML5 Doctors for their input to this article.

Avoiding common HTML5 mistakes originally appeared on HTML5 Doctor on July 26, 2011.

]]> http://html5doctor.com/avoiding-common-html5-mistakes/feed/ 60 Your Questions #16 http://html5doctor.com/your-questions-16/ http://html5doctor.com/your-questions-16/#comments Tue, 01 Mar 2011 14:30:38 +0000 Richard Clark http://html5doctor.com/?p=2748 The clinic is getting busy with more HTML5 ailments! This week, we'll cover the separation of formatting and content, custom elements, using aside for social links, sections with no visible titles, and canvas in the DOM.

]]> Doctor treating a patient illustration The clinic is getting busy with more HTML5 ailments! This week, we’ll cover the separation of formatting and content, custom elements, using <aside> for social links, sections with no visible titles, and <canvas> in the DOM.

Separation of formatting and content

Graham asked:

When I first started learning html and CSS I was constantly told not to use b or i tags as the idea was to completely separate formatting from content. Is this now not the case?

In HTML 4 (and XHTML 1.x), the elements <b> and <i> (plus some others) were presentational — they only had visual meaning. This doesn’t work so well for blind users, for example.

In HTML5, presentational elements have either been cut or, as in the case of <b> and <i>, given semantic meanings to make them media-independent. You can find out more here: The <i>, <b>, <em>, and <strong> elements and The <small> and <hr> elements.

So to directly answer your question, in HTML5, <b> and <i> are now content (semantic), not formatting (presentational).

peace – Oli

Custom elements

Eric asked:

It is possible to use custom elements in HTML5 to be more semantic; however, is it ill-advised? For example:

<footer id="page-footer">
<copyright>Copyright ©...</copyright>
</footer>

Umm, no, HTML5 doesn’t allow “custom elements”. While browsers will try to recover gracefully if you do this, making stuff up is definitely ill-advised — something like <copyright> will have no meaning for browsers and could lead to problems in IE.

If you want an element for a copyright statement or other short legalese, there’s already a perfectly good one in <small>.

If you can’t find a more semantically appropriate element, use <span> for phrasing (inline) content, <p> for a block of phrasing content, or <div> for flow (block-level) content, and add a class name that indicates the semantics — e.g. <span class="lorem">Lorem ipsum</span>.

Hope that helps!

peace – Oli

Marking up social links

A reader asked:

Could a list of share icons (twitter, facebook, etc) be considered a candidate for use of the nav element? and do links in a nav element have to be into the same domain name”?

<nav> is for navigation around your content. On my personal site, I have a link to my Flickr photostream marked up in the same container as links to my own contact page, etc. I think the link to Flickr is conceptually no different to navigation within my personal site: it’s all my content. If my photos were on my own domain (as they used to be), I wouldn’t hesitate to include them in <nav>, and I wouldn’t hesitate to include this same content within <nav> today.

A list of share icons isn’t <nav> for two separate reasons.

First, they aren’t meant to take you somewhere else. They’re designed to perform an action of tweeting/”liking” a link to a page.

Second, and most importantly, they’re not navigation around your content. As the spec says “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.”

As a list of share icons is tangential to your content, I’d probably use the <aside> element: “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”. For more details, check out our <aside> revisited article.

Social links are the kind of thing that could be cut from a feed reader without diminishing the value of the content. As an additional note, remember that you can also place an <aside> at the end of an article, like a footer. In spite of its name, <aside> doesn’t have to be a sidebar.

Thanks, Bruce and Mike

Sections with no visible titles

Francesco asked:

I have some divs, in a page, that semantically would make more sense as sections as there are natural headings for them, but they’re not written *inside* them, they’re outside. There are tabs to switch the visibility of these sections, and the tab navigation is on their left… so the actual title is only there, and not repeated inside of the sections. But besides that they really are sections… they even had “class=section” in the old version. :-)

What would the best solution be? Put an h1 in there with display:none? It would make the outline correct, but it looks like a hack.

You should reorganise your markup to ensure the headings are within the section. Then you can use some CSS positioning trickery to move them into place. Don’t use display:none, though, as that’s invisible to everyone, including assistive technologies like screen readers.

Cheers, Rich

HTML5 <canvas> and the DOM

Elango asked:

Is it possible to get the elements i have drawn into the canvas using some API. Say for eg i draw 2 circle and 2 lines is that possible for me to get these information from Canvas by using DOM API’s

No. Think of a canvas like a canvas you would physically paint on. If you paint a red stroke and then paint over that in blue, you can’t get back to the original red stroke. The canvas API works the same way: once your pixels are committed, you can’t go back.

You want SVG (or try out Raphaël).

Cheers, Remy

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.

Your Questions #16 originally appeared on HTML5 Doctor on March 1, 2011.

]]> http://html5doctor.com/your-questions-16/feed/ 8 Your Questions #14 http://html5doctor.com/your-questions-14/ http://html5doctor.com/your-questions-14/#comments Fri, 26 Nov 2010 14:30:07 +0000 Richard Clark http://html5doctor.com/?p=2543 The clinic is getting busy with more HTML5 ailments. This week, we'll cover questions about aside, blogging platforms, stylesheet links, id attribute validation and a mammoth semantic journey.

]]> Doctor treating a patient illustration The clinic is getting busy with more HTML5 ailments. This week, we’ll cover questions about <aside>, blogging platforms, stylesheet links, id attribute validation, and take a mammoth semantic journey.

Aside question

Lukasz asked:

I wonder if such use of aside tag inside section would be correct:

<section id="about">
  <h1>about me</h1>
  <p>blablabla</p>
  <aside>
    <h2>you can also find me on:</h2>
    <ul>
      <li><a href="#">twitter</a></li>
      ...
    </ul>
  </aside>
</section>

Thanks in advance for any help and keep up the good work!

Hard to give definitive advice without seeing the whole page, but it seems fine to me. See Mike’s article on <aside>.

In general, use <aside> for a section of a page that consists of content that is tangentially related to but separate from the surrounding content. In print, this would be a sidebar, pull-quote, or footnote. On a weblog article, this could be article metadata in the margin or the comments section.

If your social network links are main content, then <aside> isn’t the element (maybe <section>, maybe <nav>). If they’re just related content (i.e., they could be omitted when showing this page in a feed reader), then <aside> is a good choice.

peace – Oli

Blogging services

Patrick asked:

Do you have any suggestions to people implementing HTML5 on blogging services like Tumblr? The last time I checked, there are problems making HTML5 blogs on these sites:

  • Tumblr – inserted iframe breaks HTML5 conformance
  • Posterous – no Javascript allowed at the moment (according to their doc)
  • Blogger – it doesn’t preserve my HTML5 DOCTYPE

Are there blogging services that don’t mess with the HTML5 markup?

I used to use Tumblr, and you can use HTML5 in your templates. But any new HTML5 elements (e.g., <section>) in your articles get munged, even using the “Raw HTML” setting. Unfortunately, I think that managed blogging services will probably be a little slow to adopt HTML5 (= fix the HTML5 errors they/their tools have), and you’ll have to use your own CMS for that level of control.

You can of course build your own theme for something like WordPress, and a little birdie did tell me that the latest version of WordPress has some HTML5 in its default template, so this might carry over into their hosted service. If you can’t wait and don’t have a server, remember that HTML5 is a sliding scale — I was using <div class="section"> with Tumblr for a while.

peace – Oli

Link stylesheet

Steve asked:

Hello, can we get rid of type=”text/css” when declaring a link rel=”stylesheet”?

Thank you and long live the web.

You certainly can do that. Same with including JavaScript:

<link rel="stylesheet" media="screen, projection" href="http://html5doctor.com/css/style.css">
<script src="http://html5doctor.com/js/html5.js"></script>

Thanks, Tom

ID attribute validation

Andrés asked:

Does the id attribute allows to begin with a number or a hyphen, unlike previous specs? Is there any set of character that aren’t allowed, besides space character?

There are three rules for the value of the ID attribute:

  1. It must be at least one character long,
  2. it must contain no space characters, and
  3. it must be unique within the page.

So a hyphen would be valid as an ID value. It validates too. However, you may run into legacy stuff that hasn’t been updated yet (HTML Tidy, WYSIWYG plugins for a CMS, etc), so I’d advise testing within your workflow and in a browser (no idea if IE would barf on that, and it wouldn’t surprise me if it did).

peace – Oli

I’m so confused – article, header, footer, nav?

Benjamin asked:

Hey Doctor(s), I’m so confused right now.

I’ve been trying to implement HTML5 for my new blog and CMS, but having difficulties trying to figure out where advanced content should go. All the demonstrations and examples about HTML5 are over-simplified and just don’t include any real world information. For example, an article typically includes (in no particular order):

  • Article
    • Title
    • Tagline
    • Tags
    • Avatar
    • Content
    • Links to child articles (eg. download, docs, demo)
      • Link Title
      • Link Avatar
      • Link Author Name
    • Links to recommended articles (related content)
      • Link Title
      • Link Avatar
      • Link Author Name
    • Article Author Details
      • Author Name
      • Author Avatar
    • Article Details
      • Published Date
      • Modified Date
    • Share Buttons

So all in all, way more complicated than the typical:

  • Article
    • Article Title
    • Article Content

So say for example, where should all the stuff in the complicated (real-world) example go? Should the avatar go in the header, the article, or the footer? Or maybe even a details element? Should the navigation links to other articles be like: nav > ul > li > article > header > a > h1 With the a containing the link, and the h1 containing the article header? Should the post details (despite we want them display perhaps underneath the title, and before the content) be in a details element? And should that be within the header element or be below the header element? Should they use for example:

<dl>
  <dt class="published">Published At:</dt>
  <dd class="published">...</dd>
</dl>

or:

<ul>
  <li class="published">
    <label>Published At:</label>
    <span>...</span>
  </li>
</ul>

or something else? The second example seems to remove the duplication of the css class, but seems to add more complications though. Should those tag and article links in nav elements be inside the header? Or footer? Or just article? How many footers and headers can be in article?

I’m soo confused. Any help would be greatly appreciated? Perhaps the best help out there would be a detailed HTML5 example of the real-world article structure I posted above.

OK now, take a deeeep breath and relax. There, feeling a little better? ;)

That’s a mammoth e-mail, so here are some basics to get you started:

  • Start with a basic page before attempting something complex — don’t jump in the deep end.
  • Look at websites in HTML5 Gallery and check their code.
  • Look at the code for this site. Granted, it’s not perfect, but it’s pretty good, and we have a lot of the content you list.
  • Use the most appropriate element for each piece of content, even if it’s not one of the new ones. (Hopefully it ends up being what you used before.) Perhaps our handy flowchart might help for that.

Some more specific answers:

“Should the navigation links to other articles be like: nav > ul > li > article > header > a > h1 With the a containing the link, and the h1 containing the article header?” The title of an article is not the same as an article, so it’d be wrong to use <article> or <header> here. I assume you didn’t use <h1> in navigation lists before, right?

“Should the post details (despite we want them display perhaps underneath the title, and before the content) be in a details element?” Possibly, if you wanted that interaction, but likely not as you probably want them visible all the time. See what the spec says about <details>. Decide on the semantics of each piece of content first. Worry about styling later.

“And should that be within the header element or be below the header element?” Header or footer seem like good places to put them. <label> is a caption for a form control, not an element to use whenever you need to label something.

I recommend you start with your HTML4 or XHTML1 knowledge and build on it. HTML5 is an evolution, not a revolution. In fact, I’d recommend you start out making a site in HTML4 with the HTML5 doctype (and validate it as HTML5), then change bits over time as you read each article on HTML5 Doctor and learn more ;-)

peace – Oli

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.

Your Questions #14 originally appeared on HTML5 Doctor on November 26, 2010.

]]> http://html5doctor.com/your-questions-14/feed/ 3 Your Questions Answered #5 http://html5doctor.com/your-questions-5/ http://html5doctor.com/your-questions-5/#comments Tue, 02 Mar 2010 14:30:55 +0000 Richard Clark http://html5doctor.com/?p=1400 img element, scaling video and a proposal for a field element. ]]> Doctor treating a patient illustration 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.

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

]]> http://html5doctor.com/your-questions-5/feed/ 12 Semantic navigation with the nav element http://html5doctor.com/nav-element/ http://html5doctor.com/nav-element/#comments Wed, 15 Jul 2009 14:31:45 +0000 Tom Leadbetter http://html5doctor.com/?p=473 <nav> element which allows you to group together links, resulting in more semantic meaning for your markup, and help help structure the content for screenreaders. In this article I'll discuss how and where to use it as well as some reservations I have with the specifications definition.]]> One of the new elements for HTML 5 is the <nav> element which allows you to group together links, resulting in more semantic markup and extra structure which may help screenreaders. In this article I’ll discuss how and where to use it as well as some reservations I have with the specifications definition.

At first, I thought the <nav> element to be pretty simple. And whilst it still is very easy to use, I found the specification to not be overly helpful; a lot of decisions are left to the developer. Then on Monday Hixie made a change to the definition of <nav> in the draft following a prompt from our very own Dr Bruce.

How to use it

You are probably used to using something like

<div id="nav">
<ul>
<li><a.... etc

Or

<ul id="mainNav">

Well, for the sake of your markup, nothing much will change as you will now have something like this

<nav>
<ul>
<li><a href="index.html">Home</a></li>
<li><a href="/about/">About</a></li>
<li><a href="/blog/">Blog</a></li>
</ul>
</nav>

The specification

The HTML 5 specification defines <nav> as:

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.

The key phrase there is “major navigation” (previously primary navigation).

Looking at the example they give – “In the following example, the page has several places where links are present, but only one of those places is considered a navigation section.”

<body>
<header>
<h1>Wake up sheeple!</h1>
<p><a href="news.html">News</a> -
<a href="blog.html">Blog</a> -
<a href="forums.html">Forums</a></p>
<p>Last Modified: <time>2009-04-01</time></p>

<nav>
<h1>Navigation</h1>
<ul>
<li><a href="articles.html">Index of all articles</a></li>
<li><a href="today.html">Things sheeple need to wake up for today</a></li>
<li><a href="successes.html">Sheeple we have managed to wake</a></li>
</ul>
</nav>

</header>
<article>
<p>...page content would be here...</p>
</article>
<footer>
<p>Copyright © 2006 The Example Company</p>
<p><a href="about.html">About</a> -
<a href="policy.html">Privacy Policy</a> -
<a href="contact.html">Contact Us</a></p>
</footer>
</body>

I have to say that this is no use to me. There are six items of navigation in the header element there. But only three are in the nav tag. There is no explanation as to what differentiates the first three links with the second three links – both go to different pages and all are in internal to that current site.

They also give a second example:

<body>
<h1>The Wiki Center Of Exampland</h1>

<nav>
<ul>
<li><a href="/">Home</a></li>
<li><a href="/events">Current Events</a></li>
...more...
</ul>
</nav>

<article>
<header>
<h1>Demos in Exampland</h1>

<nav>
<ul>
<li><a href="#public">Public demonstrations</a></li>
<li><a href="#destroy">Demolitions</a></li>
...more...
</ul>
</nav>

</header>
<section id="public">
<h1>Public demonstrations</h1>
<p>...more...</p>
</section>
<section id="destroy">
<h1>Demolitions</h1>
<p>...more...</p>
</section>
...more...
<footer>
<p><a href="?edit">Edit</a> | <a href="?delete">Delete</a> | <a href="?Rename">Rename</a></p>
</footer>
</article>
<footer>
<p><small>© copyright 1998 Exampland Emperor</small></p>
</footer>
</body>

This is a little more helpful as I find the biggest isse of the <nav> element is deciding which sets of links should be classed as major navigation.

Where to use it?

If you take a peek at the source code for this site, there are three uses (Ed. or four if you’re on a page that includes pagination) of the nav elements – we used it on the main navigation and above the footer (both are exactly the same links by the way). We also decided to use it on the skip links that are included for accessibility.

Looking at the content of the site, it could be argued that the <nav> element could be used on the Recent Articles and Categories listings in the sidebar. Should you do it? Honestly, I think it is hard to say from looking at the spec – but I would say these are not “major navigation” but it would tempting to do, particularly if you’re analytics suggest these areas of navigation are ‘major’ ways in which your users navigate your site.

Other Possible Uses

Below are a few more examples of other areas of the site in which you might consider using the <nav> element. It is also important to note that while XHTML 2 <nl> element, this hasn’t been replicated in HTML 5 because navigation does not have to take list form, as we’ll see.

  • Table of Contents
    I would say definitely yes to that – it is primary navigation for that particularly content
  • Previous/next buttons (or pagination)
    I would say yes to this because it is important to the overall structure and hierarchy of the blog/site
  • Search form
    For me, a definite yes, but it is not mentioned in the spec. A search form is hugely important to the navigation of a site, particularly large sites which rely almost solely on their search engine.
  • Breadcrumbs
    Again, I would say yes to this as well. Although breadcrumbs are not always necessary and can be used when not applicable, on large sites a breadcrumb trail can be an important navigation aid.

The difference of nav from menu

If you aren’t aware there is another element that can confuse the issue in the HTML 5 specification – menu. I’ve noticed that some developers are using the <menu> element for navigation rather than the <nav> element. We thought it best to clarify that <menu> is to be used for a list of commands and is an interactive element and more likely to be used exclusively in Web Applications. We will be covering more about the <menu> element in a later post.

And finally…

Only with the help of the community, and hopefully a much clearer spec, can we be sure when and perhaps more importantly, when not to use the <nav> element.

Semantic navigation with the nav element originally appeared on HTML5 Doctor on July 15, 2009.

]]> http://html5doctor.com/nav-element/feed/ 64