Don’t Let HTML5 Become the New DHTML

Beers with non-HTML5 technologies imprinted on them.
This photo represents some of the technologies (pint glasses) that HTML5 (t-shirt) is thought to encompass (drink). The horror of that concept is represented by the hands (defensive wounds coming).

I had the pleasure of sharing some pints with Bruce Lawson and Chris Mills last week in London. While discussing what bands are emo versus punk rock and during an exchange of favorite phrases to refer to the chronically daft, we touched on HTML5 and its perceptions a bit.

This thought process was rekindled just this week when I got in a discussion with a not-very-technical manager of web projects who insisted on mobile support and decidedly CSS3-based styling by implementing HTML5. The key here is the insistence on using HTML5. For a little context, we use HTML 4.01 Transitional for our projects. It’s a valid and complete specification. It allows us to use things like WOFF, CSS3, AJAX, support mobile devices and so on.

I understand that many have co-opted “HTML5” as a brand for a suite of new technologies (most of them even from the W3C or WHATWG). I do not accept that, however, because it confuses the point when it comes time to make choices about technologies. This is a battle I have already fought repeatedly back when DHTML (and IE4!) became the rage and I had clients asking what technologies I would use to build their pages — insisting in advance that it be DHTML. I could explain that DHTML was just a terrible term coined to mean HTML4, CSS and JavaScript, but clients didn’t care. It didn’t matter to them. Good for them.

For developers and the people that manage them, including those who write on these topics, I have a different expectation than I have from clients. Allowing HTML5 to mean CSS3, geolocation, H.264, or any other technology just makes it harder on us who work in this space. A technology for a project should be chosen based on the goals at hand, not because a client insists on it because of a misunderstanding of a brand or because the press release will sound great when citing how cutting edge everyone is. Most importantly, a technology should not be chosen because of confusion over terminology — least of all when that term actually refers to one particular specification.

Please, fellow developer/writer/manager, make an effort to understand the technologies you reference so you do not confuse other developers/writers/managers, set incorrect expectations with clients, or generally demonstrate that you do not get it (especially if you want to work for me).

I have written on this extensively (with many links in each article that are to further details not written by me):

If you are a writer (whether a journalist, blogger or analyst) then please take a few moments to read this useful and informational post: HTML5: notes for analysts and journalists (also not written by me). There will be a quiz. I don’t know when, but there will be a quiz.

Now, to reveal how Bruce and Chris really felt about the HTML5 confusion:

Beers with non-HTML5 technologies imprinted on them. And Bruce Lawson and Chris Mills looking horrified and sheepish, respectively

Here are posts from both Bruce and Chris discussing this confusion, within the context of the new HTML5 logo muddying the point earlier this year:

4 Comments

Reply

Nice post dude.

Of course, "HTML 4.01 Transitional" is a flavour of HTML 4.01, and not a specification in its own right. I use the HTML5 doctype exclusively now, as it is easier to remember, and allows you to use everything that the previous HTML doctypes do, with no negatives. All the doctype ever did was put the browser into standards mode…but of course, try explaining that to clients!

Do you tend to discuss stuff like doctypes with clients? I thought it would be a case of hiding details like that from them, and just making sure that what you choose allows you to implement what they want? OR does it depend a lot on the client?

Reply

You are correct, the HTML 4.01 is the spec, not the transitional flavor. I was trying to be thorough about my approach.

Sometimes we discuss doctypes with clients, sometimes not. It depends on the client's technical knowledge/interest. Our agreements state the standard we will use so it's never hidden and not just glossed over in a conversation. Most of our clients don't know and/or don't care. They come to us to address a business need, not a technical one.

For those who do, we explain the specifications we use (including level of WCAG support). When they show an interest I am thrilled because it gives me an opportunity to demonstrate that they made the right choice by hiring us. When they don't, at least I know we're doing good work.

Reply

Thanks for the explanation dude – I am always interested in seeing how normal companies deal with this stuff out in the wild.

And sorry for being so anal at you ;-)

Reply

You're not being anal, you are being precise. Considering how much I expect that from others it's fair to make me clarify.

As for us being "out in the wild," that only scratches the surface…

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>