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 <img> and <applet> and <object> and <embed> and <audio> and <video> all doing roughly the same thing.

"Well, We Have To Support It..."

<object> is the standards-compliant method for embedding an external object (video, sound, interactive element, spreadsheet, etc) into a web page. However, old versions of Netscape used <embed> instead. In practice authors used one or the other, or both. And so, sensibly, browser makers implemented support for both <object> and <embed>.

HTML5, as it stands, standardises <embed>. So there are now two, functionally identical, but syntactically different methods for embedding external objects into an HTML document. This is confusing for authors who have to wonder when they should use one, or the other, or both! In practice, the majority of authors will use both out of a belief that they have to (or should) -- if they didn't have to, then why would both elements be included in the spec? -- so the staus quo remains unchanged, and authors end up using twice as much markup as they need to.

What would happen if HTML5 did not include the <embed> element? Would the sky come tumbling down? People writing to the HTML5 spec would use <object> alone and save themselves some coding. Those authors who knew about <embed>, and used it instead of or as well as<object> would find that their pages still worked, but didn't validate. In other words: browsers would behave the same, <embed> and <object> would both work the same, but the specification would be simpler and authors would find it less confusing.

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 <blink> element has been implemented fairly consistantly in all major browsers for a number of years.

***

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 <embed> and <blink> and <marquee>. It should support frames and all the other things which browser makers need to support no matter how much we wish they didn't.

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.