This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 7842 - No programmatic way to make an HTML document - consider adding createHTMLDocument
Summary: No programmatic way to make an HTML document - consider adding createHTMLDocu...
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
Keywords: NE
Depends on:
Reported: 2009-10-08 13:32 UTC by Maciej Stachowiak
Modified: 2010-10-04 14:49 UTC (History)
5 users (show)

See Also:


Description Maciej Stachowiak 2009-10-08 13:32:33 UTC
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.
Comment 1 Henri Sivonen 2009-10-08 13:41:37 UTC
Relevant email:
Comment 2 Simon Pieters 2009-10-08 15:30:07 UTC
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).
Comment 3 Ian 'Hixie' Hickson 2009-10-20 09:05:10 UTC
What's the use case?
Comment 4 Maciej Stachowiak 2009-10-20 09:44:40 UTC
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.
Comment 5 contributor 2009-10-20 11:13:56 UTC
Checked in as WHATWG revision r4207.
Check-in comment: Define createHTMLDocument().
Comment 6 Maciej Stachowiak 2009-10-23 22:28:36 UTC
Looks good to me.