Hello HTML5!
Here I’d like to outline (for myself as much as anything) why I think the web should be using HTML5 right now.
For the web standardista community XHTML has long been the benchmark for high quality front-end markup. But its promise – a future web of lean, semantic and multi-purpose XML – has not come to be.
I think XHTML is too pure in its ideals to fit with the sprawling ‘do it yourself’ nature of web authoring, let alone lack of support by major browsers. It still has its place in the world, but for now it looks to go down as a transitional phase in the history of mainstream HTML. Which is ironic as the most practical version of XHTML for use on the web has been the transitional variant (I should note that using any transitional doctype is a compromise; it is intended to support legacy code until conversion to a strict doctype is practical).
For good reasons it’s clear that XHTML has failed for 99% of what people are doing on the web right now.
Things that do not support XHTML 1 (of any variety):
- Microsoft Internet Explorer (cannot accept mime type application/xml)
- Most WYSIWYG editor generated markup
- Most mashup generated markup
- Most third party JavaScript widgets
Things that XHTML 1 (of any variety) does not support:
- A rich set of semantic elements to choose from
Element.innerHTML(core to every JavaScript library)- Inline JavaScript without ugly escaping
- The target attribute on hyperlinks (which is not as bad as some would say, hence its inclusion in HTML5)
It’s not all bad
One of the reasons XHTML has been so enthusiastically adopted in the past is that it enforces a clean consistent markup style. Tag soup and font tags were awful, so the reaction in wanting to make the web strict XML was actually very beneficial; it has created an online community of designers and developers who appreciate and can author clean, maintainable and high quality markup.
And now... HTML5
HTML5 for me represents a complete rethinking of the HTML specification based on the way the web has evolved. While I won’t try to cover all the detail here (as it has been done very well elsewhere), I would like to pick a few details that capture how HTML5 has taken the web forward without breaking anything.
First look at the HTML5 doctype:
<!DOCTYPE html>Nice and simple isn’t it. The good part is that it’s not just a pretty face; it invokes full standards rendering mode in all browsers. This is more than be said for transitional doctypes that invoke the maddeningly named ‘almost standards’ rendering mode in some browsers and ‘standards’ mode in others. Like we need more cross-browser incompatibility.
With HTML5 you can even type it from memory, and know you’re running your code in strict mode in all browsers.
Have you ever wondered why the type attribute is necessary in your style and script tags when there is only one styling language and one scripting language used with HTML? In HTML5 type attributes for these elements are now optional. An elegant move forward whilst remaining fully backwards compatible.
Forms get a substantial overhaul in HTML5. Form validation that is now handled by JavaScript on the client becomes native to the browser in HTML5. Form inputs now have a fairly extensive set of type options; and because the default input type is text, browsers that don’t recognise the new input types can degrade gracefully.
The new semantic HTML5 elements, such as nav, section, time etc. can all be used now, with the caveat that IE does not style elements that it does not recognise. This can be easily fixed with a little JavaScript bootstrapping.
But for me a JavaScript dependency on this level does make the use of these new elements somewhat hard to justify, at least until the most recent version of IE can support the styling of these elements for users without JavaScript. It has been suggested that you could serve two versions of your markup with a little regular expression hackery – one for IE, one for everyone else – but that seems like overkill to me.
Keeping it clean
The only drawback I can think of with using the backwards compatible HTML5 features, over an XML type markup language, is the syntax rules. Because in HTML5 there is no requirement for lowercase tags and attributes or closing tags for all elements, it does lead to the probability of inconsistent and less readable markup. All these examples are valid HTML5:
<DIV TITLE=shout></DIV>
<div title=”talk”></div>
<p>Paragraph with no closing tag
<p>Paragraph with a closing tag</p>
<img src=”myimg.jpg” alt=”Where’s my close”>
<img src=”myimg.jpg” alt=”Here” />
<br>
<br />I personally don’t think mixing the open/closed tag styles is doing anyone any favours. It just looks wrong if the author is making arbitrary decisions about when to close tags. The problem is the inconsistency; readable markup is consistent. Because HTML requires some tags to be closed it is better if they all open and close as they do in the XHTML standard.
Tagged with:
