To HTML 5 or not to HTML 5, that is the question

[Hugene]

Starting a new site, and I was wondering if I should stick to loose HTML 4.1 (my favorite tag soup) or hop on the yet small train and start fresh with HTML 5?

What are your opinions? I read a little bit some older posts and people seem to favor sticking to HTML 4.1.

My concerns with HTML 5 are:

1) Will older browser display it OK (assuming I won't use any new tags, which I wont)?
2) Will browsers in Mobile Devices display it OK?

[Fotiman]

If you're not using the newer tags (ie - you're essentially serving HTML 4.1 content but with an HTML5 doctype), you should be fine. Here is a good primer for getting started with HTML5: [diveintohtml5.org...]

[kaled]

There is no point serving HTML 4 code with an HTML 5 doctype. When you add features that require HTML 5, change the doctype.

However, you might consider test-validation with an HTML 5 doctype if you are concerned about not using features that will become deprecated (or even dropped). I haven't looked closely enough to determine if this is an issue or not.

Kaled.

[pageoneresults]

1) Will older browser display it OK (assuming I won't use any new tags, which I wont)?
2) Will browsers in Mobile Devices display it OK?

Google use an HTML5 DOCTYPE, it is meant to be backwards compatible.

You can use the new elements and do just fine, I've already got a handful of HTML5 sites out there and they are performing as expected. I use the new elements but I've wrapped their content in <div>s for now until support is fully implemented. I can still segment my documents semantically using HTML5 elements, the basics, and cover all my bases e.g.

<aside>
<div id="leftnav">
</div>
</aside>

<aside>
<div id="rightnav">
</div>
</aside>

There are some CSS rules to use so that the new elements are treated properly. There are a few articles out there explaining the use of those rules.

All of our new sites being launched use HTML5 templates. It's a tough call for us as we have many XHTML based applications. But, for static brochureware and/or promotional sites, HTML5 is just fine, go for it!

[Hugene]

If I understand correctly, the <div> tag is also valid HTML 5, and will be rendered as good old <div> by older browsers:

<aside>
<div id="leftnav">
</div>
</aside>

So basically I can start using HTML 5.0 and older browsers will still see it as valid tag soup?

HTML 5 here I come (I guess)

[Hugene]

PS: Fotiman, thanks for the great link

[caribguy]

This will save you a bunch of headaches in IE6:

article, aside, dialog, figure, footer, header,
hgroup, menu, nav, section {
display: block;
}

[mattur]

So basically I can start using HTML 5.0 and older browsers will still see it as valid tag soup?

Older browsers will see HTML5 as "HTML" - exactly the same way they see HTML4, HTML3.2, etc.

Browsers use a "HTML" parser for all HTML pages, and HTML5 describes for the first time how this "HTML" parser works (as well as extending it with new features). HTML5 is designed to be backwards compatible; it's based on how existing browsers work.

[mattur]

caribguy:

That's certainly useful, but IE6, IE7 & IE8 do not apply CSS formatting to elements they don't recognise. The workaround is to use a Javascript shim:

[code.google.com...]

(or avoid using/styling new elements until widely supported)

[caribguy]

Forgot about that, thanks! IE needs the shim and the css...

[Hugene]

Alright, so I am reading through the book suggested by Fotiman, and basically, after having gone through <header>, <article> and <time> I am starting to understand that HTML 5 is an attempt at introducing further semantics in HTML, with the goal of having machines understand the structure of your document.

I will be honest here: the way I've always designed web pages until now, I never really cared about the implicit outline or sectioning of the page. I never used <h2> or higher and the only reason I used <h1> was for SEO purposes.

To me, the end user is what is important. The end user is a human, who looks at a rendered web page. I've always indicated titles with <span class="title"> and all other sectioning was done in similar ways.

But now, I can use <header> and <footer> instead of <div id="header"> or <span class="footer">, with the purpose of having a machine understand that this is a header and this is a footer, or with the purpose of restarting the <h1> element independently of the previous nodes in the outline doc.

Maybe I am wrong, and as a software developer I should be, because re-usability should be key, but IMHO this is pure and simple overkill. I really don't care how a computer program sees my document, because my only target are humans. I am not creating documents to be exchanged between machines, I am not creating documents to be archived as a source of structured knowledge, I am creating human target content.

I don't need to fix the hierarchy of <h1> to <h6> and I really don't need to indicate to a machine when the content was created with <time>. To me, these semantics in HTML 5 are a waste of time.

But SE will (and certainly do) love them, so if we want to stay on top of the SEO game, I see a great advantages in using HTML5.

[Hugene]

<input type="email">, browsers don't do anything with it, except for the iPhone that changes the keyword. Seriously?

The more I read, the more HTML 5 sounds like garbage.

