Another look at HTML 5

It has become evident to me that some of my previous comments about HTML 5 and what is going on in the HTML Working Group are the result of misunderstanding and overreacting on my part. I no longer think things are quite as bad. I still believe there are some problems that need to be solved though, so I'm going to try once more to explain my feelings and suggest a few things that I think would improve the situation going forward.

My personal reason for writing web related articles and tutorials is that I am really passionate about doing what I can to make the Web a better place that everybody can use. That thinking can be applied to many aspects of web design and development, but since this is about HTML 5 I'll be focusing on creating markup in this article.

I want to improve the Web

I really want the Web to work better, for more people, than it does today. In order to make the Web a better, more accessible, user-friendly, and interoperable place, I believe that developers, designers, CMS vendors, and authoring tool vendors all need to be educated. We all need to adopt best practices in our work, and encourage others to do so as well. Writing tutorials is one way of doing that, but I don't think it is enough.

Tutorials, blog posts, and books only reach those who find and read them. Unfortunately that means most people who work with the Web read little, if any, material that helps them improve their knowledge of HTML. I think that is quite obvious when you look at the current state of the Web.

So, while tutorials and guides do help, they only help those who want to be helped and know that they need help. They do not help people who want to do things right but are unaware that they are using HTML incorrectly. If they or their clients knew they were doing things wrong, many of those people would learn how to do things right. At least that's what I, perhaps naively, want to believe.

Backwards compatibility and error handling

And that leads me to HTML 5, backwards compatibility, and standardised error handling. Backwards compatibility in browsers I don't really have a problem with. I realise that it is necessary, though I don't quite understand why browsers can't treat new content (content that somehow claims to be HTML 5) in a different way than they treat current content. I am told that it is too expensive for browser vendors to do so, which sounds odd to me. But I am not a software engineer, so what do I know. They are probably right about that.

Error handling then. Yes, error handling is definitely necessary. People will always make mistakes, and standardised error handling is great for interoperability. But here is where my opinion differs from that of most browser vendors (and many others). I really am naive enough to think that browsers somehow making the user aware of errors in the markup will eventually lead to an improvement (and no, I do not believe that the W3C can force browser vendors to display error messages). Let me try to explain why.

I am not saying that browsers should stop rendering when they encounter an error. Nor should they display a modal alert or open a window that displays the erroneous markup. An inconspicuous icon of some kind, perhaps in the browser status bar, would be enough. Two different examples of how that can be done are provided by the HTML Validator extension for Firefox and the iCab browser. My point is that it doesn't have to be obtrusive. It shouldn't be. If the user or developer wants more info, they can click the icon.

Some say that any browser vendor that implements something like that would lose market share. I simply cannot understand why they would, but if someone can prove that is what would happen, please do.

Leave most cowpaths unpaved

There are a number of proposed design principles for the HTML Working Group. Most of them make perfect sense, but I think a potentially dangerous principle is "Pave the cowpaths", which says:

When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new.

Depending on how you interpret that, it can lead to insanity such as the following:

Luckily neither of those cowpaths have been paved in the HTML 5 specification, and as far as I understand it they won't will be. However the explanation of this design principle needs work to avoid misunderstanding.

For the record, I do believe that if upon investigation a widespread practice is found to make more sense than what is currently in the spec, it should probably be adopted.

The HTML 5 Specification

Some of my previous worries and complaints are no doubt caused by me misreading the HTML 5 specification. My only excuse is that I find it very, very difficult to read since information that is only intended for browser developers is mixed with information that is important to authors (designers, developers, writers, CMS developers, etc.).

Having spent hours reading and re-reading the HTML 5 Working Draft, I now see that, except for it being hard to read for a web author, it really is a good start. I don't necessarily agree with everything. There are some elements and attributes that I don't quite see the point of, as well as some that I find missing. But overall I think the gist of the spec is fine. Basically, the information in it just needs to be presented in a better way.

Here are some suggestions that I think would make the HTML 5 specification easier to read and more useful to authors:

The attitude problem

Specifications and design principles aside, I think a more disturbing issue is the really poor attitude some members of the HTML Working Group have. I'm not going to quote anyone or name any names, but it is something I felt from the moment I joined the working group mailing list.

Sometimes it is just between the lines, sometimes it is clearly expressed in writing. But the dismissive and condescending attitude towards accessibility and semantics advocates is quite tangible, and is what made me frustrated enough to write Help keep accessibility and semantics in HTML before making sure I had all the facts sorted out.

In my opinion this is the main problem with the HTML WG right now.

Looking forward

More than once I've been close to leaving the group out of frustration, but reconsidered. I still don't know if it will be worth my time to stick around. I don't even know yet if I will stick around, or for how long.

I'll definitely stay for a few weeks to see what happens now that the WHAT WG's HTML 5 Working Draft has been accepted as the document that the W3C HTML Working Group will use as a starting point, with Ian Hickson and David Hyatt as editors.

After that, I don't know.

Posted on May 14, 2007 in HTML 5, (X)HTML, Web Standards