HTML5 Doctor » section

Avoiding common HTML5 mistakes

Richard Clark — Tue, 26 Jul 2011 13:38:05 +0000

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

s with HTML5 sectioning elements — specifically, replacing wrapper

s (used for styling) with

s. In XHTML or HTML4, I would see something like this:



    
    My super duper page

Now, I’m instead seeing this:



    
    My super duper page

Frankly, that’s just wrong:

is not a wrapper. The

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 element as described by Kroc Camen. If you still need an additional element for styling, use a

. 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

depending on your design.)


    
    My super duper page

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

and being used when there’s no need for them. You can get up to speed with our articles on the

element and the element, but I’ll briefly summarise:

The
element represents a group of introductory or navigational aids and usually contains the section’s heading
The element groups a set of
—
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

element can be used multiple times in a document, which has popularized the following pattern:



    
    My best blog post

If your

element only contains a single heading element, leave out the

. The

ensures that the heading will be shown in the document outline, and because the

doesn’t contain multiple elements (as the definition describes), why write code when you don’t need to? Simply use this:

  
  My best blog post

Incorrect use of

On the subject of headers, I also frequently see incorrect uses of

. You should not use in conjunction with

when:

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

The first problem looks like this:



    
    My best blog post
  
  by Rich Clark

In that case, simply remove the

and let the heading run free.


  My best blog post
  by Rich Clark

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



    
    My company
    Established 1893

When the only child of the

is the , why include the

? If you don’t have additional elements within the

(i.e., siblings of the ), simply remove the

altogether.

  
  My company
  Established 1893

For more

examples and explanations, read the detailed article about it in the archives.

Don’t wrap all lists of links in

With 30 new elements (at the time of writing) introduced in HTML5, we’re somewhat spoilt for choice when it comes to creating meaningful, structured markup. That said, we shouldn’t abuse the super-semantic elements now made available to us. Unfortunately, that’s what I see happening with

. The spec describes

as follows:

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.

Note: Not all groups of links on a page need to be in a nav element — the element is primarily intended for sections that consist of major navigation blocks. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases; while a nav element can be used in such cases, it is usually unnecessary.

WHATWG HTML spec

The key phrase is ‘major’ navigation. We could debate all day about the definition of ‘major’, but to me it means:

Primary navigation
Site search
Secondary navigation (arguably)
In-page navigation (within a long article, for example)

While there isn’t any right or wrong here, a straw poll coupled with my own interpretation tells me that the following shouldn’t be enclosed by

Pagination controls
Social links (although there may be exceptions where social links are the major navigation, in sites like About me or Flavours, for example)
Tags on a blog post
Categories on a blog post
Tertiary navigation
Fat footers

If you’re unsure whether to mark up a list of links with

Common mistakes with the figure element

Ah,

. The appropriate use of this element, along with its partner-in-crime

, is quite difficult to master. Let’s look at a few common problems I see with

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

. 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

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

, 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

. 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

(an

, perhaps). If so, ask yourself, Could I move this to an appendix? If the answer to both questions is ‘yes’, it’s probably a

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:



  
    
      
    
    My company name

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

, but that’s not what we’re here for. The real issue is the abuse of the

element.

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:

  
  My company name

Figure can be more than an image

Another common misconception regarding

is that it can only be used for images. This isn’t the case. A

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

s to images. Our job as web standards affectionadoes is to accurately describe the content with our markup.

A while back, I wrote about

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

Instead, you can simply write:

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:


required="true" />

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"?


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):

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.

Your Questions #17

Richard Clark — Tue, 19 Apr 2011 13:30:12 +0000

The clinic is packed this week with your HTML5 ailments! Today, we’ll discuss an HTML5 syntax dilemma, using sections within sections, semantics, describing the contents of a figure, and marking up web app toolbars.

HTML5 syntax dilemma

Manuel asked:

In theory, HTML5 syntax is very lazy but, in fact, when you write a HTML5 page you follow some conventions that originate in the XHTML era: lowercase code, double-quoted attribute values, properly closed elements, proper element nesting. While this practice is rational and admirable, some people take a further step towards a XHTML-style syntax: they don’t use attribute minimization and do terminate empty elements. Of course this further step is not necessary to write clear HTML5 code, but could be fostered if you look at the following points:

