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

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?

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.

This tag should be used to define elements related to the main content. Usually this is the right column in most site designs. Which is pretty nice, as you can now have your content and related content separately marked.

It becomes even nicer when there is a vertical navigation. Putting the <nav> tag in the <aside> tag means that the given navigation takes you deeper into the site structure. The pages in the navigation are specifications of the current content.

When the vertical navigation is the main navigation, it doesn’t need to be in an <aside> tag, as it is not related to the current main content.

This is a really nice example of how to structure your page and give elements semantic meaning, so machines have a better idea of how the elements are related to each other. It’s what html is all about, no ?

Looking forward to working with these tags. It’s like getting a second dictionary.

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.

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.

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.

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 <div>, which is just a box. For all other elements, the <div> element is still available, so I don’t really see how we’ll lose flexibility. We’re just given some common element a more detailed name and semantic meaning.

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.

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: <div role=“header”></div>. 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.

A number of comments suggest that we’ll never see the benefits of HTML 5 but that’s simply not true.

# <canvas> is implemented in Firefox, Opera (& Opera Mobile), and Safari (& Mobile Safari). It also has “an extensive test suite”:http://philip.html5.org/tests/canvas/suite/tests/ that will help with interoperability issues. (Is it perfect? no. Is it in IE? no. bummer.)
# <video> is “implemented in the Opera 9.5 betas”:http://my.opera.com/desktopteam/blog/2007/11/08/experimental-video-build-released-on-opera-labs and in the “WebKit nightlies.”:http://webkit.org/blog/140/html5-media-support/
# “WebKit nightlies implement HTML 5’s Offline storage API”:http://webkit.org/blog/126/webkit-does-html5-client-side-database-storage/
# 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.)
# There is “an open-source HTML 5 parsing engine written in Python & Ruby”:http://code.google.com/p/html5lib/

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:

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.

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.

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.

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.

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 <header>, <footer>, etc. are abstractions, not concrete realities. What happens if I have a header and subheader? What happens if I have two navigation bars? Why do I have to put <ul> INSIDE the <nav> block?

It feels to me like we’ll have to define what sorts of elements these things are - in other words, the header acts like a div, or the nav acts like an unordered list - which seems redundant to me. I don’t know. Why confuse things with unneeded additional elements when there are other, more powerful things we could be addressing?

Finally, I have agree - I know the process is necessarily long and laborious, but damn - years and years will go by?

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

<header>

and

<div id=“header”>

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

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.

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)

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 <nav> over <div id=“nav”> (e.a.) - the benefits for you as the author will be limited. You _already_ know what meaning that element will have on your site, so really, all that’s left for you is having an easier styling hook and saving a few keystrokes.
But the thing is, _everyone else_ doesn’t **know** what id=“nav” means. There is no standard which specifies this, and no way to rely on it. (Plus, other developers will use id=“menu”, “id=“navigation”, id=“navmenu”, or one of a hundred other variations.)
And the real benefit will be exactly for all these other people; probably including benefits we can’t even begin to imagine yet…
What I can imagine is, for example, that screen readers could provide a standardized function to skip straight to the navigation menu (or to skip it altogether), now finally **knowing** exactly what part of the site _is_ that navigation. Search engines could take all this extra information into account in their ranking algorithms and provide us with ever more useful results. And that’s probably just scratching the surface…

The desire to label these common parts of our sites is there already; we all do it (if we didn’t, it wouldn’t have been considered for inclusion in HTML5).
HTML5 is just providing an easier mold for this behaviour, minutely helping us, and potentially greatly helping the world.

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

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.

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.

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?

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

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.

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!

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 <div class=“header”> or <div role=“header”> over <header> - unless what goes into a header will be restricted…

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.

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.

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

<body>

<h4>Apples</h4>

Apples are fruit.

<section>

<h2>Taste</h2>

They taste lovely.

<h6>Sweet</h6>

Red apples are sweeter than green ones.

<h1>Color</h1>

Apples come in various colors.

</section>

</body>

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.

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?

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

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 <header>, <nav> and <article>. But these can surely make your content more usable and accessible for users of non display browsers. As Lachlan Hunt said:

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

A specific advantage of the <header> tag would be to me, that I can preserve the use of <h1> for the first heading above my text, instead of displaying the name of the site.

But I agree with most commentors that the development cycle of html and other web standards is too long. Not sure who to blame though.

The HTML 5 specification should also include tags that extend the basic structure of documents. Block-level elements such as:
- <title>
- <subtitle>
- <byline>
- <abstract>
And an inline element of <author>.
Or, as suggested by others, rather extend the XHTML specification with a _content=“keyword"_ attribute to convey meaning to the UA.

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.

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.

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 <header> and <div id=”?header”?>, cause the last one shouldn’t exists on a page at all. Say, you have to build a page which will be viewed in the default form, why on earth would you use a <div> or <span> tag? It tells absolutely nothing to the browser or other software about its content.

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.

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 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?
<div id=”?Cabecera”?>Header in Spanish</div>

We’ve never particularly worried about other elements being named in English only. Nobody has said that we should allow <cuerpo> as well as <body>, or that CSS should recognise ‘izquierda’ as meaning ‘left’.

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.

So HTML5 will introduce a load of new semantic tags. But what exactly will they achieve? To the end user whether a tag is <header> or <div class=“header”> is irrelevant. It will look the same. To the browser I imagine it makes no difference either. I imagine a header tag will be rendered just like a div tag, depending on the default CSS a browser applies to it. It might help with some accessibility issues and might also help with interoperability between automated systems I guess.

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. <header> or <div class=“header”>? How about the “Fighting Mongooses”, that’s a good team name.

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

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

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.

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 <div>s. 1 main div, 2 nested divs, one floated L and R. Can you do all this nesting with HTML 5? Theres more complex layouts then just those basic areas mentioned. how can 5 do that? And what is wrong with XHTML and CSS??? I like CSS and the things I can do with it.

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!

First of all, thanks for the article. I came across it while searching for clarification on how the <section> & <article> elements might play out on a page. Your example was great & made perfect sense.

For quite some time, I have marked up all my pages with <divs> 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 <div>s in so many different ways (we’ll call it the semantic angel on my shoulder speaking).

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 <h1> 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 <h1> or <h2> 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 <h1>, and that problem is solved too.

I still plan to use a container <div> every now and then to allow myself more CSS options, and I’ll probably always have a little semantic angel on one shoulder trying to convince me otherwise.

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