HTML5 Doctor » section http://html5doctor.com helping you implement HTML5 today Tue, 27 Jul 2010 14:36:01 +0000 http://wordpress.org/?v=2.9.2 en hourly 1 Your Questions Answered #10 http://html5doctor.com/your-questions-answered-10/ http://html5doctor.com/your-questions-answered-10/#comments Fri, 09 Jul 2010 12:45:00 +0000 Richard Clark http://html5doctor.com/?p=1991 The clinic is getting busy with more HTML5 ailments. This week, we'll cover using sections within a footer, <canvas> vs. Flash security, why HTML5 elements are treated as inline, using offline with storage, and marking up block quotes.

]]>

Doctor treating a patient illustration The clinic is getting busy with more HTML5 ailments. This week, we’ll cover using sections within a footer, <canvas> 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 <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.

Share and Save: Twitter Digg Sphinn Reddit del.icio.us StumbleUpon Technorati Netvibes Facebook Google Bookmarks FriendFeed HackerNews LinkedIn NewsVine Tumblr

Your Questions Answered #10 originally appeared on HTML5 Doctor on July 9, 2010.

]]> http://html5doctor.com/your-questions-answered-10/feed/ 6 The article element http://html5doctor.com/the-article-element/ http://html5doctor.com/the-article-element/#comments Tue, 18 May 2010 14:00:27 +0000 Tom Leadbetter http://html5doctor.com/?p=1364 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.

]]>

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.

In addition to it’s content, an <article> element typically has a heading (often in a header element), and sometimes a footer. The easiest way to conceptualise <article> is to think of it’s 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 <article> element. We also use <article> on ‘static’ content pages, like the About and Contact pages, as <article> 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 <article> element, is content that makes sense on it’s 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 <article> in use

A bare-bones <article>

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

<article>
	<h1>Apple</h1>
	<p>The <b>apple</b> is the pomaceous fruit of the apple tree...</p>
	...
</article>

A weblog-style <article>

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

<article>
  <header>
    <h1>Apple</h1>
    <p>Published: <time pubdate="pubdate">2009-10-09</time></p>
  </header>
  <p>The <b>apple</b> is the pomaceous fruit of the apple tree...</p>
  ...
  <footer>
    <p><small>Creative Commons Attribution-ShareAlike License</small></p>
  </footer>
</article>

An <article> with comments as nested <article>s

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

<article>
  <header>
    <h1>Apple</h1>
    <p>Published: <time pubdate datetime="2009-10-09">9th October, 2009</time></p>
  </header>
  <p>The <b>apple</b> is the pomaceous fruit of the apple tree...</p>
  ...
  
  <section>
    <h2>Comments</h2>
    <article>
      <header>
      <h3>Posted by: Apple Lover</h3>
      <p><time pubdate datetime="2009-10-10T19:10-08:00">~1 hour ago</time></p>
    </header>
    <p>I love apples, my favourite kind are Granny Smiths</p>
    </article>
    
    <article>
      <header>
        <h3>Posted by: Oranges are king</h3>
        <p><time pubdate datetime="2009-10-10T19:15-08:00">~1 hour ago</time></p>
      </header>
      <p>Urgh, apples!? you should write about ORANGES instead!!1!</p>
    </article>
  </section>
</article>

An <article> with <section>s

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

<article>
  <h1>Apple varieties</h1>
  <p>The apple is the pomaceous fruit of the apple tree...</p>

  <section>
    <h2>Red Delicious</h2>
    <p>These bright red apples are the most common found in many supermarkets...</p>
  </section>

  <section>
    <h2>Granny Smith</h2>
    <p>These juicy, green apples make a great filling for apple pies...</p>
  </section>
    
</article>

A <section> containing <article>s

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

<section>
  <h1>Articles on: Fruit</h1>

  <article>
    <h2>Apple</h2>
    <p>The apple is the pomaceous fruit of the apple tree...</p>
  </article>

  <article>
    <h2>Orange</h2>
    <p>The orange is a hybrid of ancient cultivated origin, possibly between pomelo and tangerine...</p>
  </article>

  <article>
    <h2>Banana</h2>
    <p>Bananas come in a variety of sizes and colors when ripe, including yellow, purple, and red...</p>
  </article>
    