Sorry, correction: apparently Opera 9 validates the email address, now that's more like it.

[mattur]

<input type="email">, browsers don't do anything with it

Only browsers that support the new <input type="email"> element do anything with it.

This doesn't mean HTML5 is "garbage", it means HTML5 is, to use the technical term, "new" :)

[Fotiman]

Hugene, there are other benefits as well. HTML5 adds new form controls, multimedia elements, and improved structural elements (header, nav, article, section, aside, and footer) and semantics. Sure, you can continue to do:

<div id="header">

but eventually, the HTML5 components will just be *easier* to use (and shorter):

<header>

Development will get easier because your code will be cleaner and leaner. So don't dismiss HTML5 just yet. I'm sure there were people who said "what do I need HTML 4 for... HTML 3.2 works just fine!" Sometimes its not always immediately obvious what the benefits of change will be. :)

[pageoneresults]

I will be honest here: the way I've always designed web pages until now, I never really cared about the implicit outline or sectioning of the page. I never used <h2> or higher and the only reason I used <h1> was for SEO purposes.

It's been part of the HTML protocol since inception. Sure, folks were able to wrap their content in basically anything back then. Times have changed.

HTML5 is an extension of HTML4. There are additional elements and attributes that you can now use to extend the meaning and functionality of your documents. If you didn't use them in HTML4, then HTML5 may not appeal to you. It is all about separating presentation from markup and sectioning documents into logical chunks of metadata that can be read by machines.

There's really not much difference if you're working with the basic elements. The core group of HTML5 Elements that define the semantic structure of your document can be used safely from what I've seen. I have a very small group of sites though so don't run out and make the changeover just yet.

I like to study what the leaders are doing, those who are writing the protocols. Google is involved with the push to HTML5. They use an HTML5 DOCTYPE and are now validating interior pages. I figure if Google is using it, I'm probably going to be okay using it myself down here at this level. ;)

Taking my example above and extending it to show more semantics...

<aside>
<div id="leftnav">
<ul>
<li></li>
</ul>
</div>
</aside>

<aside>
<div id="rightnav">
<ul>
<li></li>
</ul>
</div>
</aside>

In most instances, left and right navigation elements contain lists of links or other bullet points. There is meaning behind every element you see above when thinking about machine readable content. ;)

[Hugene]

Only browsers that support the new <input type="email"> element do anything with it.

Agreed, but the problem is that the standard does not mandate what should be done with type="email". I agree that the logical thing would be to check the validity of the email, but I am not sure that as a developer I want to leave this responsibility to the browser.

What annoys me is that if you remove the <header> or the <aside> tags from the HMTL, the browser will display the page exactly the same way as if they were there. To me, this is fluff, if a tag does not affect the rendering, then why is it there? I can't think of a single tag like this I've used.

I understand the idea of semantics and their understanding by machines, but to me, this is work we're doing for G and the other SE, and not for our end user. Anything you don't do for your user is useless.

Except that if you don't do it, your site will start dropping in the SERPs. This feels like blackmailing. For example the whole microdata push by Google. Why would I implement this, so that G can display my events listings straight on their pages?

[Demaestro]

Does anyone know of any reasons that creating new pages in HTML 5 would be bad if other pages on the site are HTML4.1?

Just curious what side effects mixed doc type sites may incur.

if a tag does not affect the rendering, then why is it there? I can't think of a single tag like this I've used.

They don't change the rendering but they still add value in the markup. Usually it is to give you more control over container tags. A good example of this is <tbody> and <theader>

[albo]

To give you a resource for html5, I offer the html5doctor - where you'll also find a version of the javascript shiv mentioned earlier. (There are several versions out and about.)

For a discussion as to why html5, if you're interested in deploying your site(s) on mobile devices, you might want to read Mac Slocum's interview with Eric Meyer on O'Reilly Radar, in March this year. (I'm not permitted to cite the URL for you but it has to do with "why html5 is worth your time".)

On my sites, I found html5 to provide a great benefit to me *and* the visitors (win-win) by enforcing upon me a more strict organization, decreasing code bloat, and opening the door to easier mobile testing.

[mattur]

Agreed, but the problem is that the standard does not mandate what should be done with type="email".

How browsers should handle new input types is specified in excruciating detail [whatwg.org] :)

But you can continue using <input type="text"> if you prefer to. Remember HTML5 is new; no browser is even close to fully implementing it yet.

I agree that the logical thing would be to check the validity of the email, but I am not sure that as a developer I want to leave this responsibility to the browser.

You will still be able to use your own custom validation js routines instead, if you want to. It's up to you.

I understand the idea of semantics and their understanding by machines, but to me, this is work we're doing for G and the other SE, and not for our end user. Anything you don't do for your user is useless.