it makes [it] easier to upgrade legacy XHTML code (which represents the bulk of the web even if it’s generally served as text-html) to HTML5 (it’s just a matter of doctype change)

it makes [an] easier the shift to HTML5 for web developers, since they are generally used to write XHTML

it could set a coding standard in the field

What do you think about it?

I disagree. I think there’s nothing lazy about HTML5 syntax. You could say that it’s lazy that in HTML we write

rather than , but the fact is, it’s a specified part of the language.

Furthermore, “legacy XHTML” code does not represent the bulk of the Web; 61% of the Web is HTML4 according to the Opera MAMA study in 2008.

But it doesn’t matter. You say tom-ay-toes, I say to-mah-toes; you like XHTML syntax, I like HTML syntax. They’re all the same to a browser, if served as text/html.

Cheers, Bruce

Sections within sections

Corey asked:

Don’t know if this has been asked before or not, as I couldn’t find anything to tell me otherwise. I read through the article and section information and understand more or less how they function, but I’m wondering if there is a case to be made about having a section within a section. Your article doesn’t really touch on whether this is appropriate or not.

The reason I ask is because I have a page that is broken into different parts (introduction, description, requirements, etc) that are all part of the same overall article. Now if I wanted to break down say, the requirements section into sub-sections (technical, stylistic, semantic, etc) would it be all right to wrap those sub sections in a section tag (that is within a section itself), assuming I put the correct header on it?

Thanks a bunch,

Yes, you certainly can nest

s — in fact, that’s pretty much exactly what

is for! If you look at the source of some of our more recent articles — e.g., this article or our microformats article — you’ll notice how we’ve split the article into sections.

In theory, using nested sections means that we’ll be able to do away with

–

, since a new heading level is implied with each nested section. In practice, however, it’s not as simple as that, so we suggest sticking with the usual

–

heading structure even if you decide to nest sections.

For your example, this code would be entirely appropriate:


  Article name
  ...
  
    Introduction
    ...
  
  
    Description
    ...
      
        Technical
        ...
      
      
        Stylistic
        ...
      
  
  
    Requirements
    ...

Each part of the

is wrapped in a

. The one exception might be the introduction, unless you are explicitly declaring a heading with it. You don’t always need a

element if it would only contain a single

–
element. In that case, the heading on it’s own will be fine. Bruce has a good post on the difference between articles and sections.

Hope that helps, Rich

Since we’re being semantic…

Rob asked:

HTML5 is working towards being more semantic, but I don’t think the tag is semantic at all…especially for stylesheets! Has anyone ever suggested changing the specification for the

I think most implementors would say that the current way works well enough. Breaking backwards compatibility for the sake of theoretical purity was where XHTML 2 was heading before it was finally curtailed. HTML5 takes stock of where we are, warts and all, and builds on that. (I feel your pain: I always want to be .)

Cheers, Bruce

Describing the content of

Sverri asked:

A lot of things can be presented as figures (everything from a simple quote to an information-dense canvas). The first thing that came to my mind was using e.g. a “type” attribute. For example:
  Styling p tags
  p { margin-bottom: 1em }
That would be a dead simple way of succinctly telling user agents, search engines, etc. what kind of content they can expect to find in the figure. However, since this is not valid HTML5 (as far as I know) how would you recommend describing the contents of a figure, so as to make it more accessible to non-human agents?

Thank you.

Bruce replied:

What would be the purpose of doing so? For example, it’s easy for a non-human agent to see that your example contains code, or that:


  ...
  ...

contains video, or that:

...

contains an image. So I’m not sure of the use case for a type attribute.

Sverri then responded:

The way I think about this is that figures are images of sorts, or embedded content. A “type” attribute (or perhaps a more aptly named “of” attribute) would be the equivalent of the “alt” attribute of img. It is extra information, and as such would not always be needed, but sometimes it can be an important part in how you present the content.

As for use cases:

Aiding search engines better understand the content

Browsers can use such information to make browsing the internet richer

I realize that you can use some other way of describing the content, such as titles, itemscopes or other ways of adding metadata. A dedicated, but optional, attribute for this would not be such a bad idea in my opinion.

To sum up, I suppose what I am getting at is that content in a figure is not always so well defined on its own. A snippet of code, for example, is given more meaning if it is in a context, such as “css”, “algorithm” or “while loop”.

