Abstract#section1
The web is constantly evolving. New and innovative websites are being created
every day, pushing the boundaries of HTML in every direction. HTML 4 has
been around for nearly a decade now, and publishers seeking new techniques to
provide enhanced functionality are being held back by the constraints of
the language and browsers.
To give authors more flexibility and interoperability, and enable more interactive
and exciting websites and applications, HTML 5 introduces and enhances a wide range of features including form controls, APIs, multimedia, structure, and semantics.
Work on HTML 5, which commenced in 2004, is currently being carried out in
a joint effort between the
W3C HTML
WG and
the WHATWG.
Many key players are participating in the W3C effort including representatives
from the four major browser vendors: Apple, Mozilla, Opera, and Microsoft;
and a range of other organisations and individuals with many diverse interests
and expertise.
Note that the
specification is still a work in progress and quite a long
way from completion. As such, it is possible that any feature discussed in
this article may change in the future. This article is intended to provide
a brief introduction to some of the major features as they are in the current
draft.
Structure#section3
HTML 5 introduces a whole set of new elements that make it much easier to
structure pages. Most HTML 4 pages include a variety of common structures,
such as headers, footers and columns and today, it is fairly common to mark
them up using div elements, giving each a descriptive id or class.
Diagram illustrates a typical two-column layout marked up using divs with id and class attributes. It contains a header, footer, and horizontal navigation bar below the header. The main content contains an article and sidebar on the right.
The use of div elements is largely because current versions of
HTML 4 lack the necessary semantics for describing these parts more specifically.
HTML 5 addresses this issue by introducing new elements for representing
each of these different sections.
The div elements can be replaced with the new elements: header, nav, section, article, aside, and footer.
The markup for that document could look like the following:
<body> <header>...</header> <nav>...</nav> <article> <section> ... </section> </article> <aside>...</aside> <footer>...</footer> </body>
There are several advantages to using these elements. When used in conjunction
with the heading elements (h1 to h6), all of these provide
a way to mark up nested sections with heading levels, beyond the six levels
possible with previous versions of HTML. The specification includes a
detailed algorithm for generating an outline that takes the structure of these elements
into account and remains backwards compatible with previous versions. This
can be used by both authoring tools and browsers to generate tables of contents
to assist users with navigating the document.
For example, the following markup structure marked up with nested section and h1 elements:
<section>
<h1>Level 1</h1>
<section>
<h1>Level 2</h1>
<section>
<h1>Level 3</h1>
</section>
</section>
</section>
Note that for better compatibility with current browsers, it is also possible
to make use of the other heading elements (h2 to h6) appropriately in place
of the h1 elements.
By identifying the purpose of sections in the page using specific sectioning
elements, assistive technology can help the user to more easily navigate
the page. For example, they can easily skip over the navigation section or
quickly jump from one article to the next without the need for authors to provide
skip links. Authors also benefit because replacing many of the divs in the
document with one of several distinct elements can help make the source code
clearer and easier to author.
The header element represents the header of a section. Headers may contain
more than just the section’s heading—for example it would be reasonable
for the header to include sub headings, version history information or bylines.
<header> <h1>A Preview of HTML 5</h1> <p class="byline">By Lachlan Hunt</p> </header>
<header> <h1>Example Blog</h1> <h2>Insert tag line here.</h2> </header>
The footer element represents the footer for the section it applies to. A
footer typically contains information about its section such as who wrote it,
links to related documents, copyright data, and the like.
<footer>© 2007 Example Inc.</footer>
The nav element represents a section of navigation links. It is suitable
for either site navigation or a table of contents.
<nav> <ul> <li><a href="/">Home</a></li> <li><a href="/products">Products</a></li> <li><a href="/services">Services</a></li> <li><a href="/about">About</a></li> </ul> </nav>
The aside element is for content that is tangentially related to the content
around it, and is typically useful for marking up sidebars.
<aside> <h1>Archives</h1> <ul> <li><a href="/2007/09/">September 2007</a></li> <li><a href="/2007/08/">August 2007</a></li> <li><a href="/2007/07/">July 2007</a></li> </ul> </aside>
The section element represents a generic section of a document or application,
such as a chapter, for example.
<section> <h1>Chapter 1: The Period</h1> <p>It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of Light, it was the season of Darkness, ...</p> </section>
(Excerpt from A Tale of Two Cities)
The article element represents an independent section of a document, page
or site. It is suitable for content like news or blog articles, forum posts
or individual comments.
<article id="comment-2"> <header> <h4><a href="#comment-2" rel="bookmark">Comment #2</a> by <a href="http://example.com/">Jack O’Niell</a></h4> <p><time datetime="2007-08-29T13:58Z">August 29th, 2007 at 13:58</time> </header> <p>That's another great article!</p> </article>
Video and audio#section4
In recent years, video and audio on the web has become increasingly viable
and sites like YouTube, Viddler, Revver, MySpace, and dozens of others are
making it easy for anyone to publish video and audio. However, since HTML currently
lacks the necessary means to successfully embed and control multimedia itself,
many sites are relying on Flash to provide that functionality. Although it
is possible to embed multimedia using various plug-ins (such as QuickTime,
Windows Media, etc.), Flash is currently the only widely deployed plugin
that provides a cross-browser compatible solution with the desired APIs for
developers.
As evidenced by the various Flash-based media players, authors are interested
in providing their own custom-designed user interfaces, which generally allow
users to play, pause, stop, seek, and adjust volume. The plan is to provide
this functionality in browsers by adding native support for embedding video
and audio and providing DOM APIs for scripts to control the playback.
The new video and audio elements make this really easy. Most of the APIs
are shared between the two elements, with the only differences being related
to the inherent differences between visual and non-visual media.
Both Opera and WebKit have
released builds with partial support for the video element. You may download
the experimental
build of Opera or a recent nightly
build of WebKit to try out these examples. Opera includes support for Ogg
Theora and WebKit supports all the formats that are supported by QuickTime,
including third party codecs.
The simplest way to embed a video is to use a video element and allow
the browser to provide a default user interface. The controls attribute is
a boolean attribute that indicates whether or not the author wants this UI
on or off by default.
<video src="video.ogv" controls poster="poster.jpg" width="320" height="240"> <a href="video.ogv">Download movie</a> </video>
The optional poster attribute can be used to specify an image which will be
displayed in place of the video before the video has begun playing. Although
there are some video formats that support their own poster frame feature, such
as MPEG-4, this provides an alternative solution that can work independently
of the video format.
It is just as simple to embed audio into a page using the audio element. Most
of the attributes are common between the video and audio elements, although
for obvious reasons, the audio element lacks the width, height, and poster attributes.
<audio src="music.oga" controls> <a href="music.oga">Download song</a> </audio>
HTML 5 provides the source element for specifying alternative
video and audio files which the browser may choose from based on its media type
or codec support. The media attribute can be used to specify a
media query for selection based on the device limitations and the type attribute
for specifying the media type and codecs. Note that when using the source elements,
the src attribute needs
to be omitted from their parent video or audio element
or the alternatives given by the source elements will be ignored.
<video poster="poster.jpg"> <source src="video.3gp" type="video/3gpp" media="handheld"> <source src="video.ogv" type="video/ogg; codecs=theora, vorbis"> <source src="video.mp4" type="video/mp4"> </video> <audio> <source src="music.oga" type="audio/ogg"> <source src="music.mp3" type="audio/mpeg"> </audio>
For authors who want a little more control over the user interface so that
they can make it fit the overall design of the web page, the extensive API
provides several methods and events to let scripts control the playback of the
media. The simplest methods to use are the play(), pause(), and setting currentTime to rewind to the beginning. The following example illustrates the use of these.
<video src="video.ogg" id="video"></video>
<script>
var video = document.getElementById("video");
</script>
<p>
<button type="button" onclick="video.play();">Play</button>
<button type="button" onclick="video.pause();">‖Pause</button>
<button type="button" onclick="video.currentTime = 0;">≪Rewind</button>
</p>
There are many other attributes and APIs available for the video and audio
elements that have not been discussed here. For more information, you should
consult the current
draft specification.
Document representation#section5
Unlike previous versions of HTML and XHTML, which are defined in terms of
their syntax, HTML 5 is being defined in terms of the Document Object Model
(DOM)—the tree representation used internally by browsers to represent the
document. For example, consider a very simple document consisting of a title,
heading and paragraph. The DOM tree could look something like this:
The DOM tree includes a title element in the head and h1 and p elements in the body.
The advantage of defining HTML 5 in terms of the DOM is that the language
itself can be defined independently of the syntax. There are primarily two
syntaxes that can be used to represent HTML documents: the HTML serialisation
(known as HTML 5) and the XML serialisation (known as XHTML 5).
The HTML serialisation refers to the syntax that is inspired by the SGML
syntax from earlier versions of HTML, but defined to be more compatible with
the way browsers actually handle HTML in practice.
<!DOCTYPE html> <html> <head> <title>An HTML Document</title> </head> <body> <h1>Example</h1> <p>This is an example HTML document. </body> </html>
Note that like previous versions of HTML, some tags are optional and are automatically
implied.
The XML serialisation refers to the syntax using XML 1.0 and namespaces,
just like XHTML 1.0.
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>An HTML Document</title>
</head>
<body>
<h1>Example</h1>
<p>This is an example HTML document.</p>
</body>
</html>
Excluding differences in whitespace and the presence of the xmlns attribute,
those two examples are equivalent.
Browsers use the MIME type to distinguish between the two. Any document served
as text/html must conform to the requirements for the HTML serialisation
and any document served with an XML MIME type such as application/xhtml+xml must conform to the requirements for the XML serialisation.
Authors should make an informed choice about which serialisation to use,
which may be dependent on a number of different factors. Authors should not
be unconditionally forced to use one or the other; each one is optimised
for different situations.
Benefits of using HTML#section6
- Backwards compatible with existing browsers
- Authors are already familiar with the syntax
- The lenient and forgiving syntax means there will be no user-hostile “Yellow
Screen of Death” if a mistake accidentally slips through - Convenient shorthand syntax, e.g. authors can omit some tags and attribute values
Benefits of Using XHTML#section7
- Strict XML syntax encourages authors to write well-formed markup, which
some authors may find easier to maintain - Integrates directly with other XML vocabularies, such as SVG and MathML
- Allows the use of XML Processing, which some authors use as part of their
editing and/or publishing processes
How to contribute#section8
Work on HTML 5 is rapidly progressing, yet it is still expected to continue
for several years. Due to the requirement to produce test cases and achieve
interoperable implementations, current estimates have work finishing in around
ten to fifteen years. During this process, feedback from a wide range of
people including, among others, web designers and developers, CMS and authoring
tool vendors, and browser vendors is vital to ensure its success. Everyone
is not only welcome, but actively encouraged to contribute feedback on HTML5.
In addition to the specification, there are several other related efforts
designed to help people better understand the work.
- The Differences from
HTML 4 describes the changes that have occurred since
the previous version of HTML. - The HTML Design Principles discuss principles used to help make decisions,
and will help you understand the rationale behind many of the current
design decisions. - The Web Developer’s Guide
to HTML 5, which only recently began, is being
written to help web designers and developers understand everything they
need to know to write conforming HTML 5 documents, and provide guidelines
and describe best practices.
There are numerous venues through which you may contribute. You may join the
W3C’s HTML WG and subscribe/contribute
to the HTML WGmailing lists or
wiki. You may also subscribe and
contribute to the any of the
WHATWG mailing lists, post
to the WHATWG forum, post comments or
write articles on the WHATWG
blog. 
… if you read Roger Johansson’s blog
http://www.456bereastreet.com/archive/categories/html_5/
It will be interesting to see how this all shakes out.
You know, I really don’t understand the point. What was *really* wrong with the example using divs? Surely developing such specific tags (as article, aside, nav etc) is only going to end up limiting the scope in future – and once again we will be back to square one – trying to get around the limitations of the spec.
I would think the better approach would be to create a spec that provides better support for microformats, while using a bare minimum of tags.
Did I read that right? The HTML 5 spec isn’t expected to be done for another 10-15 years? And then how long until browsers support it? A decade is an incredibly long time in web-years — I don’t see how this spec can even hope to still be relevant if it won’t see the light of day for that long.
Ditto #2. If ease is the purpose of the HTML 5 spec, clearly it should have come… last century (the XHTML 1.0 spec officialized in 2000). It is also interesting to note that HTML 5 will be a rather major step in “devolution,” eschewing the abstraction of structure and the implementation of microformats for neatly named tags and pseudo-embeds. I doubt web designers are going to adapt backwards in 2007 A.D.
I’m really wondering, is this possible?
I agree with #3…. just doing the math, html 4 has been around for 10 years and another 15 for html 5? Plus time for all the browsers to catch up, with the rate of other devices besides desktop computers coming into play, having the same html version for near 30 years seems, well I’m just wondering. How will these things possibly apply in 15 years?
I’m still not happy with the SGML version that allows unclosed tags. This burdens people with having to learn which elements need a closing tag and which ones don’t. With XHTML, it’s clear-cut: all of them need one. Also, you can at least check an XHTML file for well-formedness without a DTD. SGML requires a DTD for any sort of validation.
Another one who’s slightly worried about the time frame being proposed.
I’m of two minds on this ten to fifteen year time frame thing.
First, I assume that includes time for the implementation, testing, & feedback cycle, so that the end result of 10-15 is interoperable cross-browser implementations.
Part of me thinks that will be too little too late, that if the various parties involved hadn’t been off doing their own thing came together as a unified group a little earlier, having 2010 or so as an end point would have been easy to stomach. By 2017, development habits will have had time to become firmly entrenched (IE6 only had 5 years, look how that went), and transitioning to a newer non-backwards-compatible HTML dialect will be a huge uphill battle. To draw a comparison, XHTML2 is (to be euphemistic) somewhat lacking in relevancy to those of us building web sites day to day because it doesn’t solve enough problems and it abandons the past. Since the new stuff in HTML5 is basically just codifying what we’re already doing in other ways, could that which looks promising today suffer the same fate, given enough time?
But the other part of me wonders, what’s the hurry? At this point we’re not exactly being held back by the lack of these elements in the current drafts. Progress isn’t breakneck anymore, and the rhetorical “web years” from back in the 90’s don’t apply. We can afford to take some time and do it right.
Still. 10 years? That is a rather lot of time. It better really be worth the wait.
First, to be snarky, who needs “section” when we’ve got this little section DIVider already?
What is the point of adding new elements such as section, header, aside, et al? If one browser (ahem) still isn’t supporting simple things like :before, why would be expect its dominant 800-pound monkey ass to jump now?
I want to be using things that are available to me *now* through *approved* specs, that other browsers already support; but I’m stuck with over-verbose methods or out-and-out hacks to bring the previously mentioned ugly gorilla into line so its users get a “modern” experience.
The 10-15 year time frame includes the time required stabilize the spec, produce the test suite containing thousands of tests and achieve interoperable implementations. Browsers are expected to implement HTML5 during this time, not wait until after. Indeed, they have already begun, which is why we’re already seeing early implementations of video, audio, and we have had canvas for a long time already.
For comparison, look at CSS 2.1. It’s been 10 years since CSS2 was started and that’s still only a candidate recommendation. However, it’s been relatively stable for a few years now, while still being updated based on implementation feedback.
Programming is going more dynamic, generic based. Divs can be anything, I am not sure about the new header, footer, section tags. It is really about typing HTML in HTML5 and I think at that level it is not really needed. Flexibility, the ability to control context for the user (back/forward/navs) and textual goodness make the web fun. I think XHTML and HTML are fine as a base now. I really like the video and audio tags but again, typed… object, embed are much more generic. What about flash? flash tag? what about silverlight? ria tag to fit both. You see the dilemma. if you just keep it to divs, maybe clean up object and embed to one widget tag or object tag. Not sure I like much in the HTML5 spec especially possibly calling SQL right from html, what the eff?
http://www.crockford.com/html/ I really liked the things in this article.
I’m quite surprised by the negative reactions towards the new elements. div elements are indeed more generic, and thus fail to add much semantic meaning to the document.
A header is not much different from a div. Except it adds semantic meaning to a certain portion of your document. This is really a good thing, not a bad thing.
I’ve written a more complete reaction “here”:http://www.onderhond.com/blog/onderhond/html5-prospects as I believe these type of comments deserve some extra attention.
Finally the browser vendors focused on browser features like tabs and RSS readers. Now, the web designers started learning CSS/JavaScript language to build their own nice applications on top of the existing frameworks using Ajax. But HTML itself grew hardly at all in the next eight years. I think that from now one, this controversial subject can be more discussed.
This is good news. HTML was lagging behind a little, compared to the other vast improvements made with other web technologies. The additions look good. It’ll make life easier for many designers and developers. I look forward to it.
While this article was nice, I was hoping for a list of features that were already being implemented, such as Opera’s new “Google Suggests”:http://dev.opera.com/articles/view/an-html5-style-google-suggest/ like feature. This looks pretty danged cool, and I’ve implemented it in one section of our code base.
Are there ANY HTML 5 features being implemented in Firefox 3? I haven’t been able to find any mention of such and that leads me to believe that nothing will be coming.
One feature I would like to see in HTML 5 is the ability to mark elements as cacheable for the browser. For many people, headers, footers, navigation, etc. do not change from page to page. Why can’t we tell the browsers to cache those elements?
From this article (I still need to dig deeper into HTML 5), I can generally support the current proposed changes because it seems it deals with markup.
A lot of suggestions for “HTML 5”, such as Radoslav Stankov linked to crockford.com always seem to forget they’re talking about HTM(arkup)L and instead go off on a tangent talking about how client side scripting (JavaScript) or CSS should have improvement ‘x’ or ‘y’. But that’s not HTML, that’s scripting and styling respectfully and needs to be addressed separately.
Though, I’m not sure of the importance or need for new tags such as “section”, “header”, “footer” and “aside”, but I really like the “Nav” tag. In general, I guess guess it won’t hurt anything as long as said tags don’t become required attributes where people start adding them for the same of adding them.
Cheers!
About tags like
One one hand, having specialized header, footer, etc. tags seems a bit bloated, but on the other hand, having headers and footers render in a rational way, as a sort of “scaffold” before the CSS is plugged in, sure would be nice.
Lachlan, please help me understand why you don’t think HTML 5 will seriously confuse authors by redefining the semantics of numbered headings. In HTML 5, H1 will have the same semantic meaning as H6.
1. This means lower value headings can be used before higher value headings. For example, this will be valid in HTML 5:
[body]
[h6]heading[/h6]
[h1]heading[/h1]
[/body]
2. Skipping heading levels will be valid in HTML 5. For example:
[body]
[h1]heading[/h1]
[h3]heading[/h3]
[/body]
(Using [ ] instead of < > in above examples. Sorry, I have no clue how to do code examples using Textile syntax.)
bq. A header is not much different from a div. Except it adds semantic meaning to a certain portion of your document.
Does it? What does “header” actually _mean_? What does it tell me? It tells me, “This is a bunch of stuff that goes at the top”. That’s all header means. I’m not sure that’s terribly helpful.
If we’re going to muck around with new markup, it should actually be meaningful and not just convenient. I want my markup to give additional clues about the content itself, both informational and emotional, not merely support page layout convention. That doesn’t help anyone.
Lachlan, please help me understand why you don’t think HTML 5 will seriously confuse authors by redefining the semantics of numbered headings. In HTML 5, H1 will have the same semantic meaning as H6.
1. This means lower value headings can be used before higher value headings. For example, this will be valid in HTML 5:
heading
heading
2. Skipping heading levels will be valid in HTML 5. For example:
heading
heading
I’m also torn – it’s generally a great thing that divs and spans have no semantic meaning – it allows us designers more flexibility… but what about the user? If every website were marked up with consistent header and footer tags it would empower the average user (or the _disabled_ user) to apply their own custom stylesheets with much more predictable results – there are plenty of accessibility benefits there.
Headers tell you more than “stuff that goes on the top”.
A header gives you information about the content which is usefull to know before starting the actual content. It contains all elements that should best be known before starting the content.
Same with the footer, which contains all information related to the content but is useful only as an after-thought. As we read from top to bottom, a header is usually positioned at the top and a footer at the bottom, but the semantic meaning is of course more detailed.
A header is always an intro to content, while a footer is an outro. Same goes with site headers, which display all info relevant to travelling around the site and giving the user info about the site.
It has more semantic power than a
The “charter”:http://www.w3.org/2007/03/HTML-WG-charter.html calls for 3 years, not 10. We’ll see which plan is closer to reality when we get there, I suppose, but I’m betting it’s closer to 3 than 10.
… were spent getting all the browser manufacturers to get their _presently existing browsers_ to follow the _presently existing spec_, the life of every web designer out there would be made 10x better.
I think there’s plenty to be said both ways regarding HTML5, but it doesn’t change the fact that if ie6 was not a part of my life, id get 3x more done. Surely there’s more that can be done to get users off this and other older browsers. Thats where I’d like to see some more effort (another NYT ad, maybe, moz?).
The web world does an awful good job of making new problems before properly fixing old ones.
How about equal time for XHTML 2? Further reading: X/HTML 5 Versus XHTML 2
bq. The HTML 5 spec isn’t expected to be done for another 10-15 years? And then how long until browsers support it?
I believe Dave’s right: the spec won’t be considered finished until there are two (complete?) interoperable browser implementations. The 15 year period includes browser support. You should be able to use some of its new features before then.
Indeed, with the backwards-compatibility stuff, you can start serving documents that are technically HTML 5 already: I believe Daring Fireball is published in HTML 5. You just won’t see any benefit to using elements like <section> yet.
Developing a new version of just HTML seems like a waste of time to me. In 10-15 years (assuming the writer of this article wasn’t being sarcastic) I imagine that XHTML will be more of a standard than HTML will be. XHTML is so much more powerful, both in potential and how it’s currently used… in 10 years, I can’t really imagine anyone really wanting to use HTML when you think of all the potential XHTML has.
I agree that aside, header, footer, etc. are useful, but do we need new elements for these? What about a role attribute? For example:
. The role attribute (unlike class or id) could have a defined set of allowed values (aside, header, footer, etc.). This would add the semantics of the proposed elements while maintaining backwards compatibility with user agents that only understand div.
what about the browsers catching up to the current specifications?
I agree with #27 on that. More focus should be on browser compatibility with the current markup of both HTML and CSS.
A number of comments suggest that we’ll never see the benefits of HTML 5 but that’s simply not true.
#
There are more success stories if you follow the working group discussions (blogs, mailing list, IRC) and there is clear support from Apple, Google, Mozilla, and Opera to implement HTML 5 now, not later. Microsoft hasn’t quite joined the implementation game yet but is involved (Chris Wilson is the chair of the W3C’s HTML Working Group which is working on HTML 5 along with WHATWG.)
Is HTML 5 the solution to all of our HTML problems? Of course not, but HTML 5 is in a better position than where we were “four years ago with XHTML 2”:http://www.zeldman.com/daily/0103b.shtml#skyfall .
Finally I’d like to add that your opinions matter and will be seen by the W3C HTML Working Group & WHATWG. The spec editors (Ian Hickson and Dave Hyatt) are committed to taking not only feedback from the working group discussions but also “feedback from the wider web such as blogs and publications like A List Apart”:http://lists.w3.org/Archives/Public/public-html/2007Apr/0563.html .
It is really great that this discussion is happening in public across the internet and if you have ideas on how to improve HTML 5 then I hope you’ll stop by. On top of the links Lachlan provided in his article, there are some other public resources:
* relevant “IRC channels”:http://krijnhoetmer.nl/irc-logs/
* “HTML 5 issue tracker”:http://www.w3.org/html/wg/tracker/
Finally, “we can always use volunteers”:http://www.w3.org/html/wg/#who who want to provide clearly defined use cases, test cases that prod the spec in every which direction, and people to help translate our treatise on browser behavior to web author accessible prose.
Look, I’m all for advancing the Web. But we’re *currently* held back by IE on *today’s* approved standards. I would love to use some things available to me now — but I usually can’t because I have to support the 70+% user out there on it. Until that turd is flushed (as in dead) or polished (as in catching up with the rest of the kids), we’re stuck with the stink of old ways.
Thank you, Shawn!
Folks, please read “Shawn’s comment”:http://www.alistapart.com/comments/previewofhtml5?page=4#33 and think about it.
I have to say, I’m rather disappointed. Not at the amount of work which has gone into this (which is commendable), but rather the short-sightedness of those involved.
Listen to people like Bert Bos & you’ll hear them say that *13 years ago* (!), they couldn’t even dream of how CSS would be used by people. They can’t even believe that it *still exists*. If CSS had been built to solve the problems of 1994 and only those problems, he probably would have been right.
13 years later, the HTML working groups involved in HTML5 have decided to approach things differently. The introduction of new elements like “header”, “footer”, “aside” and “section” reek of this, let alone the “article” element.
Extolling the virtues of “semantic markup” (as a general concept du jour) doesn’t cut it as an argument for these new elements. What real world benefits can we derive from their meaning?
More critically, what exactly is the _goal_ of HTML5. I’ve heard some people say that the goal is:
bq. more interoperability when recovering from errors [1]
That’s fair enough, but mixed in with those frothing at the mouth over these new elements, things are becoming more and more hazy as to what HTML5 is trying to solve. I’d like to hear a clear statement on that.
fn1. Karl Dubost in “Why HTML 5 Specification Matters?”:http://www.w3.org/QA/2007/07/why-html-5-matters.html
I am all for HTML V. It will give us Web coders and, of course, the browser makers, more tags to misinterpret and misapply. For sure, having the *aside* tag will allow me to _semantical-up_ my pages where I have no possibility for that now.
I hope the HTML V spec takes a long time to put together because it will keep a certain class of person off the streets, safe from wandering dreamily, in mortal danger from passing vehicles.
Meanwhile, I am still waiting for a leading or non-leading browser to implement HTML 4.01. Fixed table headers / footers? Column alignment on language-specific decimals? Object? Cite? Char? And so on.
Not that this matters much. HTML is simply structure and our job is to keep structure as simple as possible. CSS, JavaScript, and other technologies build best upon simplicity. Usability, an ultimate goal, builds upon convention and repetition. Anyone complaining that an old spec or a particular browser is holding up progress should really be careful of passing vehicles.
Sean Medero writes:
bq. The WebKit team has told the HTML WG that they want to implement the entirety of the HTML 5 spec in the very near future. (I wish I could give you a citation URL for this but I can’t find the transcript of the face-to-face meeting in Boston where Maciej Stachowiak talked about the WebKit team’s commitment to HTML 5.)
Just to be clear, I didn’t make specific date or scope commitments, as Apple does not comment about future product releases. But I *can* say that we’ve implemented many aspects of the spec in WebKit nightlies, and we are interested in many other parts of it. In any case I couldn’t make a statement one way or the other about 100% support until the spec is final.
Here’s what I’d love to see in the new version of HTML:
1. The href= attribute available for use on any element. If I want to make an element linkable, why do I either have to use javascript or put use an anchor?
2. An easy way to tie the height/width of an element to another element – the way table rows and columns tie height and width to groups of table cells. Some thing like: div {height: #header;}, which would grab the height of the #header element.
3. An easy way to vertical center in block elements (DIVs, etc.). How come table cells can do this, and but DIVs require give and take with padding and height/width?
Also, like a lot of other people in this board, It feels to me that the new elements
I think that the code, discussion and techniques discussed here in ALA ultimately mean more and have more beneficial effect than this HTML5 thing ever will.
I do understand that there is a syntactic difference between
and
but for the life of me I do not see what desirable behaviors I cannot do with the second. And since divs share some behaviors, I find the second *more* understandable. In my cranky pseudo-object terminology, it means that _header_ as defined in css inherits from _div_. So what if one is a tag and the other is an attribute value.
Although I am a student of language structure, I require meaningful application to my work which, in this context, is making web sites.
I also am guessing that there is going to be some paradigm shift, sea change, aha discovery or mere ‘this changes everything’ event that makes much of the hard work of HTML5 for naught. As others have mentioned (3,10,15) years is a long time.
OTOH, construction of “The Cathedral of St. John The Divine”:http://en.wikipedia.org/wiki/Cathedral_of_Saint_John_the_Divine,_New_York was started in 1892 and it is still not yet completeted, yet it functions fully. Maybe HTML5 will be the St. John’s of the web.
It’s likely I’ll be retired before HTML 5 is THE way, but I can already see the potential. It’ll be interesting to watch the progress. For the time being I would like to say thank you, Lachlan. That was a well written and informative article.
Seems to me that ought to be the subtitle for the HTML5 specification. I did read Shawn’s comments (#33) _and_ I even took a look at the committee’s so-called “Design Principles” and parts of the HTML5 spec.
Personally, I found the “Design Principles” to be the most telling: This is arguably the most important part of the standards process and yet this document is devoid of substantive goals and expectations. I was expecting such things as: What specific problems do we intend to solve? How do we envision the production _and_ consumption of future HTML _and_ the issues posed by each? All I was able to gather is that we “need” to have a new spec. and so let’s go create one and incorporate some of these general/techie ideas along the way.
There are very good reasons to choose Flash over HTML/CSS/Javascript and also good reasons to choose PDF over HTML, and so on. Certainly HTML has many benefits to it and the benefits are quite compelling. But the shortcomings…oh, the shortcomings.
Coming from the developer side of the camp, I agree with everyone’s comments that precede mine regarding the problems developers face: vertical alignment, column alignment without tables, varying degrees of standards compliance, different/unexpected renderings, accessibility, dealing with browser bugs/quirks/incompatibilities, maintaining colors across platforms with differing gamma corrections–to name but a few! Structuring the general layout of a page? Not a problem. Dealing with h1,h2,h3,… in some crazy fashion? Not a problem. Even dealing with audio/video is not a problem, really, but I’m open to improving that nonetheless.
I do believe there is a place for something that comes after HTML 4.01, but this HTML5 in its current form is not it–and is not going to be it, either. If the W3C wants to lay an egg, go ahead (curious how the graphic that accompanies this article is an egg in a box, no?). If the W3C wants to produce something that will actually get used, the HTML working group needs to start over.
Finally, I understand this process is new so although I am beating up the working group/W3C, I’m really more interested in seeing them improve. I’m not sure what the right forum is for some of my other thoughts and ideas but I’ll spare everyone from more of my ranting! Besides, I have to go figure out why MSIE6 is displaying my stuff in a peculiar way!
Forgot to add that if you go to the HTML Working Group’s “main page”:http://www.w3.org/html/wg/ you’ll find that under the _Current_ _News_ sidebar, the “Design Principles” link at the top is completely messed up. So if even the _HTML_ _Working_ _Group_ can’t get the XHTML right….
Okay I will:
bq. Microsoft hasn’t quite joined the implementation game yet but is involved (Chris Wilson is the chair of the W3C’s HTML Working Group which is working on HTML 5 along with WHATWG.)
And that’s what’s got my pessimism all worked into a froth. Microsoft has helped write standards before (CSS anyone?) and then (not-so-)promptly failed to ever implement them adequately.
I’m dying to move forward. But I feel like one of those cartoon characters running in place while the ghost of Explorer has a hold of my suspenders from behind. Not only am I not gaining any ground, but the ghoul will be the death of me.
Until Microsoft proves they can jump ahead of where they’ve been, I will withhold my optimism. They did that once with IE5 on the Mac – before they let it whither, get passed up and officially die. The large, but not giant, step they took forward with IE7 hardly catches up to where WebKit, Gecko and Presto were years ago.
Even though it’s not code, just an illustration, the use of curly-quotes in the top schematic around the ids and classes is a bit grating.
Count me in along with the others who don’t grasp the necessity of the new tags. OTOH I can see some usefullness in CMSs where things like “header” and “article” might make it easier for authors. Maybe. One could always treat this as xml and translate to div’s with id or class names for production.
Interesting that the example html has ‘div id=”sidebar”‘ whereas the html 5 version has ‘aside’. To me, ‘aside’ seems more like a stage direction. What’s wrong with ‘sidebar’?
As for ‘section’, I’ve been using that lately (as ‘div class=”section”‘) as specified in xhtml 2.0 spec, where ‘section’ serves to associate a heading (along with level) with the following content. (Along with transclusion that’s pretty much it for my xhtml 2 interest)
I’d much rather see crossplatform support for math equations, alignment to decimal in columns, and namespaced attributes. 15 years is a long time, perhaps most of the web then will be for ARGs taking place within an augmented reality googleverse (ok, now I see the proper use for an ‘aside’ tag)
I’m really surprised at the negative reaction here. I’ve been really excited by HTML 5 (and the XHTML variant) for a while, and this article just increased that.
What about backwards compatibility of new elements (HEADER, NAV, ARTICLE, SECTION, FOOTER, ASIDE)? Even pretty new browsers like Firefox 2 and 3b or IE 7 can’t style these new elements. Opera 9 and Safari 3 can, but what to do with others?
Maybe some attribute for DIV element is better idea from compatibility point of view.
I just think that nobody will use new elements for compatibility until Firefox 2 will not become Netscape 3 in developers’ minds.
BTW, try it yourself: “HTML 5”:http://rusrestaurant.com/tests/html5/test1/html5.html , “HTML 4”:http://rusrestaurant.com/tests/html5/test1/html4.html
For people who don’t understand the use of
Oh, and one other real benefit for us as authors: the new elements will severely reduce the clutter of all the divs blurring together on our pages.
– With thanks to Sam Ruby for mentioning that point in his email to the public-html list just now; check out the effect by viewing source on the “html5 version of his site”:http://intertwingly.net/blog/index.html5
Thanks for the excellent preview! Looking forward to it.
I was surprised however that there was no mention of things like Web Forms 2.0 and the Canvas element. Don’t they fall under HTML 5 too? Or do they just fall outside the scope of this particular preview?
Alexis (comment 51), there are far too many features in HTML5 to discuss in one article. I decied to focus on just 2 major features to keep the article short. I picked these features specifically because they would be of interest to a lot of people and haven’t been discussed much before. Other features like Web Forms and canvas have been discussed many times over the years.
@Lachlan
Understood, thanks for the clarification. My concern is that the people going “is that all?” may not be all be aware of how many more (and familiar) features HTML 5 includes.
Would be nice to seeing more of these developer-friendly articles on HTML 5 features appear as the specification matures.
I don’t wish to pick on Sander (comments 49, 50) but his comments do serve to illustrate the point I was trying to make.
For example: is “improved readability of HTML source” a goal of the HTML5 effort? The “Design Principles” document makes no mention of this as a goal and I’m sure there are lots of different opinions regarding its merits as a goal. If we’re considering people who do mostly hand-coding of HTML, this is probably a greater concern. People using server-side includes or another templating system may or may not be concerned. People who just want a flashy web site to impress potential clients…who knows?
So the point here is two-fold: 1) is this a goal? 2) which group of people deserves more/less weight when evaluating the possible solutions? To the last part, there are other ways to improve readability. Consider this if you will:
Clearly the ‘startof’ and ‘endof’ would be new attributes that could be implemented tomorrow without any impact to existing browsers (they should already know to ignore something unfamiliar). However, if I build an application that is aware of the attributes, the application could do special highlighting or tabbing or whatever to help me out as I compose or review the source.
Obviously this is only an example, but considering that there would be a way to meet the goal with no impact to the vast majority of the installed base (as opposed to introducing new tags), does this idea deserve any more/less consideration? What about resolving conflicts between people who love the idea and people who hate it?
The HTML working group does not appear to have answers to these questions. As far as I’m concerned, they _need_ to have such answers so that discussions like this can take place. Without the discussions, the risk is high that HTML5 will be neither particularly relevant nor particularly useful.
…formatting goof. The example was supposed to look like:
<div class=”example” startof=”something new”>
…text text text…
</div endof=”something new”>
I really, really want to understand why so many people are working so hard to justify HTML. Unfortunately, this article did nothing to enlighten me.
I’m now left with three possibly (probably) incorrect perceptions:
1. There are folks out there who want to ensure that IF browsers drop support for HTML 4 (no, please…don’t…zzzzzz) there will be a spankin’ new DOCTYPE that will not only continue support for these broken pages but will also make their authors feel good about supporting a “new” specification.
2. There are folks out there with severely overblown phobias of closing tags (really, guys, they’re not that hard to type in).
3. There are folks out there who think that all websites in 10 years will be blogs.
Did I leave anything out? Probably.
Please… Instead of focusing your efforts on HTML 5, how about nailing down updates to CSS, or working toward better, more consistent cross-browser support for web standards, or figuring out a bulletproof way to achieve vertical centering without hell, or… I don’t know, SOMETHING. HTML 5 just doesn’t seem to be useful enough to warrant its brain trust.
The header and footer tags are not particular useful as they do not describe their content but rather they describe their position on the page.
Any content in the header, for instance, would therefore always be restricted to the top of the page. And as others have said what actually is the “header” and what should it contain? Does apple.com have a “header” or a navigation bar or is it some strange combination – a naveader?
I like the header, nav and footer tags. They seem useful for behind the scenes coding at least.
But the article and section do seem a bit limited where using a div seems to make more sense. Perhaps there will be more “article” type tags to come?
Cheers for the article though Lachlan. Must admit I found it interesting but then to read it would be 15 years away took the wind out of my sails.
@Vlad:
bq.1. This means lower value headings can be used before higher value headings. For example, this will be valid in HTML 5:
heading
heading
I don’t think that is the case, unless I’ve misread the spec. If the [h1] is within a [section] or other such block-level element, it _will_ be allowed, but within each block, [h_x_] elements must still be in the correct order.
What this means is that you can dynamically include sections into a document without having to worry about whether each of the headings is at the right level for where you have included it.
bq. 2. Skipping heading levels will be valid in HTML 5. For example:
heading
heading
That’s fine with me. Sometimes you might be working to a framework, where each [h_x_] heading represents a particular level – there might be some sections that _do_ miss out a heading level. It makes more sense to the overall structure to keep, for example, all the base-level headings as [h4] rather than promoting some of them to [h3] in some sections only.
@Amber:
bq. Does it? What does “header”? actually mean? What does it tell me? It tells me, “This is a bunch of stuff that goes at the top”?. That’s all header means. I’m not sure that’s terribly helpful.
It’s more than that, it’s like a summary or strapline to the document or section.
For example, search engines could extract any text in a [header] tag and use it on results pages to give a summary description of the page if the [meta] description is either irrelevant or absent.
Assistive technologies could use [header] sections to summarise the page and allow the user to home in on the section they need more quickly – this would give more context than users currently get by just going through the [h…] elements.
It also provides a handy way to mark up a strapline. At the moment, a lot of people are torn between using an [h2] for the line of text that goes immediately under the [h1], because it’s important, and using a [p] or [div] because it’s ordinary text. The [header] element will neatly resolve this.
@Michael:
bq. Interesting that the example html has “˜div id=”?sidebar”?’ whereas the html 5 version has “˜aside’. To me, “˜aside’ seems more like a stage direction. What’s wrong with “˜sidebar’?
The key difference is that ‘sidebar’ is a presentational, positional term. It implies a vertical division with the content on the narrower side of it – and that may not be how you want it laid out. ‘Aside’ is a more generally descriptive term, and could easily be presented in a different way without it being self-contradictory.
I’ve not read all 7 pages of comments so I don’t know if this time frame has been explained… but 15 years, the web barely existed 15 years ago and look how far we’ve come now. I’m _guessing_ 99% of what was being done/used to build the web back then is no longer relevant and I’m willing to bet that in 15 years time (with browser technology advancements, etc) the HTML5 spec will be irrelevant. MS could have released 2 new browser versions by then!
I’m all for better tools, API’s, user experiences but surely the minds/companies involved can work quicker than that!
Crikey, I’ll be looking to retire then!
@Stephen
bq. For example, search engines could extract any text in a [header] tag and use it on results pages to give a summary description of the page if the [meta] description is either irrelevant or absent.
Perhaps it’s just me, but I didn’t take the use of header to be another tag to represent metadata. The way I understand it, “header” is just as positional as “sidebar” is or would be.
I’m all for increasing/improving ways to assign metadata to web documents; I’m not sure a header tag would be the way to go to do that. I suspect that when most people think of header they’re thinking of the top of the wrapper that establishes the brand, the title of the site, etc., not the metadata that classifies what we’re looking at.
@amber
I’d have to agree looking at the new tags they seem to be there as a hint to layout rather than semantic meaning – from what I can understand I see no benefit from using
Or am I missing the bigger picture?
And all this is a bit pointless unless we get buy-in from MS (which was mentioned in article) – same thing is happening with ES4/JS2.
10 to 15 years and they are basing tags off of what’s being used right now. I dislike div-itis as much as the next guy, but the flexibility of DIVs sounds like something I’d rather use than canned layout based tags.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum.
Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.
I can’t believe the 5 to 10 to 15 year time scale being discussed on here. I’m mindful of how train operators increase their timetabled journey times to make it appear that delayed services are actually running on time. (http://news.bbc.co.uk/1/hi/england/london/2978349.stm)
If the HTML 5 working group are saying this is the timescale before it can be adopted as an everyday, usable technology, imagine how overjoyed we’ll be when it’s done a year quicker.
I’m sure there is a lot of good work going into HTML 5; however, I personally don’t see any real justification for this amount of time and energy.
Web designers are dealing with frustrating real world problems on a daily basis due to incorrect or incomplete implementations of specs in (some) current browsers and this doesn’t seem to be getting any better.
Forgive my cynicism, but I see little to be hopeful about in HTML 5 when the current state of play is still far from ideal. I’m more interested in being able to write code ONCE that works across all browsers NOW, than the dubious benefits that will come from some future-distant unnecessary spec.
sounds fine but way to slow. I cant seriously evaluate something that will come in 15 years. This cant be serious.
apar from that the fixed tags like head and article is a bad idea. Pople will put non-nav content in nav-tags. Bad start…
I am a content producer (writer, editor, photographer) I will look more into this. maybe I dont understands all thi techstuff, but my overall feeling is negative because of the timeline.
HTML 5 sounds great on paper, but the time table is entirely way too long, and it’s all completely pointless unless each of the browser vendors will support it in full. No browser that I am aware of even supports CSS 2 fully. There’s no excuse for that. CSS 2 has been around for a long time. And of course the one browser that gets it wrong the most is also the most used. IE 6 needs to hurry up and die, and all current browsers should be given full support of CSS 2.1 and even parts of CSS 3 as a minimum. Think about all the wasted man hours spent fixing CSS bugs just so web pages will render relatively consistently. We should all bill Microsoft for the time wasted.
I suppose that HTML 5 will appear “a bit” too late. If it appeared now, situation would be different, but even if standard will be ready it will take years when users will use it.
.. look wrong, to me. Why did they choose to make that a standard?
The CONTROLS attribute describes nothing. Is it a boolean? Does it “control” something obscure? Simply adding a value would clear up a lot of potential confusion.
M. Hageman (comment 72), the controls attribute is boolean. It’s exactly like the checked attribute:
In XHTML, it would be controls=”controls”. For convenience, controls=”” will work too.
When are they going to include a way to label a list?
Generally those new elements suppose HTML 5 will make easier to developer/designer, though it wouldn’t much help. (Or i just didn’t realized of its shakes)
@ Stephen (comment 59)
My statement that, in HTML 5, lower value headings can be used before higher value headings, is correct. Below is an example taken from the spec:
http://www.w3.org/html/wg/html5/#headings0
Apples
Apples are fruit.
Taste
They taste lovely.
Sweet
Red apples are sweeter than green ones.
Color
Apples come in various colors.
Headings are one of the most important constructs in making Web pages accessible. But virtually nobody is using numbered headings correctly. Changing the semantics of numbered headings in HTML 5 will only serve to confuse people further and will not fix the problem. By contrast, XHTML 2 uses the h element instead of numbered headings, which is a much easier construct for people to understand and use. But the HTML 5 Working Group is reluctant to “borrow” constructs from XHTML 2.
Please fix your commenting system. It’s not clear how to post code examples in comments. The preview does not reflect the actual posted comment.
Hello –
Interesting article and dicussion. I am a a college instructor for XHTML. It’s a sorry shame that the HTML 5 folks can’t get together with the XHTML 2 folks and just combine the best features of both. Then… let’s call it COOL 2.0. COOL? Yeah… because it would then be real Cool for students to learn just ONE language, and ONE standard that worked on ALL browsers. Fat chance. Instead, I’ll just tell them “Close your tags — No. Wait. Maybe you don’t have to.”
C’mon people. Doesn’t anyone see the “Tower of Babel” problem here? God help me, it almost makes me wish for a Dictatorship of web standards. An article comparing the competing standards, linked to and cited earlier, states:
“Indeed, the X/HTML 5 spec actually says ‘generally speaking, authors are discouraged from trying to use XML on the Web’, even though W3C continues to herald XML as the future of the Web?” HUH? Great, now we can have a new web editor with FIVE WINDOWS: HTML5, XHTML2, XML, CSS, and BROWSER VIEW. Wait… we’ll have to have a tab for different browser views for the different standards.
What the H— is going on here? What the H— should be taught in college so students can excel?
Yours –
Scott
Talking about a technology that’s not expected to work until 2017 (or even as late as 2022) is ridiculous. The web moves far too quickly for us to rigidly define a language for use a decade in the future — the best we can do is embrace extensible technologies, so that things can develop naturally.
The new features HTML 5 are very underwhelming: for example, there’s the possibility for automatic client-side validation of e-mail addresses etc. — but that’s something I’d rather just do now with JavaScript than wait 10 years for _some_ web browsers to do it for me. It’s laughable.
I’ve read that HTML 5 is supposed to be better for automatic indexing etc. — but if we’re concerned about making the web better for robots, then furthering XML is the way to go. And for developers, XHTML 2.0 is really clever, tight, elegant and intuitive. It’s not as backward compatible as HTML 5… but I’m beginning to think that maybe a ‘new start’ is what the web needs: we’ll see better levels of compliance after browser vendors are forced to start afresh. Anyway, it’s not as if you can’t adopt XHTML 2.0 without also serving old (X)HTML to old browsers until they die out. And, if XHTML 2.0 becomes a W3C recommendation soon (the “XHTML2 Working Group Roadmap”:http://www.w3.org/MarkUp/xhtml-roadmap/ seems hopeful), it’s likely to have been well-supported for years by the time HTML 5 arrives to sort out little issues that only affect decade-old software.
I have to say, I’ve only recently heard about HTML 5. I thought that as of HTML 4.01, HTML itself was no longer going to be developed or standardized, and that XHTML 1.0 and 2.0 were the way forward.
The biggest drawback for XHTML 2.0 as far as I can see is backward compatibility, but there’s nothing to say that browsers themselves cant process both current HTML/XHTML standards and that of XHTML 2.0. And if XHTML 2.0 solves many of the problems we see in HTML today, but 10 years sooner than HTML 5 will, then why even bother with HTML 5?
As people have repeatedly said in this discussion, 10 – 15 years is just too long to wait for a new markup language for the web.
My personal opinion is that the people developing HTML/XHTML in general aren’t thinking outside the box enough. At the moment, websites are primarily text-based, and everyone conforms to the usual standard when designing their sites – ie. most websites are columns-and-rows based layouts, filled with text. Search engines love text, but hate multimedia elements such as Flash and SVG graphics. But when are things going to change? When are we going to move away from the “anything-more-than-text-on-a-site-will-make-it-less-usable-for -someone” attitude?
I’m not saying that accessibility and usability aren’t important, and I know this is probably a discussion for another time, but it seems pointless to me that the W3C (and others) are working so hard (and for so long) on developing the next great standard markup language for the web, when in the end it just wont deliver what we’ll all want it to 10 – 15 years from now.
We need a completely new language for the web. Sure, it’d be fine to keep it XML-based (certainly not SGML-based) but if the web is going to evolve at the same pace that it has been, then we’re going to have to find a way of breaking the restrictions that current markup languages have – and in my eyes HTML 5 or XHTML 2.0 just aren’t going to do that.
I like the article oriented semantics of html5, article could be a video, a sound interview or piece of text… which seems good. Maybe there should be a way to denote “Main Article”?
In this way you have a way to separate one article pages from pages with many of them (like homepages).
Not sure why we need this article when HTML5 is not finished. Who’s to say the elements won’t change again? Yet it’s generating some good discussion here.
10-15 years is a joke. I assume this is to allow time for Microsoft to implement it. 🙂 Talking of whom:
_”Until Microsoft proves they can jump ahead of where they’ve been, I will withhold my optimism. They did that once with IE5 on the Mac — before they let it whither, get passed up and officially die. The large, but not giant, step they took forward with IE7 hardly catches up to where WebKit, Gecko and Presto were years ago.”_
Good news. Rumours are rife that IE8 will be based on a new engine such as WebKit.
_”Oh, and one other real benefit for us as authors: the new elements will severely reduce the clutter of all the divs blurring together on our pages.”_
Sadly I doubt this. What will happen is that we’ll end up with the new elements *and* a bunch of divs surrounding them to ensure backwards compatibility. How else will we render our sites in browsers like IE6? (Either that or serve different code from the server. Sigh.)
I spoke too soon. Looks now like IE8 will be based on the old Trident after all. (Check out this “interview”:http://www.sitepoint.com/article/ie-standards-chris-wilson with Chris Wilson.)
If you’re a designer who wants to make your semantically correct (x)html page just look right, you probably won’t need elements like
I’m sorry. Did I say ‘symantic’? I meant ‘semantic’ of course.
The HTML 5 specification should also include tags that extend the basic structure of documents. Block-level elements such as:
–
Thanks for very interesting article. btw. I really enjoyed reading all of your articles. It’s interesting to read ideas, and observations from someone else’s point of view”¦ makes you think more. Keep up the good work. Greetings
So, in summary:
– there are better ways to implement semantic meaning and metadata by using the structures designed for that: attributes instead of new tags
– everything in HTML 5 (or XHTML 2, for that matter) is useless, unless MS is on board.
– SGML development is a waste of time, because XML is better (try writing an SGML Parser from scratch, versus an XML parser).
– The web needs current standards implemented before moving on to newer (and XML-based) solutions.
Where does this leave CSS?
It does sound like a long time. Still, it has been almost ten years and the major browsers still can’t get on board with XHTML and CSS.
Talk about XHTML, wasn’t that one of the major reasons to have everything closed; to clean up the markup and make it XML friendly all at the same time. Seems like removing half the code now, it’s moving right back to HTML. Which, by the way, was supposed to be completely replaced by XHTML? Perhaps if they want to improve on it they could just figure out how to include an “if” statement.
Personally I like the closing tags. I can imagine the browsers now, each with its own interpretation of where the closing should be; don’t throw out the hack book yet.
Why do we need HTML 5 when we all ready have XML, with which We can define our own tags? Wouldn’t it be easier to persuade browser vendors to support ‘application/xml’ and then the possibilities will be endless.
Title emphasis are on *hypertex* and *markup*.
It feels like there is just too much confusion on this particular topic. Seems that we have almost forgotten what is a job of HTML(as it is) thanks to an overwhelming number of other web-techs flying around our heads.
We shouldn’t discuss the difference between the
*How a parser sees the ideal HTML page*?
– beginning of the content– heading
– subheading
– paragraph
A Heading!
…
So, now… how we can improve the later *without* introducing new tags? If we say that, new tags are irrelevant, then we should all go back and remove half of the existing tags as well, cause we don’t use them semantically anyway.
Personally I think that the *goal* of a *HTML 5* shouldn’t be something ground-breaking or that it should reduce designers coding work by half. It just has to make a page little less complicated and a little bit more semantical, that alone would be just great.
What a mess. The people developing HTML 5 clearly don’t care about what a muddle the web is in (or if they do, they’re going the wrong way about fixing it).
I read somewhere that HTML5 does have one little advantage that other languages can’t provide: it allows you to specify that an input should contain an e-mail address, so browsers with proper support could (1) validate e-mail addresses, and (2) have a form control that allows a user to select an e-mail from their address book. The second benefit is, apparently, not possible without HTML5. But that’s not true, it would be better to do that sort of thing with microformats. I really don’t think that sort of thing should be built into a markup language.
People who think it’s a good thing to have elements like “footer” and “article” have completely lost the plot – semantics is not about coming up with more and more restrictive tags. I mean, what the hell does an “article” tag actually achieve? It makes absolutely no difference to users. It’s not even very convenient for robots, because it’s part of a shoddy, badly-formed language that’s difficult to parse. If you want to achieve infinite flexibility (not just a few more tags), and you want the web to be more semantic and more understandable by bots (and therefore more interelational) you need to make the world embrace application/xml. And the step on the way to that is XHTML 2.0.
HTML5 is an ugly, backward mess and I hope to God I never have to code in it. It’s not elegant and not consistent. And it doesn’t help the world adopt XML, it’s just delaying progress. Please, A List Apart, do an article on XHTML 2.0 and show everyone how great it is.
Oh, and XHTML 2.0 will have XForms. Enough said.
I’m sure there will be very little we can’t do in html5 that we can do now. To escape the limitations of the form tags such as “header” it seems there would be no reason we couldn’t still make custom CSS classes within div tags.
The time-line is worrisome, however, I think getting this spec into production quickly is important; Otherwise, we may get stuck in a quagmire of proprietary web technologies again. Standards must prevail, or we will be living in web-dev-hell.
I think the biggest advantage of the new standards that are currently in development are the stricter definitions. We’ve learned from the past that many things were interpretable in different ways. Hopefully HTML5 and other future standards will bring a more standardized web, as in every browser will render it the same. With no space for your own interpretation it *should* be easier to implement it for the browser vendors. Let’s hope the best!
I can see how
Thanks for this great post.
I don’t like the new “semantic” tags, because meaning is murky. I think that the proposed “section” tags don’t need to exist, and we can just give semantic meaning to layers of “div” tags, each indicating the beginning of a section. We can rank headings on a page by how many layers in they are.
I’m with Rob Newman on this one; there’s a clear difference between moving forwards and creating new restrictions.
XHTML created a standard that finally made designers code sites that would look the same in most browser (and IE).
It even got some of the lazy designers closing tags, which even HTML 4 advocated. Pandering to laziness and encouraging people to start writing pages like a dyslexic donkey, jamming unclosed tags here there and everywhere, is just bloody ridiculous.
Claiming this is a move towards a more semantic web is just counter-productive. The viewing public couldn’t care less if you coded your website in Pascal as long as it looks nice and does what they expect, and as much as I support the idea of a semantic web, I fail to see how bastardising web-standards rather than working with the development of current standards is going to help create a “better internet”.
HTML 5 is simply a collective of Luddite trying to claw back the miserable mess that was HTML4 in order to make their lives that little bit easier.
For me there is only XHTML 2.0 and XForms, roll on the future it’s gonna rock. Thank god the HTML 5 mess will take a decade or so before it sees the light of day, by then it’ll be about as exciting as Fortran.
bq. If you are writing in another language, wouldn’t something like this be more readable?
We’ve never particularly worried about other elements being named in English only. Nobody has said that we should allow as well as , or that CSS should recognise ‘izquierda’ as meaning ‘left’.
Okay, let’s see if I’ve got this right. Here’s where (X)HTML5 stands today:
* Current working draft includes the well supported @embed@ element.
* Since there won’t be any doctype, we can use @@ starting today.
This allows for a simple cross-browser way to embed Flash movies *today* using *valid* (X)HTML5 markup according to specification!
Although @embed@ doesn’t support fallback, I very much prefer it’s simplicity over “using the @object@ element”:http://www.alistapart.com/articles/byebyeembed
I don’t understand _why_ we need a new SGML-based language. I can (on a good day) understand why we need two branches of the language (one for smart, hand-coding humans, and one for machines to regurgitate), but I don’t understand why the second one has been designed to keep our web browsers so bulky, by not caring about syntax. Any machine can easily comprehend XML syntax, and spit that out instead of SGML.
XML leads to cell phones being able to use the whole web, and _much_ faster web browsers. We wee told that XML is the way of the future, and now the W3C stabs all the standardista-minor in the back with a new SGML-based language: not cool.
My first browse here!
So HTML5 will introduce a load of new semantic tags. But what exactly will they achieve? To the end user whether a tag is
The latter is anyway solved by XML and the former is only the case if the tags are used properly. But then that’s the problem with HTML in the first place. It is not being used as intended and when HTML5 finally sees the light of day, it too won’t be used as intended. Having one nav tag is great, but what we will end up seeing is 5 or 6 of them because they achieve a certain layout effect. How is a blind user then going to be able to tell which is the “main” nav tag.
Really what we need is a way of applying semantics to tags in the same way that CSS applies styling to them.
I really wish all the effort that has gone into HTML5 had actually been put to better use in creating a common rendering engine or at least a standardised way of rendering CSS instructions. I just don’t see how HTML5 is solving the problems of HTML4. The problems with current web design are actually with the support for CSS, not HTML.
bq. Work on HTML 5, which commenced in 2004, is currently being carried out in a joint effort between the W3C HTML WG and the WHATWG. Many key players are participating in the W3C effort including representatives from the four major browser vendors: Apple, Mozilla, Opera, and Microsoft; and a range of other organisations and individuals with many diverse interests and expertise.
Firstoff, is the WHATWG the driving force, primarily, behind HTML5? And Microsoft is not a part of WHATWG (the listed reason is that they cannot agree that the final spec should not require software patents to implement — a weird reason, whether true or not. It leaves us to assume they simply want no part any any true interoperability).
To this commenter, it seems the author is going out of the way to try to include Microsoft in this effort, whereas they decided not to show up to the party.
Robin’s comments above really hit the nail on the head for me. I’ve coded professionally for a few long years now, and rather than refining the rules of the Game, HTML 5 seems to be a drawn out debate on what the Team should call itself.
Snarkiness aside, I’m curious to see just how far this goes.
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Phasellus eu nisi tempus nibh sagittis nonummy. Suspendisse aliquam neque quis dolor accumsan blandit. Ut in libero vitae arcu sagittis convallis. Donec sed quam at tortor interdum gravida. Vivamus consequat nulla at turpis. Nunc hendrerit interdum tellus. Maecenas interdum. Sed commodo, ligula in imperdiet tristique, orci mauris commodo diam, rhoncus laoreet nisl magna sed arcu. Fusce hendrerit, lacus nec adipiscing lobortis, ligula elit suscipit massa, eu euismod nisi leo vel justo. Curabitur mattis diam ut ipsum. Sed tincidunt, quam non mollis venenatis, est nisi ultrices nunc, id rhoncus sapien justo id pede. Fusce augue tortor, dapibus ut, euismod eu, posuere nec, erat. Phasellus velit. Nulla diam velit, posuere vel, euismod molestie, fringilla et, nunc.
Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Etiam eu dui at turpis aliquam pulvinar. Maecenas eget risus. Maecenas enim. Nulla vulputate sem a felis. Fusce lacinia euismod enim. Mauris leo. Maecenas tempus, augue eu tempus gravida, metus sem consequat ipsum, eget adipiscing enim pede vel mauris. Fusce faucibus, odio id bibendum placerat, ipsum diam eleifend nisl, ut sagittis lacus enim vel turpis. Vestibulum tristique nulla a leo. Proin sollicitudin. In ligula mauris, blandit id, fermentum quis, gravida nec, est.
Aenean posuere risus. Integer quis ligula. Mauris dignissim auctor eros. Phasellus placerat. Quisque euismod. Morbi pellentesque. Nullam quis orci. Ut vulputate lacinia eros. Donec leo lacus, elementum eu, vulputate vel, rhoncus vitae, felis. Sed et lacus. Nullam et sem.
Curabitur in arcu quis urna sagittis rutrum. Mauris rutrum nisl vel arcu. Maecenas mauris enim, tempus posuere, pulvinar eu, ullamcorper in, odio. Suspendisse dolor. Morbi libero mauris, ullamcorper id, fringilla laoreet, sodales at, odio. Etiam metus. Cras lacinia risus id pede. Phasellus elementum ornare lectus. Sed vitae diam. Nunc eu quam. Phasellus ipsum tellus, imperdiet nec, ullamcorper et, egestas vitae, purus. Proin mattis, lectus sit amet dignissim tempus, nunc nibh laoreet erat, in tempor erat quam at ligula. Aenean fringilla cursus sem. Aliquam erat volutpat. Curabitur luctus placerat sem. Integer consectetuer sodales lectus.
Sed vulputate nisi at neque congue facilisis. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos. Mauris ac erat. Donec elit. Duis urna pede, congue sed, volutpat id, lobortis in, mauris. Ut mollis ante ut neque. Duis viverra libero at justo. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Proin quam. Nullam nulla. Aliquam at nulla. Donec tristique imperdiet erat. Sed mollis pretium metus. In faucibus aliquet sem. Sed viverra tristique leo. Praesent ut nisi. Donec ac ligula eu nibh placerat ultricies.
Generated 5 paragraphs, 429 words, 2895 bytes of Lorem Ipsum
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Phasellus eu nisi tempus nibh sagittis nonummy. Suspendisse aliquam neque quis dolor accumsan blandit. Ut in libero vitae arcu sagittis convallis. Donec sed quam at tortor interdum gravida. Vivamus consequat nulla at turpis. Nunc hendrerit interdum tellus. Maecenas interdum. Sed commodo, ligula in imperdiet tristique, orci mauris commodo diam, rhoncus laoreet nisl magna sed arcu. Fusce hendrerit, lacus nec adipiscing lobortis, ligula elit suscipit massa, eu euismod nisi leo vel justo. Curabitur mattis diam ut ipsum. Sed tincidunt, quam non mollis venenatis, est nisi ultrices nunc, id rhoncus sapien justo id pede. Fusce augue tortor, dapibus ut, euismod eu, posuere nec, erat. Phasellus velit. Nulla diam velit, posuere vel, euismod molestie, fringilla et, nunc.
Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Etiam eu dui at turpis aliquam pulvinar. Maecenas eget risus. Maecenas enim. Nulla vulputate sem a felis. Fusce lacinia euismod enim. Mauris leo. Maecenas tempus, augue eu tempus gravida, metus sem consequat ipsum, eget adipiscing enim pede vel mauris. Fusce faucibus, odio id bibendum placerat, ipsum diam eleifend nisl, ut sagittis lacus enim vel turpis. Vestibulum tristique nulla a leo. Proin sollicitudin. In ligula mauris, blandit id, fermentum quis, gravida nec, est.
Aenean posuere risus. Integer quis ligula. Mauris dignissim auctor eros. Phasellus placerat. Quisque euismod. Morbi pellentesque. Nullam quis orci. Ut vulputate lacinia eros. Donec leo lacus, elementum eu, vulputate vel, rhoncus vitae, felis. Sed et lacus. Nullam et sem.
Curabitur in arcu quis urna sagittis rutrum. Mauris rutrum nisl vel arcu. Maecenas mauris enim, tempus posuere, pulvinar eu, ullamcorper in, odio. Suspendisse dolor. Morbi libero mauris, ullamcorper id, fringilla laoreet, sodales at, odio. Etiam metus. Cras lacinia risus id pede. Phasellus elementum ornare lectus. Sed vitae diam. Nunc eu quam. Phasellus ipsum tellus, imperdiet nec, ullamcorper et, egestas vitae, purus. Proin mattis, lectus sit amet dignissim tempus, nunc nibh laoreet erat, in tempor erat quam at ligula. Aenean fringilla cursus sem. Aliquam erat volutpat. Curabitur luctus placerat sem. Integer consectetuer sodales lectus.
Sed vulputate nisi at neque congue facilisis. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos. Mauris ac erat. Donec elit. Duis urna pede, congue sed, volutpat id, lobortis in, mauris. Ut mollis ante ut neque. Duis viverra libero at justo. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Proin quam. Nullam nulla. Aliquam at nulla. Donec tristique imperdiet erat. Sed mollis pretium metus. In faucibus aliquet sem. Sed viverra tristique leo. Praesent ut nisi. Donec ac ligula eu nibh placerat ultricies.
Generated 5 paragraphs, 429 words, 2895 bytes of Lorem Ipsum
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Phasellus eu nisi tempus nibh sagittis nonummy. Suspendisse aliquam neque quis dolor accumsan blandit. Ut in libero vitae arcu sagittis convallis. Donec sed quam at tortor interdum gravida. Vivamus consequat nulla at turpis. Nunc hendrerit interdum tellus. Maecenas interdum. Sed commodo, ligula in imperdiet tristique, orci mauris commodo diam, rhoncus laoreet nisl magna sed arcu. Fusce hendrerit, lacus nec adipiscing lobortis, ligula elit suscipit massa, eu euismod nisi leo vel justo. Curabitur mattis diam ut ipsum. Sed tincidunt, quam non mollis venenatis, est nisi ultrices nunc, id rhoncus sapien justo id pede. Fusce augue tortor, dapibus ut, euismod eu, posuere nec, erat. Phasellus velit. Nulla diam velit, posuere vel, euismod molestie, fringilla et, nunc.
Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Etiam eu dui at turpis aliquam pulvinar. Maecenas eget risus. Maecenas enim. Nulla vulputate sem a felis. Fusce lacinia euismod enim. Mauris leo. Maecenas tempus, augue eu tempus gravida, metus sem consequat ipsum, eget adipiscing enim pede vel mauris. Fusce faucibus, odio id bibendum placerat, ipsum diam eleifend nisl, ut sagittis lacus enim vel turpis. Vestibulum tristique nulla a leo. Proin sollicitudin. In ligula mauris, blandit id, fermentum quis, gravida nec, est.
Aenean posuere risus. Integer quis ligula. Mauris dignissim auctor eros. Phasellus placerat. Quisque euismod. Morbi pellentesque. Nullam quis orci. Ut vulputate lacinia eros. Donec leo lacus, elementum eu, vulputate vel, rhoncus vitae, felis. Sed et lacus. Nullam et sem.
Curabitur in arcu quis urna sagittis rutrum. Mauris rutrum nisl vel arcu. Maecenas mauris enim, tempus posuere, pulvinar eu, ullamcorper in, odio. Suspendisse dolor. Morbi libero mauris, ullamcorper id, fringilla laoreet, sodales at, odio. Etiam metus. Cras lacinia risus id pede. Phasellus elementum ornare lectus. Sed vitae diam. Nunc eu quam. Phasellus ipsum tellus, imperdiet nec, ullamcorper et, egestas vitae, purus. Proin mattis, lectus sit amet dignissim tempus, nunc nibh laoreet erat, in tempor erat quam at ligula. Aenean fringilla cursus sem. Aliquam erat volutpat. Curabitur luctus placerat sem. Integer consectetuer sodales lectus.
Sed vulputate nisi at neque congue facilisis. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos. Mauris ac erat. Donec elit. Duis urna pede, congue sed, volutpat id, lobortis in, mauris. Ut mollis ante ut neque. Duis viverra libero at justo. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Proin quam. Nullam nulla. Aliquam at nulla. Donec tristique imperdiet erat. Sed mollis pretium metus. In faucibus aliquet sem. Sed viverra tristique leo. Praesent ut nisi. Donec ac ligula eu nibh placerat ultricies.
Generated 5 paragraphs, 429 words, 2895 bytes of Lorem Ipsum
That was an accident. I was horsing about with the comments control.
I would like to remove it, but can’t.
I also don’t see any distinct advantages with this new presentation model except for the change in semantics. As a career C/C++ GUI developer I’ve seen the OOP model obfuscated to no end in a vain attempt to simplify the nature of coding through API’s, toolkits and template libraries. As far as web development is concerned, my attitude is “if something isn’t broken, don’t fix it”. As web developers (not unlike C++ developers) the more advanced we take our art and develop hacks to accomodate functionality that isn’t inherent in the fundamental architecture, new conventions intrinsicly inhibit the evolution of the principles of design and cause us to write hacks.
Besides, not every webpage layout follow the same style, so burdening developers with new structures such as navigation, header, etc, is re-inventing the wheel when what the new semantics accomplish is somethign that has already been addressed.
I’m really keen on new web technology, especially I love AJAX. The problem with new technologies is, that it doesn’t work with old browsers and most users don’t upgrade their browsers fast enough 🙁
Wow…it’s interesting. i will to see
I really think just having a migration to xml would be better, instead of all of these tags defined for us. seems very limiting.
This is very useful addition to the general knowledge on the subject.
I was looking for a solution to a structural markup problem I’m having and came across the “HTML+ specification”:http://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html from 1993. Now why don’t they just implement some (or most) of the tags discussed in this document?
Certainly not those hellbent on staying in the html stone age who will have to learn a host of new things.
I don’t see how it helps the standards community by blurring content with presentation once again.
Nor do I see how it helps people innovate the web by implementing very specific inflexible tags. If there’s going to be a new html it should be what we have with fewer, more general tags, not more.
Reading the specs reminds of that scene in Robocop 2 where a committee of politicians reprograms his directives and he goes from four to thousands.
I’m still not clear what the actual purpose of html 5 is? We’re already on the right track. We have everything we need to keep content, presentation and behavior separate.
“Benefits of Using HTML
* Backwards compatible with existing browsers
* Authors are already familiar with the syntax
* The lenient and forgiving syntax means there will be no user-hostile “Yellow Screen of Death”? if a mistake accidentally slips through
* Convenient shorthand syntax, e.g. authors can omit some tags and attribute values”
I thought we’d all agreed that most of these “benefits” were a “bad” thing that contributed to browser bloat and accessibility.
Excess backwards compatibility forces us to continue to limit our sites for people who refuse to move on from the stone age.
Allowing improper nesting and syntax aggravates the issue of cross-browser compatibility. I have no problem with maintaining the core elements in future versions of xhtml (as long as all presentational attributes get yoinked) but I don’t think it’s too much to ask of people to write it all in lower case and close their damn tags properly so we don’t have to deal with 8 browsers that look for and compensate for these mistakes in 8 different ways.
Has the W3C forgotten why it was formed in the first place? What’s the point of a spec that lets people ignore standards to a greater degree than xhtml transitional and strict do?
I just tried out the HTML 5
Looking forward even more towards a full scaled HTML 5 support in all major browsers.
It’s just wonderfull!
Anything that makes rendering the UI easy can only be a step in the right direction. This will enable interaction designers to quickly set up mock ups for their clients and hence enhance rapid prototyping.
good to see this in the works
I am not sure I can see the purpose of HTML 5 and changing from divs to headers, nav, etc. I like that the div is generic because of nesting multiple divs. For instance, at times I make a header with 3
I think HTML 5 is a step backwards. Definitely not a good thing. Just a cryin shame.
I don’t think the HTML5 specification will do anything to progress the Web and more to the point, it will most likely become a lost chapter in web history.
It attempts to further dictate how to markup a document to a Web browser – which in the end is just a program that draws things on a screen to present to the user. Oh, and it has a URL box at the top that allows you to warp to other presentations.
Let’s be honest, HTML was only a solution to marking-up plain text, and it WASN’T great at that either.
As a language, HTML gave the computing world:
1) the ANCHOR tag.
2) JavaScript (Because people quickly realized how dull HTML was)
A better solution:
How about a DirectX mode (Or OpenGL mode?) Or XAML or SVG mode? I mention these just for the out-of-box thinking, not that I want to write up a text document in DirectX.
But that’s why people have been excited about Flex and Silverlight – because it’s write-once, standard across all platforms in presentation.
Christ, we already have 100’s of existing languages that can do this, we just need to say YES this is the new language of the web – and then add some simple context markup to it.
This certainly is an interesting debate, but I think the comment made by Niels Matthijs at #19 and the author’s comments at #11 helped me to get off the fence, and to embrace the new version of the language. Thanks!
– Rod Homor
First of all, thanks for the article. I came across it while searching for clarification on how the
For quite some time, I have marked up all my pages with with ids (“container”, “header”, “navcontainer”, “content”, etc.), but I’ve always had this nagging feeling that I was somehow cheating the system (semantically speaking). I teach web design to high school students, and I approach the subject with an emphasis on semantic markup, so every time I teach layouts, I always wonder if I should use
I’m a little tired of my semantic demon winning out every time I teach layout design, so I’m seriously considering teaching layouts using the new HTML5 elements the way this article presented it. To me, the extra tags in HTML5 provide what I was looking for (for the most part).
The headers have also given me some semantic soul-searching as well. I usually place an
tag in the “header” div for the name of the site. Every time I do that, though, I wonder whether it’s appropriate or inappropriate to place an
or
at the top of the “content” div. Now that there are semantic sections to my page (headers, articles, sections, etc.), I suppose the title to each of those sections would most naturally be an
, and that problem is solved too.
I still plan to use a container
As to all the authors who have vented over browser implementation (especially IE), I think you are misplacing your anger. It’s a necessary evil, but we’ve been dealing with it for many years now. I’ve learned to add a few conditional ie tags to isolate IE 5 & 6 in order to fix a few of their annoying bugs, add a png-fix, and then I moved on with my life.
As to the 10-year implementation, my understanding is that the tag was not implemented by IE until version 8 (from A Day Apart: HTML5 in Seattle). They are being realistic about how long it takes for browsers to get it right (especially IE).
http://discussions.apple.com/thread.jspa?threadID=2544849
Fantastic article. Thanks for sharing overview of html 5.
Thanks for the article.
Is very important use the new html5 tags.. but it is even more important use it well!