Issues and Strategies for Moving to Html 5

Primer on Html 5

There has been a lot of buzz in the blogosphere about HTML 5 lately, from google endorsing it as the future to the W3c dropping efforts on XHTML 2 to focus on HTML 5. The consensus seems to be that HTML 5 is the future and we should start planning on using it in the future and can even use it now. It should be noted however that HTML 5 is not a standard yet, but only a draft and is subject to change before it becomes a standard and current browser support is a mixed bag.

Some useful links:

23 Essential Resources for Html 5

Misunderstanding Markup - comic that explains HTML 5 vs XHTML.

Real World Issues for a Content Management Systems To Switch to Html 5

So from reading the above linked articles and others it seems like we can easily change to the HTML 5 DocType and things will be pretty much compatible at least as long as we don't use any of the new HTML 5 elements that might not be supported in all browsers yet. In mojoPortal the doctype is declared in the layout.master file of a skin so it can be a personal choice wheether to change to the Html 5 doctype now or not. Currently the doctype in our skins is XHTML 1.0 Transitional, so to switch to HTML 5 we would just change this:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
<html xmlns="" >

to this:

<!DOCTYPE html>

In fact I've done that here on, though I'm running a newer build than the current release (dogfooding for the coming release), so you should probably wait for the next release to do this if you want to. One of the things I've added is an option on our validator link to configure it for HTML 5 instead of XHTML like this in layout.master:

<portal:XhtmlValidatorLink id="lnkw3cValidator" runat="server" UseImage="false" Html5="true" />

This Html5=true merely changes the label and/or image on the validator link to HTML 5. I've also added a property IncludeHtml5Script to our IEStyleIncludes control

<portal:IEStyleIncludes id="IEStyleIncludes1" runat="server" IncludeHtml5Script="true" />

if set to true we inject the javscript as mentioned in this article inside IE browser comments to make it possible to use some of the new HTML 5 elements in IE 8 (though I'm not actually using them yet to avoid compatibility issues you could use them in custom features). So it renders in the page like this:

<!--[if IE]>
<script type="text/javascript">


Ok But Aren't There Any Gotchas?

I got kind of excited about changing the doctype to Html 5 just in preparation for the future even though we can't use the new Html 5 elements yet without breaking some browser compatibility, especially for IE 6. I'm sick of caring about IE 6 myself and admittedly some of our skins are a little funky in IE 6 today and I don't care enough to fix them though some of them work pretty well too. Its long overdue for users of IE 6 to upgrade. But its still in wide enough use that many web site owners do care and you can make skins that work well in IE 6 using mojoPortal its just more work tweaking the IESpecific.css file and testing in IE 6. Anyway after changing to HTML 5 doctype on and testing in IE 6 and not seeing any major problems I thought I would change the included skins to HTML 5 for the next release. I did this yesterday but reverted it today. I had been testing using the wc3 validator using the direct input method, viewing the source of the page and pasting it into the validator and was happy because it was reporting it as valid HTML 5. However after testing some pages on using the validator link or using the url input method I got different results. It seems there is a bug in the w3c validator where if you use direct input it passes things that should not pass but when you use the url it finds problems on the same page it validated as direct input.

Specifically what I ran into was border is not a valid attribute on img and frameborder and scrolling are not valid attributes on iframe, however the presence of these attributes does not seem to be detected correctly with the direct input validation but it is detected using url validation. I reported this bug to the w3c public mailing list tis morning. Fixing the border on img was fairly easy so I did that, you can easily set the border on img using css so its really not needed to use border="0" to remove a border for example. However the iframe issue is a lot more of a problem. If you remove frameborder="0" from an iframe there is no way to remove the 3d border that is rendered in current browsers using CSS. I don't think there is a working CSS alternative to scrolling="no" either. So for the moment I choose to just live with it that a few pages on won't validate but for the skins included in mojoPortal I decided it was pre-mature for me to change the doctype to HTML 5 and changed it back and leave it up to users if they want to do that. 

As previously mentioned, HTML 5 is currently just a draft so I don't want to get too concerned with validation against it while its still draft. Who knows since current browsers don't work well look right with iframes that don't use frameborder=0 and scrolling=no, maybe they will change their minds about dropping these attributes or give us an HTML 5 Transitional to validate against that will allow these for backward compatibility.

So where does that leave us?

Well I think we have to proceed cautiously and very slowly toward HTML 5 but we are very limited in what we can do in mojoPortal without breaking compatibility especially for public facing features. If I were to start using new elements and attributes of HTML 5 it will break validation for those who choose to continue using the XHTML 1.0 Transitional doctype in their skins and it would probably break functionaility and visual layout in some browsers. Potentially we could move forward in the admin pages and other non public facing pages but the benefits would be minimal. The real value of HTML 5 will be when we can use it for public facing pages, the improved semantics available using the new elements like header, footer, section, nav, article, aside etc will be of most value in public facing pages, but we really can't move there yet because of the mixed browser support. Once HTML 5 graduates to a Standard instead of a draft and browser support for the new elements is more widespread it will be tempting but we will still be faced with that fact that many people use old browsers, perhaps even we will be waiting for the end of life of the current crop of browsers anxiously like we are waiting for IE 6 to go away today. The benefits of changing to HTML 5 doctype today are minimal and there is the minor downside of losing validation on some pages where we are using iframes and maybe other issues that I have not bumped into yet. HTML 5 does indeed look like the future but the future is not here yet unless you are willing to give up support for IE 6 and possibly even IE 7 as I'm not sure if the javascript trick for lighting up the new elements in IE works in IE 7 as it does in IE 8. (update it does work) I for one don't see the merit in building browser specific applications, the huge benefit of the web has been the ability to write apps that work in all browsers though of course there have been bumps along the way like supporting Netscape 4 was back in the day and like supporting IE 6 is today, it takes some extra work. I don't want to try and move forward too fast and find myself battling to get things working in all browsers. I'm tempted to change my doctype on this site back to Xhtml 1.0 Transitional since I'm not really getting any benefit from changing to HTML 5 doctype though I have not had any major problems other than some validation issues everything seems to work the same and nothing is visually different in any of the browsers I tested.

UPDATE 2009-08-03

I actually tried this javascript create element technique with IE 6 and it seems to work! So even though the article says IE 8, it seems it should also work for IE 6 and 7. So maybe it is possible to switch to Html 5 and use the new elements. So the remaining issues would be that there will be some things that don't validate like framborder=0 and scrolling=no that we would still need to use. And the problem still remains that if I were to start using the new html5 elements that would mean that all users of mojoPortal would need to change to the Html 5 doctype because the new html 5 elements are not valid for Xhtml.


Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.