I hope I am being clear enough in what I am saying.

Bruce followed up once more:

You are clear. There have been many such discussions during the development of HTML5 (and preceding versions of HTML). For example, why not have a element for marking up people’s names, analogous to ? Why not have or or ?

The use cases you describe (aiding search engines and browsers) are equally applicable.

But it comes down to two factors:

First, HTML is not a specialised language. It’s a generalised language, and there are some cases that can’t be marked up with the existing crop of elements. (There are already over a hundred.)

Second is that minting new elements and attributes isn’t “free”. It’s more for authors to remember (and get wrong), it bloats parsers in browsers, and it makes regression testing harder. So if a new addition to the language doesn’t solve a very common problem, it isn’t added to the language.

As you said, microdata/microformats/RDFa can be used to extend the language for specialised cases.

Thanks, Bruce

Web app buttons and toolbars: anchors, buttons, or commands?

Christian asked:

If you’re creating a toolbar for a web app, or perhaps even a “Share this page” widget, should one use anchors, buttons or commands?

A toolbar should be HTML5

with nested s, but browser support is zilch. I’d use a list of buttons, personally. I think

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 #17 originally appeared on HTML5 Doctor on April 19, 2011.

Your Questions #16

Richard Clark — Tue, 01 Mar 2011 14:30:38 +0000

The clinic is getting busy with more HTML5 ailments! This week, we’ll cover the separation of formatting and content, custom elements, using

for social links, sections with no visible titles, and 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 and (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 and , given semantic meanings to make them media-independent. You can find out more here: The , , , and elements and The and
elements.

So to directly answer your question, in HTML5, and 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:

Copyright ©...

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

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

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”?

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
, and I wouldn’t hesitate to include this same content within
today.

A list of share icons isn’t
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
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
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
at the end of an article, like a footer. In spite of its name,
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 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.

Related Posts:

Your Questions Answered #10

Your Questions Answered #7

Your Questions #14

Your Questions #15

Your Questions #13

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

Your Questions #14

Richard Clark — Fri, 26 Nov 2010 14:30:07 +0000

The clinic is getting busy with more HTML5 ailments. This week, we’ll cover questions about
, 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:

about me blablabla you can also find me on: twitter ...

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
.

In general, use
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
isn’t the element (maybe
, maybe
). If they’re just related content (i.e., they could be omitted when showing this page in a feed reader), then
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.,
) 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
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:

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:

It must be at least one character long,

it must contain no space characters, and

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:

Published At: ...

or:

Published At: ...

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
or
here. I assume you didn’t use
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
. 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. 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.

Related Posts:
Your Questions #15
Your Questions #16
Your Questions Answered #8
Your Questions Answered #4
Your Questions Answered #11
Your Questions #14 originally appeared on HTML5 Doctor on November 26, 2010.

Your Questions Answered #10

Richard Clark — Fri, 09 Jul 2010 12:45:00 +0000

The clinic is getting busy with more HTML5 ailments. This week, we’ll cover using sections within a footer, vs. Flash security, why HTML5 elements are treated as inline, using offline with storage, and marking up block quotes.

Footer with sections

Tommie asked:

Hi, I’ll get to the point right away. I want to use, lets say 3 section elements inside a footer each floating left and inside each of this sections I have some standard information. Is this the right way to go, or should I put my section elements outside the footer and only put copyright text etc. inside the footer?

Thanks!

You could use a
within
. but
is a sectioning root anyway
is flow content and can contain sectioning content. If you want them to appear in the outline within the footer, then it makes perfect sense to do as you suggest.

See more in Jack’s article on the
element. There are also some more examples in the spec.

Cheers, Rich

vs. Flash (security and copyright)

John asked:

I’m seeing lots of opinions that the canvas element might free us of the Adobe Flash monopoly, but what mechanisms can we use to protect our works when using straight HTML and JavaScript?

Right now I’m thinking about simple flash games, but I’m sure this is a concern for others wanting to use (free) HTML methods to perform functions now reserved more for flash.

Thanks for any input.

I’m not sure of any security mechanisms that we can use to protect content. It isn’t really any different than an image or any other type of resource. Having said that, decompilers can circumvent some of Flash’s security measures as well, so you may not be much worse off using .

If we come across anything, we’ll be sure to let you know.

