Your Questions Answered #5

by .

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:


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:


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,, 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,


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:

I would love to hear your thoughts on this.


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.

12 Responses on the article “Your Questions Answered #5”

  • Joe Devon says:

    Just a heads up, I find it really hard to read the questions in that small italicized font. The computer overuse has hurt my eyesight over the years so maybe others won’t be as bothered by it, but I basically skipped the questions after awhile and read only the answers.

  • Thanks for pointing that out Joe, it’s great to get some feedback. We’ve actually got some plans to improve the readability of the site so comments like this help bump it up the list!

  • Florent V. says:

    Regarding the (for now fictional) FIELD tag, it could be used to specify that some content is relative to the field. That could be help text, error messages, instant validation feedback, etc. Right now this text is place before or after the field, with no semantic way of saying to which field it should be applied. We rely on CSS to put that kind of content close to the field or right of it.

    So I think this proposal could help for accessibility needs. I would like to know if accessibility experts think it would be useful or not.

  • Hi! Good article. Did you try validating your site? I tried and got 3 errors. Is it possible to fix them?

  • @Florent: This is the kind of case study I would be interested in seeing, how beneficial it would be to have those related elements grouped and how it can make a page more accessible. It would definitely be interesting to see what accessibility experts have to say on this subject.

    However, I am still concerned about backwards compatibility. We don’t want to fall into a trap of this element being added, and then having unknowledgeable developers thinking that the for attribute is no longer required, excluding it entirely and making the form less accesible in older browsers. The attribute would have to remain for an indefinite amount of time, as we hope that it can be phased out in the future.

    Perhaps that is a worthwhile sacrifice? I suppose it depends on the proposed element’s implementation within the browser and how they deal with the combination of the element and a mis-matched for attribute.

  • Leo says:

    Thanks again! The question & answer concerning the img-tag was an interesting (reflow!) one.

  • @Florent To associate content with a form field, why not add the content to the label and control positioning via CSS? Examples of this are Required Form Fields and Form Error Messages. I also wrap <input> in <label> to increase clickable area (click on the label and the input becomes active). Note that while most browsers won’t need the for="" attribute when you do this, IE6 still does.

    Regarding @John’s <field> proposal, for me the various <form> child elements (<input>, <textarea> etc) with their associated labels are the fields — the input field, the textarea field etc. I also think the form’s content dictates what wrapper element to use. For me it’s almost always a list (<ol> or <ul>), and very rarely a <table> (for a complex multi-column form). For me <div> is fine but not ideal (as it’s generally a list of questions), and <dl> seems inappropriate somehow, maybe because initially the <input>s don’t have any data. The other disadvantage of <dl> (and <table>) is you can’t wrap <input> in <label>.

    Using <label> for the label and <input> for the input is the most important bit though. The rest is presentation as much as anything.

  • Florent V. says:

    Hi all,
    @Mike, I’m not knowledgeable enough to do that kind of study. I may ask some accessibility experts I happen to know if they think there is a need for something like this.
    @Oli, your two examples are nice. For placing a conventional typographic sign (*) or a few words, it’s a decent solution to embed that information in the label. But sometimes you have a full sentence used as help text or a validation message, and embedding it in the label would be cumbersome (verbose output in a screen reader, for instance).

  • @Florent In those cases adding the text to <li> (outside <label>) works for me ;-) I should also ask @feather if his advice has changed in the intervening last 5 years…

  • @Ian (Original Question)

    The basic version of what Mozilla did for creating the video scaling effect can be accomplished by wrapping a video element in a div. The video element would need to be set to 100% of the width and height of the div and then you can scale the div however you see fit.

    There are, of course, a lot more considerations than just that, but that should get you started. If you’re interested in recreating this effect you can use Mozilla’s JavaScript as a guideline.

  • Join the discussion.

    Some HTML is ok

    You can use these tags:
    <a href="" title="">
    <abbr title="">
    <blockquote cite="">
    <del datetime="">
    <q cite="">

    You can also use <code>, and remember to use &lt; and &gt; for brackets.