HTML5's Design Principles, Part I
The one thing I believe as a developer is if you want to have an intimate understanding of a language, tool, paradigm, or concept; you should learn why and/or how it was created. A couple of years ago, about…2011, I wrote a paper on the design of HTML5 and oddly, I’ve been finding myself talking about this topic years later. It seems to me that a lot of people don’t know the story and thinking behind the technologies (tools, etc…) they use on a daily basis… and many could argue that the how/why is irrelevant. But I enjoy the story of how HTML5 was brought about and I think people can learn a lot from it. Also, it’s actually pretty interesting story.
In 2004, the W3C was in the process of creating XHTML2. XHTML2 was going to take the web in completely new direction as it was going to create a more XML based web. In June of that year, the W3C held a workshop on web applications where members of the W3C, software developers, web developers and representatives can come and propose their position papers on various issues and questions revolving around web applications. In this workshop, Ian Hickson from Opera Software along with representatives from the Mozilla Foundation gave a presentation on their position on the future of the web. They believed that they should focus existing web technologies such as HTML, CSS and DOM and add features to it to make it more powerful for web applications. Their ideas were not favorable amongst the W3C and they were voted against. This caused a break, Ian Hickson as well as representatives from the Mozilla Foundation and Apple split away from the W3C and formed the Web Hypertext Application Technology Working Group (WHATWG) and started focusing on making HTML a more power language with specifications such as Web Forms 2.0 and Web Apps 1.0. This specification to make HTML more powerful was the initial groundwork of HTML5 and it picked up a lot of traction. So much that the W3C abandoned the XHTML2 project to work on their own version of HTML5. Eventfully (and thankfully), in 2006, the W3C established an HTML Working Group to work along with the WHATWG and build upon the work they already had started with Web Apps 1.0 to create a future version of HTML. The Web Apps 1.0 specification eventually became the HTML5 specification.
Due to the fact the HTML5 specification was being developed by two different working groups that operated differently, the design principles became the middle ground when deciding what should be added to the HTML5 specification. Most, if not all of the decisions made about the HTML5 specifications can be rooted to these principles. These design principles are; Compatibility, Utility, and Interoperability. Under these main principles are various sub principles.
The design principle compatibility ensures that HTML is not only backwards compatible but also to ensure that it’s forward compatible as well. One of the biggest reasons of why XHTML2 didn’t get off the ground was due to the fact that it wasn’t going to be backwards compatible. With HTML5; user agents must support previous versions of HTML. It’s obvious that not all the HTML5 features will be able to be supported by user agents and for this; the design principle of “degrading gracefully” would be applied. Put simply, features should have fallbacks in the case that it’s not supported. An example of this would be the form input attributes. In HTML5, form field can be catered to the type of information that is being put into them such as email, telephone numbers, numbers, dates, etc… The problem that authors are faced with is when it comes to these input type attributes they are not supported by all browsers and instead of not rendering the form fields at all, they degraded them to a text field that would be commonly used today, in this case it’ll be a text field. Besides degrading gracefully, the design principles state that they should not reinvent the wheel. This principle states:
If there is a widely used and implemented technology covering particular use cases, consider specifying that technology in preference to inventing something new for the same purpose.
Paving the cow paths was another design principle that was kept in mind when developing the HTML5 specification. The thought behind this was if a practice is already being widely used, then there is no need to ignore it, it should be considered for implementation. In 2005, Ian Hickson did a study to assess the current trends of the web and how the HTML language is being used on the web. One of the tests he ran was assessing the most common classes on web pages. With paving the cowpaths in mind he used this as a base to create many of the new structural elements in HTML5. In this study, Hickson list the top 20 classes being used and after distinguishing the presentational styles from the ones that have significant meaning he was able to make these elements apart of the HTML5specification. The structural elements that ended up being in the specification are; header, footer, navigation, and article.
The last design principle that falls under compatibility is “Evolution not Revolution.” This means that new features or changes should occur in existing code rather than throwing them out of the specification. This is seen in the HTML5 specification as some of the presentational elements that have been used for many years by author have now been given new meanings. For example, the small was used to create small text now has a new meaning of small print and is ideally used of legal copy or side comments. Another example would be the cite element which traditionally meant to markup the name of a person is now this element is used to markup the name of a title of work such as a book, paper or poem. Many more presentational elements have new meanings as they have evolved from there presentational heritage and have been give more semantic meaning.
This post has been split into two post. I’ll be posting the rest of this next week. Cheers.