Cheers, Rich

HTML5 tags inline?

Tami asked:

So, I’ve been experimenting with the new HTML5 elements, and one frustration I have is understanding the native display of the new elements, and how it works within the document flow. So far, experimenting with them has shown them to be very unpredictable. At best, they’re kind of behaving like a bastard span. They seem to be behaving like inline elements but that seems like it is wrong. In some cases, setting to display: block gives the expected behavior, but on the footer tag, it’s not interacting with floated elements properly.

So, are these new elements inline or are browsers still just trying to catch up? I tried looking in in the HTML5 working draft spec, but so far I am not understanding the way its written (HTML4′s specs clearly spelled out whether an element was display or inline).

Here’s an article from my personal blog that I wrote a while ago describing why browsers treat HTML5 elements as inline.

Thanks, Bruce.

Offline + Storage

Dear Doctor, I’m trying to work out if HTML5 will be able to do the job that I want. I have a number of documents (PDF, PPT, etc.) that I want to share with people in my team. These documents may change from time to time. Also, the people may not always be connected online.

Would it be possible to “cache” documents in an offline database in the browser so that when they are not connected they can still view them but when they are, they get the latest versions (which also refresh the cache)?

That way I can do a fairly pretty interface for sorting these documents so that they can easily find them.

Thanks in advance for any help you can provide.

You can, but I would strongly encourage you to think carefully about whether it’s worth it.

You can include these “assets” in the manifest, which will make the files available to the offline applications (note that this isn’t storage, just caching, which is what you’re after).

The problem is that when the visitor first hits the page with the manifest — which contains all the PDFs, PPTs, etc. — it will download all of these files. This is the bit that I’d encourage you to consider carefully. To compound that, I believe there’s a 5MB limit on the cache, so you might run into problems if you’re trying to cache more than that.

I’ve not covered offline cache on HTML5 Doctor yet (though it’s on the list), but I have described the process on my 24ways article.

If there are new versions of the cached files, you need to change the contents of the manifest — e.g., include a version number, which will trigger a download of all the assets again. Not ideal, but that’s the current situation.

Hope that helps a bit, Remy

Correct markup with blockquote

Phil asked:

Hi, in HTML 4.0 Strict and XHTML 1.0 Strict, text inside a blockquote element is required to be nested inside another block-level element, e.g. p.

In HTML5 that requirement seems to have been relaxed, as the following element validates successfully:

This is a blockquote.

The HTML5 spec uses the p element in the usage examples, but does not mention whether it is required.

Can you please confirm if this requirement has now been deprecated?

Great question. As I expected, this validates:

blockquote test Tiger tiger burning bright

We double-checked with the WHATWG mailing list and confirmed that
can contain ‘flow’ content (i.e., text, paragraphs, etc.).

To summarise, it would be valid not to further mark up content within a
, but authors are encouraged to use a
(or other more appropriate element).

Bruce

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.

Related Posts:
Go offline with application cache
Your Questions Answered 9
Your Questions #16
Your Questions Answered #7
Your Questions Answered #12
Your Questions Answered #10 originally appeared on HTML5 Doctor on July 9, 2010.

The article element

Tom Leadbetter — Tue, 18 May 2010 14:00:27 +0000

We’ve discussed a lot of new elements here at HTML5Doctor, but the article element has somehow escaped the microscope… until now! article is one of the new sectioning elements. It is often confused with section and div but don’t worry we’ll explain the difference between them.

What the spec says

Thankfully, the spec is short and sweet:

The article element represents a component of a page that consists of a self-contained composition in a document, page, application, or site and that is intended to be 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.
W3C Specification

In addition to its content, an
element typically has a heading (often in a header element), and sometimes a footer. The easiest way to conceptualise
is to think of its use in a weblog, as mentioned in the spec’s examples “a blog entry” and “user-submitted comments.” Here at HTML5 Doctor, we wrap each weblog entry inside an
element. We also use
on ‘static’ content pages, like the About and Contact pages, as
can be used for “any other independent item of content.” The tricky part is, what exactly is an independent item of content?

The smell test for going independent