</section>

Using <article> for a widget

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

<article>
  <h1>My Fruit Spinner</h1>
  <object>
    <param name="allowFullScreen" value="true">
    <embed src="#" width="600" height="395"></embed>
  </object>
</article>

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 <article>. If present it indicates that the <time> element is the date the <article> 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 <article> element, or to the document as a whole.

The difference between <article> and <section>

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

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

  1. Would the content would make sense on it’s own in a feed reader? If so use <article>
  2. Is the content related? If so use <section>
  3. Finally if there’s no semantic relationship use <div>

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

Summary

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

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

Share and Save: Twitter Digg Sphinn Reddit del.icio.us StumbleUpon Technorati Netvibes Facebook Google Bookmarks FriendFeed HackerNews LinkedIn NewsVine Tumblr

The article element originally appeared on HTML5 Doctor on May 18, 2010.

]]> http://html5doctor.com/the-article-element/feed/ 33 Your Questions Answered #7 http://html5doctor.com/your-questions-answered-7/ http://html5doctor.com/your-questions-answered-7/#comments Tue, 20 Apr 2010 14:10:51 +0000 Richard Clark http://html5doctor.com/?p=1584 HTML5. In this article, we'll be covering a host of topics including AJAX, the eternal question of div or section, how to markup multiple blocks of content in a sidebar and using header with hgroup.]]>

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

HTML and AJAX

Arie asked:

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

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

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

Cheers, Rich

<div> or <section>?

Paul asked:

Hello

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

Thanks

Hi Paul,

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

Thanks, Bruce

HTML5 and IE6

Adam asked:

Greetings HTML5 Doctor,

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

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

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

Cheers, Rich

Multiple blocks in a sidebar

Bart asked:

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

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

Thanks, Tom

Header with <hgroup>

Diego asked:

Hi,

This structure is right?

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

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

Thanks for all,

Diego Tres

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

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

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

Cheers, Rich

Got a question for us?

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

Share and Save:

Twitter
Digg
Sphinn
Reddit
del.icio.us
StumbleUpon
Technorati
Netvibes
Facebook
Google Bookmarks
FriendFeed
HackerNews
LinkedIn
NewsVine
Tumblr



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

]]> http://html5doctor.com/your-questions-answered-7/feed/ 13 Your Questions Answered #5 http://html5doctor.com/your-questions-5/ http://html5doctor.com/your-questions-5/#comments Tue, 02 Mar 2010 14:30:55 +0000 Richard Clark http://html5doctor.com/?p=1400 img element, scaling video and a proposal for a field element. ]]>

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

Headers and sidebars

Ad asked:

Hello,

I have 2 questions:

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

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

Thank you so much for your time,
Ad Taylor

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

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

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

Hope that helps.

Cheers, Rich

HTML5 <img> element

Martijn asked:

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

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

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

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

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

In the dimension attribute section they go state the following.

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

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

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

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

Am I missing something or is the specification missing this?

Looking forward to getting your prescription ;)

Kind Regards, Martijn

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

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

Thanks, Bruce

Section and Sectioning

Yanoo asked:

Hi,

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

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

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

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

Thanks, Bruce

Scaling the Video

Ian asked:

Hi there,

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

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

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

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

Many thanks,

Ian

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

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

Cheers, Rich

We need a <field> tag

John wrote in and proposed a field element:

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

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

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

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

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

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

I would love to hear your thoughts on this.

Thanks!
John

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

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

Regards, Mike

Got a question for us?

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

Share and Save:

Twitter
Digg
Sphinn
Reddit
del.icio.us
StumbleUpon
Technorati
Netvibes
Facebook
Google Bookmarks
FriendFeed
HackerNews
LinkedIn
NewsVine
Tumblr



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

]]> http://html5doctor.com/your-questions-5/feed/ 12 The section element http://html5doctor.com/the-section-element/ http://html5doctor.com/the-section-element/#comments Fri, 11 Sep 2009 12:38:17 +0000 Bruce Lawson http://html5doctor.com/?p=858 HTML5 and writing about how we do it. And we realise that we've been using the section element incorrectly all this time. Sorry.]]>

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

