"Embrace HTML5" was held in Shanghai last month. Jeremy Keith, the author of "DOM Scripting" and “HTML5 for Web Designers”, presented a speech on the design principles of HTML5. He also introduced the history of HTML and answered some questions from the audience.
Jeremy reviewed the history of HTML, from HTML 2.0 to XHTML 2.0. He mentioned the Postel's Law (aka. the Robustness Principle):
Be conservative in what you send; be liberal in what you accept.
XHTML 2.0 is not suitable for Web because of its strict syntax parsing. Jeremy thinks each standard should have its own design principles. Similarly for HTML5 - W3C had previously published "HTML Design Principles". Among all these principles, he emphasized compatibility, utility, and interoperability.
1. Avoid Needless Complexity
The DOCTYPE in HTML 4.01 and XHTML is too verbose to remember. But in HTML5, a simple <!DOCTYPE html> is OK. Generally, the DOCTYPE is used by the validator not the browser except for DOCTYPE switching. So, you don't need to write a long DOCTYPE. It is the same with charset . <meta charset="utf-8"> is all you need. A complex specification can also have a simple implementation.
2. Support Existing Content
The biggest problem of XHTML is not supporting existing content, which disobeys Postel's Law. In the real world, developers write HTML code differently. The browser should process and behave consistently.
3. Solve Real Problems
Abstract architectures that don't address an existing need are less favoured than pragmatic solutions to problems that web content faces today. For example, many people have the requirement to embed multiple paragraphs such as <p> and <h2> into a single <a>. Why not put it into the specification.
4. Pave The Cowpaths
When a practice is widely accepted, the specification should consider adopting it instead of creating a new one.
For example, HTML5 added some new tags such as <nav>, <section>, <article> and <aside>, which introduced a new article model. You can start a new <h1> in a <section>, in this way you would have infinite headers instead of six. Tim Berners-Lee wrote in 1991:
I would in fact prefer, instead of <H1>, <H2> etc for headings to have a nestable <SECTION>..</SECTION> element, and a generic <H>..</H> which at any level within the sections would produce the required level of heading.
5. Degrade Gracefully
There are some new type values of <input> in HTML5. If the browser can not recognize them, it would be treated like text by default. This is a kind of graceful degrading.
Another example is the war between HTML5 and Flash. In his opinion, it is really about <video> vs. <object>. You can treat it by degrading to <object> as the fallback content of <video>, and vice versa. If neither of them is supported, degrade to <a> to provide a link.
6. Priority Of Constituencies
In case of conflict, consider the following priority: users > authors > implementors > specifiers > theoretical purity. Users and developers are far more important than specifications and theories.
During the Q&A section, someone from the audience mentioned that people may abuse the flexibility of the syntax of HTML5. Jeremy agreed with him and suggested to use tools like HTML Lint (something similar to JSLint) to write better code.
Someone else was afraid that it would be hard to customize the style of <video> if the default style is too ugly. Jeremy showed some samples of how to customize the style of <video> by CSS stylesheets immediately. If you don’t like the control provided by the browser, you can implement one by yourself.
HTML5 is not far away. You don’t need to wait until 2014 because mainstream browsers have already started to add support for HTML5. What do you think about the future of HTML5?
This post was translated from an original posted by Ding Xuefeng from InfoQ China: : http://www.infoq.com/cn/news/2011/04/html5-design.