An independent piece of content, one suitable for putting in an
element, is content that makes sense on its own. This yardstick is up to your interpretation, but an easy smell test is would this make sense in an RSS feed? Of course weblog articles and static pages would make sense in a feed reader, and some sites have weblog comment feeds. On the other hand, a feed with each paragraph of this article as a separate post wouldn’t be very useful. The key point here is that the content has to make sense independent of its context, i.e. when all the surrounding content is stripped away.

Examples of
in use

A bare-bones

We only have a title and some content, but it’s enough to make sense on its own (assume there’s a lot more content about apples ;-)

Apple The apple is the pomaceous fruit of the apple tree... ...

A weblog-style

A published date leads us to add a
, and there’s also content that would be suitable in a
elements.

Apple Published: 2009-10-09 The apple is the pomaceous fruit of the apple tree... ... Creative Commons Attribution-ShareAlike License

An
with comments as nested
s

This example shows a weblog entry with comments. Each comment can be marked up as an
within the containing
.

Apple Published: 9th October, 2009 The apple is the pomaceous fruit of the apple tree... ... Comments Posted by: Apple Lover ~1 hour ago I love apples, my favourite kind are Granny Smiths Posted by: Oranges are king ~1 hour ago Urgh, apples!? you should write about ORANGES instead!!1!

An
with
s

You can use the
element to split the article into logical groups of content with headings:

Apple varieties The apple is the pomaceous fruit of the apple tree... Red Delicious These bright red apples are the most common found in many supermarkets... Granny Smith These juicy, green apples make a great filling for apple pies...

A
containing
s

Where appropriate a
element can contain
elements. We already saw this in the comment section example above, and other common examples are the homepage or category pages of a weblog:

Articles on: Fruit Apple The apple is the pomaceous fruit of the apple tree... Orange The orange is a hybrid of ancient cultivated origin, possibly between pomelo and tangerine... Banana Bananas come in a variety of sizes and colors when ripe, including yellow, purple, and red...

Using
for a widget

The specification also mentions that an interactive widget can also be an
. The example below shows how the markup might look for an embedded widget from somewhere like Widgetbox.

My Fruit Spinner

The pubdate attribute

You may have noticed the pubdate attribute in these examples. pubdate is an optional boolean attribute that may be added to one time element within the
. If present it indicates that the element is the date the
was published. It can be written in several ways, the most popular being:

pubdate pubdate="pubdate"

You could think of these as HTML and XHTML-style — the end result is the same so use the style you like. Note that pubdate applies only to the parent
element, or to the document as a whole.

The difference between
and

There’s been a lot of confusion over the difference (or perceived lack of a difference) between the
and
elements in HTML5. The
element is a specialised kind of
; it has a more specific semantic meaning than
in that it is an independent, self-contained block of related content. We could use
, but using
gives more semantic meaning to the content.

By contrast
is only a block of related content, and
is only a block of content. Also as mentioned above the pubdate attribute doesn’t apply to
. To decide which of these three elements is appropriate, choose the first suitable option:

Would the content would make sense on its own in a feed reader? If so use

Is the content related? If so use

Finally if there’s no semantic relationship use

Dr Bruce has written HTML5
s and
s, what’s the difference?, so we recommend reading that if you are still fuzzy on when to use
.

Summary

Hopefully this post has given you some insight into the correct use of the
element. Do you have any other examples that you can share for using
in your HTML5 markup?

I’m also keen to hear your thoughts on the confusion between the
and
elements. Do you think the distinction between the two is clear?

Related Posts:
The dl element
The time element (and microformats)
Your Questions Answered #4
The section element
Your Questions Answered #6
The article element originally appeared on HTML5 Doctor on May 18, 2010.

Your Questions Answered #7

Richard Clark — Tue, 20 Apr 2010 14:10:51 +0000

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

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

or
?

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
s or s where another, more precise element would fit the bill. But for grouping arbitrary content,
s and 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
s might be
s or maybe
elements though, depending on their content. I suggest you read our article (and the comments) on the
element.

Thanks, Tom

Header with

Diego asked:

Hi,

This structure is right?

Foo Bar Baz Bat Qux lorem ipsum

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
within your
or an within your
. Similarly, you don’t have to use a
around your .

