This is a very old article. It has been imported from older blogging software, and the formatting, images, etc may have been lost. Some links may be broken. Some of the information may no longer be correct. Opinions expressed in this article may no longer be held.
Part of the problem with the WHATWG HTML 5 specification is that it’s primarily written by browser makers. (Hixie, its editor, is the exception, as he currently works for Google, though in the past was employed by the Mozilla Foundation and Opera.)
This has steered the focus of the specification towards browser manufacturers — the specification includes such things as algorithms for parsing markup. To expect a typical document author to care about such details, let alone understand them is a triumph of optimism over sanity.
Understanding Motivations
The aim of most browser makers is to increase their market share — to attract users, the browser must enable them to view any documents they could in their old browser, plus tempt the user with an array of new features and improvements. Naturally this leads to a situation where browsers are somewhat liberal in interpreting documents.
Whatsmore, it tends to mean that tolerences of malformed HTML in one browser proliferate.
Paving the Cow Paths
HTML5 embodies a principle called “paving the cow paths”.
The idea behind this analogy is that at some time ago, a lonely cow wandered haphazardly through a field. A day or so later, a man walking through the same field decided to follow the trodden down path instead of venturing into the long grass. Over time, many people following the same path wore it down into a dirt path where no grass would grow. This was eventually paved.
Nobody seems to have mentioned to WHATWG that this isn’t a good thing. You end up with a haphazard road rather than a straight, efficient route. You end up with and
“Well, We Have To Support It…”
HTML5, as it stands, standardises
What would happen if HTML5 did not include the
The people behind the HTML5 spec, as they’ve approached the problem (naturally) from a browser maker’s point of view, seem to have come to the conclusion that any elements that they’d like to support need to be in the specification. However, history has shown us that this is not the case. Despite it never being part of any HTML spec, the annoying
***
The Tao
Here is the way forward: two specifications.
One specification should be written for authors. It should be based on HTML 4.01 Strict and XHTML 1.0 Strict, but introduce a number of new, useful elements and attributes to the language — “clean” ones — well-designed extensions to the language — not the haphazard results of meandering bovines.
The other specification should be written for browser makers. It should be based on HTML 4.01 Transitional and XHTML 1.0 Transitional. It should be a proper superset of the specification for authors. It should include
Authors deal with a small standard, telling them best practice for authoring modern documents; browser makers have a comprehensive document that specifies how their software should parse and display the full set of current, historical and proprietary elements.
