This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Problem: With the combination of HTML5, and DOM APIs, there is a programmatic way to make a brand new empty XML document (DOMImplementation.createDocument), but no way to make an HTML document other than by action of the parser. This seems like an unfortunate gap. Possible solution: It turns out that an old draft of DOM2 HTML included an HTMLDOMImplementation interface with a createHTMLDocument() method - intended to be implemented on the DOMImplementation object. WebKit and Presto implement it. Without this method, there is no programmatic way to make an HTML document; you have to use the parser. Since HTML5 takes over where DOM2HTML left off, I think it would be a good idea to add this method back.
Relevant email: http://lists.w3.org/Archives/Public/www-dom/2009OctDec/0022.html
Both Opera and WebKit create a document with the HTMLness bit set, implements the HTMLDocument interface, and uses standards mode. WebKit uses a doctype (with name 'html' and publicId and systemId returning the empty string), Opera doesn't. The document has the html, head, title and body elements. In Opera, the title always has a text node child. In WebKit, it only has a text node child if the argument wasn't the empty string. If the argument is omitted, Opera throws a WRONG_ARGUMENTS_ERR internal exception and WebKit sets the title to 'undefined' (i.e. it's not 'optional' in the IDL).
What's the use case?
Same as the use case for creating a document programatically in general, in cases where it's useful to have some processing where the HTMLness bit matters. Some potential (maybe contrived) examples: - Create a non-rendered HTML document to upload via XMLHttpRequest (instead of sending an XML document). - Feature-test the HTML DOM in library code in a way that is guaranteed to avoid side effects on the displayed document. - Create an isolated non-rendered document from a rich text editing area, so client-side cleanup can be done before uploading without disturbing the live DOM that the user may still edit further. - Implement HTML5 parsing algorithm client-side in JavaScript for testing and comparison purposes, or for virtualization or object-capability-based security. An invisible iframe can be used for most of these purposes but that is more expensive in terms of resources. I think these use cases are not necessarily the most compelling. Mainly it seems non-orthogonal that HTML documents can only be created by the HTML parser, and thus offscreen / non-rendered documents all have to be XML documents. This seems like an unnecessary asymmetry. Reopening for consideration of provided info.
Checked in as WHATWG revision r4207. Check-in comment: Define createHTMLDocument(). http://html5.org/tools/web-apps-tracker?from=4206&to=4207
Looks good to me.