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.

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 <section> within <footer>. but <footer> is a sectioning root anyway <footer> 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 <footer> element. There are also some more examples in the spec.

Cheers, Rich

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

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:

<blockquote>This is a blockquote.</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:

<!doctype html>
<meta charset=utf-8>
<title>blockquote test</title>
<blockquote>Tiger tiger burning bright</blockquote>

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

To summarise, it would be valid not to further mark up content within a <blockquote>, but authors are encouraged to use a <p> (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.

Setting the DOCTYPE

HTML 5, when used as plain HTML rather than its XHTML 5 sibling doesn’t need a DOCTYPE. But all browsers do, otherwise they go into Quirksmode, which you don’t want: the collision of HTML 5 and Quirksmode is like matter and anti-matter meeting, and will cause a negative reality inversion that will make your underwear catch fire.

You’ve been warned, so at the top of your document, you need the line <!DOCTYPE html>.

Some sites “use” HTML 5, when in actual fact all they’ve done is take their existing code and change the DOCTYPE. That’s fine and dandy if you’ve been using valid, semantic code as HTML 5 is very similar to valid HTML 4.01. Eric Meyer mentions small differences like “not permitting a value attribute on an image submit”, and there are a few differences between the languages, summarised in the document HTML 5 differences from HTML 4.

However, I don’t want simply to rebadge my existing code, but to use some of the new structural elements now.

Using some new structural elements

My blog – like millions of others – has a header denoted by <div id="header">, a footer <div id="footer">, some articles (wrapped by an area called “content”, <div id="content">) and some navigation (wrapped up in an area called “sidebar” <div id="sidebar">). Most sites on the Web have similar constructs, although depending on your choice they might be called "branding" or "info" or "menu", or you might use the equivalent words in your own language.

Although these all have very different functions within the page, they use the same generic div in the markup. as HTML 4 has no other way to code them. HTML 5 has new elements for distinguishing these logical areas: header, nav, footer and friends. (There’s more on this in an artice by Lachlan Hunt on A List Apart: A Preview of HTML 5.)

The overall aim is to replace this structure:

with this:

It’s a simple matter to change the HTML divs into the new elements. The only difficulty I had was deciding which element to use to mark up my sidebar, as it also includes a search field and “colophon” information as well as site-wide navigation. I decided against the aside element, as the spec says it “represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content”, but it’s nevertheless content rather than navigation. So I decided to go for the nav element as the closest fit.

I’ve wrapped the main content in a section element (previously I’d kept it as a div). section is defined in the spec

The section element represents a generic document or application section. A section, in this context, is a thematic grouping of content, typically with a heading, possibly with a footer.

Please note: I no longer recommend wrapping the whole content area in a section element, and suggest that you use a div element. Read more about using section appropriately.

In this case, the “generic document section” is that of main content. I’ve retained an id so that a skip links feature will work, although I hope that in the future, assistive technology will offer an automatic way for people to go to the first section or article.

My fellow HTML 5 doctor, Remy Sharp, also notes that if you retain the div, Internet Explorer without JavaScript would style the div, but none of the other content, making the site very hard to read.

New form attributes

As well as the main structural item on the page, I’ve added some new attributes on input elements in the comments form.

HTML 5 was designed to reflect what developers actually do rather than to reflect a philosophical purity, and that’s very clearly manifested in the new attributes which mean the browser takes up much of the work currently done by developers re-inventing validation routines in JavaScript. (Extending forms functionality was how the HTML 5 spec began).

So I amended the email input field in the comments to be input type="email" which means that when the user submits the form, an HTML 5-aware browser will use built-in validation routines to check that it’s in the correct format, without any JavaScript. Check it out in the current version of Opera, as that the only full implementation at the time of writing (June 2009), and note that it also adds a “mail” icon in the input field as a cue to the user.

There are similar input validation routines triggered by some of the new input types, such as url (which I use on the field that asks for the user’s web address), number and pattern which compares the input with an arbitrary regular expression.

Another good example is input type="date", which pops up a calendar widget/ date picker when the user focusses on the input field. You can test the date picker, or here’s a screenshot from Opera 9.6:

A very useful new attribute I used on both input fields for commenter’s name and email address, and the comment textarea was type="required" which generates a message on submission if the fields are left blank. Each different localisation of a browser would need to have a different message, and it’s not (so far) customisable by the developer.

The good thing with all this new form fabulousness is it’s all formed around new attributes on an exisiting element, so people using older browsers just see a plain old input field.

Laying out the new elements

It’s not too hard to layout the new elements. In all the non-IE browsers, you can lay out anything using CSS – even a nonsense element. One gotcha is that that the current crop of browsers have no “knowledge” of these elements, although support is improving all the time.

All browsers have default settings for the elements they “know about”—how much padding, margin they element gets, does it display as a block or inline?. (Here’s a sample default stylesheet.) Unless over-ridden by CSS, these defaults apply. But the browsers don’t know about header, nav and the like, so have no defaults to apply to them.

I got terrible rendering oddities until I explicitly told the browsers

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

What’s the point of those new structural elements?

Well, they add semantics to the page. The browser now knows which area of your site is the header or the footer because there are header and footer elements, whereas div might be called “branding” and “legal”, or even “en-tete” and “pied-de-page” or “kopfzeile” and “fusszeile“.

But so what?

Robin Berjon expressed it beautifully in a comment on A List Apart:

Pretty much everyone in the Web community agrees that “semantics are yummy, and will get you cookies”, and that’s probably true. But once you start digging a little bit further, it becomes clear that very few people can actually articulate a reason why. So before we all go another round on this, I have to ask: what’s it you wanna do with them darn semantics?

The general answer is “to repurpose content”. That’s fine on the surface, but you quickly reach a point where you have to ask “repurpose to what?” … I think HTML should add only elements that either expose functionality that would be pretty much meaningless otherwise (e.g. canvas) or that provide semantics that help repurpose for Web browsing uses.

In my view, there are a couple of things I want to do with those semantics. The first is for search engine use; it’s easy to imagine Messrs Google or Yahoo! giving lower weighting to content in footer elements, or extra weight to content in the header. The second reason is to make the site navigable for people with disabilities. People with learning difficulties might instruct their browser always to put the articles before the navigation, for example. User agents might very well have a keyboard shortcut which jumped straight to the nav for example, or jumped straight past the navigation, in a programmatic implementation of “skip links“.

Which brings me to…

Further refining the HTML 5 structure

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

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

<div id="footer">
  <ul>
     <li>copyright</li>
     <li>sitemap</li>
     <li>contact</li>
     <li>to top</li>
  </ul>
<div>

<footer>
  <ul>
     <li>copyright</li>
     <li>sitemap</li>
     <li>contact</li>
     <li>to top</li>
  </ul>
</footer>

<section>
   Section content appears here.
   <footer>
   Footer information for section.
   </footer>
</section>

<article>
   Article content appears here.
   <footer>
   Footer information for article.
   </footer>
</article>