Think about it: we could just use <span>'s and custom classes for everything. Why don't we do this? Parsability, maintainability and accessibility. But if you don't want to use the new structural elements, that's fine too.

Except that if you don't do [use HTML5], your site will start dropping in the SERPs.

There are loads of completely-baseless SEO rumours out there already. I really don't think we need to start any more... :)

[mattur]

Does anyone know of any reasons that creating new pages in HTML 5 would be bad if other pages on the site are HTML4.1? Just curious what side effects mixed doc type sites may incur.

Hi Demaestro, the doctype declaration is only used by browsers to switch between standards and quirks modes. The HTML5 doctype <!DOCTYPE html> turns on standards mode, so if your existing pages use a quirks mode HTML4.01 doctype that could be a problem, as the CSS would be displayed differently.

Otherwise, if you're already using a standards mode doctype, there should be no problems.

[edited for clarity]

[Sgt_Kickaxe]

Starting a new site, and I was wondering if I should stick to loose HTML 4.1 (my favorite tag soup) or hop on the yet small train and start fresh with HTML 5?

Go ahead and jump in, let me know if the water is warm.

Personally I'm more interested in seeing what happens with popular CMS's that upgrade but their plugins don't all upgrade at the same time. Throw in a sprinkle of database changes and I'd expect many thigs to be achtung for a little while, not because of HTML5 but because many sites will mix the two.

[tedster]

A doctype applies to a document -- that is, to a "page" and not to a "website". There are many sites that mix doctypes with no trouble from browsers or search engines. In fact, it's REALLY common to see the HTML 4.01 doctype begin the soruce code but then some XHTML tagging thrown in. That doesn't make trouble and it is much crazier than having some URLs on a domain using a different doctype.

I have some frameset doctypes on sites that are mostly html 4.01 strict - not a problem and not invalid, ether.

So beginning to write new pages in HTML 5 without first converting the old pages is not going to make any trouble, technically or with the search engines.

It's an interesting fact that there is no technical definition for either the word "page" or the word "website", even though we toss them both around all the time.

[gethan]

Given that;

- backward compatibility can be achieved with the js IE script.
- <div class='nav'> can be replaced by <nav> (ditto for header, footer etc)
- <h1/2/3>'s are used as intended
- The browser handles videos - not flash.
- accessibility is improved - so it's not just machines benefiting
- the rise of apple,tablets, mobile browsing
- new browsers - hey chrome
- that the biggest changes mirror the way I've developed past projects

For new projects I'll be using HTML5

I'm hoping to stay just slightly ahead of the curve.

[edited by: gethan at 5:59 am (utc) on Jun 1, 2010]

[cruxabhi]

I don't think so you can stick on one .. I added so many new things to site

[IanCP]

So I figure us olden day "no frills" users of <h1>, <p>, <b> etc. backed up with a .css file have nothing to be concerned with?

Some people actually write pages of plain vanilla content without any need for frills.

Nes pas?

[sullen]

But isn't HTML 5 still at draft stage? There is absolutely no way I'll use it until W3C publish a formal recommendation, because I can't be bothered to keep changing code.

...and even if it was finalised - acheiving backwards compatibility via javascript? not if I can possibly help it.

[yaix2]

I usually use a !DOCTYPE html but otherwise only a few of the new tags until more browsers support them.

[Solution1]

Having gotten convinced of the uselessness of DTD's (the Content-Type header is what's in actuality making the difference between HTML and XHTML), I'm now putting HTML5's empty doctype above my pages.

[jbinbpt]

So I figure us olden day "no frills" users of <h1>, <p>, <b> etc. backed up with a .css file have nothing to be concerned with?

Some people actually write pages of plain vanilla content without any need for frills.

Nes pas?

Awful amount of existing content that won't be changed. The plain vanilla approach will work until items are completely depreciated.

[pageoneresults]

HTML5 is here already. Google have been using the HTML5 DOCTYPE for quite a while now. I've been monitoring 750 websites for validation since 2009-09-01. I've watched more than a handful of top properties make the switch to HTML5. If your HTML4 now, you can change DOCTYPEs and not skip a beat, it is that backwards compatible.

Here is just a small sampling of Brand websites that have switched to HTML5...

1. Baidu.com
   
2. Google.com
   
3. Google.com/Analytics
   
4. Guardian.co.uk
   
5. LinkedIn.com
   
6. ND.edu
   
7. Search.Yahoo.com
   
8. WHATWG.org
   
9. Wikipedia.com
   
10. YouTube.com

Oh, and for those who keep saying that Google doesn't validate, check out Google.com/Analytics and other interior documents. Google is slowly bringing things up to snuff and is validating HTML5.