views:

54

answers:

3

I'm beginning a very large project in the coming weeks and am trying to decide if I should take the leap into HTML5 land or stick with my time trusted XHTML 1 strict.

The site will be huge. Thousands of pages, video, custom CMS system, lots of social media integration, etc. I'm trying to justify using the new technology, but am unsure (as I've never done a huge site in 5) if everything will go according to plan on older browsers.

I can sit there and talk all day long about the new technology that html5 brings, but when you're sitting in a board room full of execs and the site doesn't work on their IE6 machines...not good.

Let me know what you guys would do. - Thanks

A: 

HTML5 is a better choice here. It offers improvements as well as compatibility; and will render in all browsers. Modern features such as <video> can be sniffed for and replaced by FLV players or other alternative in non-compatible browsers.

XHTML has been redundant since its creation, and XHTML 1.0 (when sent with the correct mime type) doesn't work at all in IE6. Using HTML5, it will both render and be functional, assuming you handle the lack of support of modern features properly.

You
Thanks for the input!
I don't think anyone is advocating serving `application/xhtml+xml`. (It'll be years until IE9 is the baseline browser and that'll work.) That doesn't make XHTML redundant at all. It's much easier to handle at the server end and making it HTML-compatible is pretty simple; plus of course it is the standard for low-end phone browsers (XHTML Basic/Mobile Profile). HTML5 doesn't magically manage to provide its new features to IE6 either: using the non-empty elements that it introduces over HTML4 will also break parsing in IE.
bobince
@bobince: Using the html5shiv, new HTML5 elements won't break IE. Serving XHTML as `text/html` negates **all** pros of using XHTML in the first place, and is discouraged. And while HTML5 won't be *better* than HTML4 in IE6 (which is what you get when you send XHTML to IE), it will be *at least as good* — and the improvement in more modern browsers justifies using it.
You
The typical approach is MIME negotation i.e. send `application/xhtml+xml` only if browser supports.
Maciej Piechotka
But negates the use of XHTML for all versions of IE. There is **no** compelling reason to choose XHTML over regular HTML, in the general case.
You
+1  A: 

Choosing to use the HTML5 vocabulary is an orthogonal issue to whether to use XHTML syntax. If you want to use HTML5 elements and still work with XML production tools, you can always use XHTML5.

HTML5 is not yet finished so to some extent you will be labelling your documents with a doctype of unknown quantity, and validating it isn't as easy. But if your project is going to be using elements like <video> at any point, using an HTML5 doctype makes sense. (Though hopefully if you are using a custom CMS it should be relatively straightforward to adjust the doctype it spits out in the future anyway?)

None of this is relevant to IE6 compatibility as such. IE6-8 will render the page the same with any of the Standards Mode doctypes, and won't ever render <video> regardless of whether you're using an HTML5 doctype. You will certainly need fallback for any HTML5 extensions you use, such as Flash for <video>. The extended HTML5 semantic elements like <section> or <article>, you don't really get anything for using anyway; avoid them for now.

bobince
The only purpose of the doctype in HTML5 is to trigger rendering modes in browsers. Validation is not really an issue; validator.nu is pretty much up-to-date with the HTML5 draft.
You
Thanks for the input!
Using html5shiv, IE will render new HTML5 elements as empty elements (basically `<div>`s), which you can style using CSS.
You
Helpful with IE are comment conditionals. It is non-standard extention which allows to comment out part of code (or uncomment) specificly for IE.
Maciej Piechotka
html5shiv is not a complete solution; you will still face scripting problems, in particular with `innerHTML`. It's not worth the pain for now, as there is little-to-no-gain. In the future, sure...
bobince
A: 

While HTML5 is not fully complete, much of it can be used today. It was designed with compatibility in mind, so a number of the new elements will work in older browsers, even if they don't specifically support HTML5.

You can start using the new doctype - any browser will recognize it as valid. From there, you can do your layouts using the new semantic structural elements - section, aside, header, footer, etc. You'll need to style these a bit to get them appearing correctly, and there is a shiv script for IE compatibility. It takes a little work, but they provide much more semantic value than the generic div.

audio and video elements have fallback capabilities for older browsers, so by all means use them.

Various new form elements and attributes are not widely supported yet, so you probably won't get much value from them right now. Though I quite look forward to using them, as they will reduce need for client-side scripting a fair bit.

IE6 is the obvious element in the room, but with the right setup, and use of fallbacks in HTML5, there should be no serious issues from using HTML5. CSS is another matter, of course. But IE9 is looking rather good, and will help to raise the bar for standards support.

Grant Palin