To summarise, the best solution (if you don’t require the
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.

Related Posts:

Your Questions Answered #5

Your Questions Answered #8

Your Questions Answered #11

Your Questions Answered #6

Your Questions Answered 9

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

Your Questions Answered #5

Richard Clark — Tue, 02 Mar 2010 14:30:55 +0000

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 element, scaling video, and a proposal for a 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
within your
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 inside the
though.

See our articles on
and
for more on this.

Regarding your second question, I would use
(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 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 (
–
). The outlining algorithm can produce a table of contents from the nested
,
,
, and
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 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 and to provide some interesting results (laying the over the ). For more on the 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 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.

Related Posts:

Your Questions Answered #8

Your Questions Answered #7

Your Questions Answered #11

Your Questions Answered #6

Your Questions 18

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

The section element

Bruce Lawson — Fri, 11 Sep 2009 12:38:17 +0000

We doctors are a bunch of chums using HTML5 and writing about how we do it. Apart from spurious requests for medical advice, the questions we receive most are about using the section element, and we realise that we’ve been using the section element incorrectly all this time.

Sorry.

What we’ve been doing wrong is using section to wrap content in order to style it, or to demarcate the main content area from the nav, header, footer etc. These are jobs for div, not section.

The section spec says

The section element represents a generic document or application section…The section element is not a generic container element. When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead.

section is a blob of content that you could store as an individual record in a database. It generally looks like this (and note that the heading goes inside the section element, not immediately before it):

Any level of heading rest of the content

With very few exceptions, section should not be used if there is no natural heading for it. Check your work in the HTML 5 outiner tool. If you see any instances of “untitled section” that corresponds to a section, you’re probably doing it wrong. (It’s fine for a nav or aside element to be untitled, however).

Section is also the most generic of the sectioning elements. Make certain that you don’t really need an article, which is defined as

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

What about main content?

In HTML 5 you can specifically mark up all the “secondary” content on a page such as navigation, branding, copyright notices, so it feels odd that you can’t specifically mark up the most important part of your page—the content.

But what would be the purpose of marking it up specifically, anyway? If you need to style it, use a div. An assistive technlogy like a screenreader can find the main content because it is the first thing inside a page that isn’t a header, nav or footer.

Rules of thumb for using section

Of course, there are always exceptions, but these should give useful guidance for 99% of cases:

Don’t use it just as hook for styling or scripting; that’s a div

Don’t use it if article, aside or nav is more appropriate

Don’t use it unless there is naturally a heading at the start of the section

The revised spec (as of 16 September) says:

Authors are encouraged to use the article element instead of the section element when it would make sense to syndicate the contents of the element.

As blogposts and comments are often syndicated (by being pulled into other blogs or being linked via twitter, reddit etc) they should be articles.

Thanks to Opera’s Lachlan Hunt for fact-checking this article. Please also note that we haven’t yet changed the WordPress theme to get rid of extra sections, so for now please do as we say and not as we do!

Related Posts:

Designing a blog with html5

September HTML5 spec changes

Document Outlines

Your Questions Answered #3

Your Questions Answered #4

The section element originally appeared on HTML5 Doctor on September 11, 2009.

Your questions answered #1

Richard Clark — Mon, 06 Jul 2009 10:59:36 +0000

One week on since our official launch and we’ve been overwhelmed by your response to the site. It’s great to see a large number of you wanting to get involved with the discussion relating to HTML 5 and asking about what you can and can’t do as well as the pro’s and cons of the specification.

In this post we’re going to cover a few of the questions we’ve received that don’t require a full post answer but still need to be addressed. We’ll post more answers everytime we’ve collated a bunch of questions so don’t be afraid to ask, however groundbreaking or insignificant it might be. Ok here we go for starters…

Automated Conversion?

Andy Mabbett wrote to ask:

Are there (or will there be) any automated or semi-automated tools which will take my (valid) HTML 4.01 Strict documents and convert them to HTML5?

While we don’t know about any specific conversion tools for converting to HTML 5 from HTML 4.01. There are several articles (see below) describing how you can name your classes more semantically in preparation for using HTML 5.

More on developing naming conventions, Microformats and HTML5

Preparing for HTML5 with Semantic Class Names

HTML5 id/class name cheatsheet

A final point on this is that I’m not sure that it would be wise to have a converter in order to move from HTML 4.01 to HTML 5, a machine however clever will not really be able to understand the true meaning of
or
for example. I’d be interested to hear other peoples thoughts on this though?

When should I start using HTML 5?

James asked us (presumably a little tongue in cheek):

Dear Doctor,

When will I know that it is time to start using HTML5 “for real”? Will there be an announcement?

yours etc,
James

Now I’d love there to be an official annoucement, in fact I might just announce it now! You can all start using HTML 5 today. There I said it, I feel so much better now. Seriously though, there is no reason for you not to start using HTML 5 now in sites you’re developing. I’m not saying that you have to use it religiously, but at you should at least start thinking about it in your development roadmaps. We can see on our sister site that there are a number of sites using HTML 5 “in the wild”. The amount of implementation varies greatly (some including
‘s around their
elements for styling purposes for example) but they have begun to incorporate HTML 5 right now.

Lastly, Molly recently gave a talk at @media which touched upon this subject, she told us that

Implementation trumps specification

which I happen to firmly believe, after all CSS 2.1 isn’t a formal specification yet but almost everyone is using it. If you’re not sure where to start then I suggest taking a look at what browser implementations are currently like, which is where this Wiki from the WHATWG comes in. Hope that answers your question James.

Main Body

Darren asked:

How do I markup the main body of a page, are there tags? Can I serve a SWF Flash file using tags?

Regards Darren

There isn’t a tag (element), the most appropriate element for that would be
, however if only a single article is contained in that area you should use
.

As for the second part to your question, you *can’t* use a SWF file natively as the source to the tag, or FLV file for that matter. However, for the foreseeable future you’re still going to need to embed flash for video, via nesting the flash within the tag.

First you’ll use the with nested source elements to fall through the different supported codecs. Then when all else fails, particularly for IE, you’ll serve up the flash video via the and combo. This is because IE8 and lower doesn’t support the you’re going to need to fall back on something that works.

Make sure you read Tom’s article about the element, but you should also find this article on Video for Everybody useful to see how to degrade through the codecs.

More articles!

Although not really a question I wanted to drop this in, August wrote to tell us:

The
article is awesome. Great explanation of a very semantic HTML5 element. More of those, please!

Thanks for the great feedback August, we’re happy to help, rest assured we’ve got plenty of articles lined up along those lines, in fact I know we’ve got a few crackers lined up for the next couple of weeks, so watch this space.

And finally…

If your question hasn’t been answered in this post or we haven’t got back to you directly then it’s more than likely that we’ll be covering it soon in a more detailed post so be sure to check back or subscribe to the RSS feed for all future articles.

Related Posts:

Your questions answered #2

Your Questions Answered #12

Your Questions Answered #6

The video element

Your Questions Answered #8

Your questions answered #1 originally appeared on HTML5 Doctor on July 6, 2009.

HTML5 Doctor » section

Avoiding common HTML5 mistakes

Don’t use section as a wrapper for styling

My super duper page

Only use header and hgroup when they’re required

Don’t wrap all lists of links in

Common mistakes with the figure element

Not every image is a figure

Your logo is not a figure

Figure can be more than an image

Don’t include unnecessary type attributes

Incorrect use of form attributes

Boolean attributes

Summary

Related Posts:

Your Questions #17

HTML5 syntax dilemma

Sections within sections

Article name

Introduction

Description

Technical

Stylistic

Requirements

Since we’re being semantic…

Describing the content of

Web app buttons and toolbars: anchors, buttons, or commands?

Got a question for us?

Related Posts:

Your Questions #16

Custom elements

Marking up social links

Sections with no visible titles

HTML5 and the DOM

Got a question for us?

Related Posts:

Your Questions #14

Your Questions Answered #10

Footer with sections

vs. Flash (security and copyright)

HTML5 tags inline?

Offline + Storage

Correct markup with blockquote

Got a question for us?

Related Posts:

The article element

What the spec says

The smell test for going independent

Examples of in use

A bare-bones

Apple

A weblog-style

An with comments as nested s

Comments

An with s

Apple varieties

Red Delicious

Granny Smith

A containing s

Articles on: Fruit

Apple

Orange

Banana

Using for a widget

My Fruit Spinner

The pubdate attribute

The difference between and

Summary

Related Posts:

Your Questions Answered #7

Your Questions Answered #5

Headers and sidebars

Examples of
in use

An
with comments as nested
s

An
with
s

A
containing
s

Using
for a widget

The `pubdate` attribute

The difference between
and