<section>
<h1>Any level of heading</h1>
rest of the content
</section>

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

Share and Save:

Twitter
Digg
Sphinn
Reddit
del.icio.us
StumbleUpon
Technorati
Netvibes
Facebook
Google Bookmarks
FriendFeed
HackerNews
LinkedIn
NewsVine
Tumblr



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

]]> http://html5doctor.com/the-section-element/feed/ 82 Your questions answered #1 http://html5doctor.com/your-questions-answered-1/ http://html5doctor.com/your-questions-answered-1/#comments Mon, 06 Jul 2009 10:59:36 +0000 Richard Clark http://html5doctor.com/?p=390 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.]]>

Doctor treating a patient illustration 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.

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 <aside> or <figure> 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 <div>’s around their <header> 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 <content> tags? Can I serve a SWF Flash file using <VIDEO> tags?

Regards Darren

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

As for the second part to your question, you *can’t* use a SWF file natively as the source to the <video> 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 <video> tag.

First you’ll use the <video> 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 <object> and <embed> combo. This is because IE8 and lower doesn’t support the <video> you’re going to need to fall back on something that works.

Make sure you read Tom’s article about the <video> 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 <aside> 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.

Share and Save:

Twitter
Digg
Sphinn
Reddit
del.icio.us
StumbleUpon
Technorati
Netvibes
Facebook
Google Bookmarks
FriendFeed
HackerNews
LinkedIn
NewsVine
Tumblr



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

]]> http://html5doctor.com/your-questions-answered-1/feed/ 8 Designing a blog with html5 http://html5doctor.com/designing-a-blog-with-html5/ http://html5doctor.com/designing-a-blog-with-html5/#comments Tue, 30 Jun 2009 14:00:21 +0000 Bruce Lawson http://html5doctor.com/?p=47

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

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

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

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

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:

structure chart before redesign

with this:

structure chart after redesign

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:

date picker pops up next to input field

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.

red-bordered browser message 'You have to specify a value'

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.

A note on screenreaders and HTML 5

I hope screenreaders are ready for these new interactions; I asked the html 5 group to formally invite screenreader vendors to participate in the specification; to my knowledge, none have done so.



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;}

IE layout

There’s one gotcha about styling HTML 5 pages in IE: it doesn’t work. You can force it to quite easily with a JavaScript hack document.createElement('element name'). (Lachlan Hunt gets to the bottom of why IE needs this.)

For your convenience, Remy Sharp has written an HTML 5 enabling script which I use in the header to conjure all the missing elements into existence all at once.

But let’s be clear: this won’t work if your IE user doesn’t have JavaScript turned on. How much of that’s a big deal that is for you to decide. Pragmatically, it seems to me that the sites that will benefit the most from HTML 5’s new “Ajax”-style features, such as drag-and-drop, are the sites that currently have no hope of working without JavaScript.


Firefox 2 and Camino 1 layout

Firefox 2 and Camino 1 both use Gecko 1.9 which has a bug and so gets grumpy if you don’t serve the page as XHTML. (Go figure; that’s almost enough to trigger a negative reality inversion and you know how bad that can be). However, Firefox and Camino users upgrade frequently so Firefox is in version 3, while Camino 2 beta is out, so the problem will soon cease to exist. (Read more at How to get HTML5 working in IE and Firefox 22 by Remy Sharp.)



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

The blog home page

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

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

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

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

Anatomy of a blog post

diagram of article structure; explanation follows

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

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

Data about the article

Following the content there is some “metadata” about the post: what category it’s in, how many comments there are. I’ve marked this up as footer. I previously used aside which “represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content” but decided that it was too much of a stretch; data about a post is intimately related.

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


Comments

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

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

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


Times and dates

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

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

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

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

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

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

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

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


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

Share and Save:

Twitter
Digg
Sphinn
Reddit
del.icio.us
StumbleUpon
Technorati
Netvibes
Facebook
Google Bookmarks
FriendFeed
HackerNews
LinkedIn
NewsVine
Tumblr



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

]]> http://html5doctor.com/designing-a-blog-with-html5/feed/ 140