7842 2009-10-08 13:32:33 +0000 No programmatic way to make an HTML document - consider adding createHTMLDocument 2010-10-04 14:49:27 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified PC All CLOSED FIXED NE P2 normal --- 1 mjs ian hsivonen ian mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 28129 0 mjs 2009-10-08 13:32:33 +0000 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. 28130 1 hsivonen 2009-10-08 13:41:37 +0000 Relevant email: http://lists.w3.org/Archives/Public/www-dom/2009OctDec/0022.html 28135 2 zcorpan 2009-10-08 15:30:07 +0000 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). 28552 3 ian 2009-10-20 09:05:10 +0000 What's the use case? 28557 4 mjs 2009-10-20 09:44:40 +0000 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. 28571 5 contributor 2009-10-20 11:13:56 +0000 Checked in as WHATWG revision r4207. Check-in comment: Define createHTMLDocument(). http://html5.org/tools/web-apps-tracker?from=4206&to=4207 28907 6 mjs 2009-10-23 22:28:36 +0000 Looks good to me.