The Brave New World of HTML5
[Home of the HTML5 Car]

Yes, design principles for HTML5 do exist. At least as a W3C Working Draft. As this working draft tells, the plan was to publish them as W3C Working Group Note. Well this obviously didn’t happen up to now. Never the less reading the “HTML Design Principles” helps to understand much better why HTML5 is like it is.

At least 3 of the Design Principles take care that old traditions do not disappear. These three are entitled “Do not Reinvent the Wheel”, “Pave the Cow Paths”, and “Evolution Not Revolution”. Funny enough in “Do not Reinvent the Wheel” it says: “…contenteditable="" was already used and implemented by user agents. No need to invent a new feature.” Please read “Surprising developers” about the beauty of the contenteditable="" construct. These Design Principles mean for HTML5, that if there is some ugly practice in place, it should be used (even if it was not part of the standard before)! You may extend it, but don’t tidy it! So things – that mostly for good reasons – didn’t make it into HTML4 or XHTML1 get a second chance. We will address a few of them in other posts.

Another of my favorites says “Solve Real Problems”. The text says “… Abstract architectures that don’t address an existing need are less favored than pragmatic solutions to problems that web content faces today.”. Wasn’t architecture – abstract or not – meant to describe a structure and a set of rules which help to achieve a sound design, security, usability and more? Doesn’t W3C maintain a Technical Architecture Group (TAG) to maintain such rules for the Web? From the charter of the TAG: W3C has created the TAG to document and build consensus around principles of Web architecture and to interpret and clarify these principles when necessary … The “Solve Real Problems” design principle rather sounds like “if it kind of works use it, don’t think too hard!”.

This brings us to the top of the pops: “Priority of Constituencies:”: “In case of conflict, consider users over authors over implementors over specifiers over theoretical purity…”. We could call this hierarchy the Web technology food-chain – if it would exist. This does not describe likely conflicts. Usual conflicts are functionality vs. simplicity, liberty vs. security, or flexibility vs. ease of use … Why are these not addressed?

If you read up to here I have some good news and some bad news. The good news: the Design Criteria never made it to become a Working Group Note. And in practice they have limited relevance. The bad news is about the most relevant Design Principle for HTML5 – and this is not part of the working draft. It could be entitled: “If browser vendors implement it, it goes into the HTML5 specification.” But this has to be addressed in another post.