- From: David Flanagan <dflanagan@mozilla.com>
- Date: Tue, 09 Aug 2011 13:23:20 -0700
- To: Ian Hickson <ian@hixie.ch>
- CC: Ms2ger <ms2ger@gmail.com>, www-dom@w3.org
On 8/9/11 1:01 PM, Ian Hickson wrote: > On Tue, 9 Aug 2011, David Flanagan wrote: >> But more to the point, the DOM spec also needs to say when those >> additional HTML requirements apply. If I create a "table" element in >> each of these scenarios, in which of them to do I get an >> HTMLTableElement? >> >> 1) html document, createElement >> 2) non-html document, createElement >> 3) html document, createElementNS, HTML namespace >> 4) html document, createElementNS, non-HTML namespace >> 5) non-html document, createElementNS, HTML namespace >> 6) non-html document, createElementNS, non-HTML namespace > The HTML spec, if it applies to your user agent, says it must happen for > 1, 2, 3, and 5. Thanks for the clarification. >> There is a similar situation for DOMImplementation.createDocument() and >> DOMImplementation.createHTMLDocument(). The DOM spec should note that >> the HTML spec imposes additional requirements on the object reaturned by >> createHTMLDocument(). (i.e. that it must implement the HTMLDocument >> interface). > If the HTML spec applies to your UA, all Document objects must implement > HTMLDocument, regardless of how they are constructed. I get that part. I was confused about the interaction between the specs and which spec is allowed to extend the other. I get it now. HTML includes and extends the DOM. If I'm implementing the DOM spec as part of my implementation of the HTML spec, then obviously I give the HTML spec priority. > >> Note that since DOM already defines a flag that creates a distinction >> between HTML documents and XML documents. It will be very confusing if >> createDocument() returns an "XML document" that implements the methods >> of HTMLDocument! > Why would that be confusing? HTMLDocument's APIs apply in XHTML and HTML > equally. In fact the API is (mostly) serialisation-agnostic. There might > not even be a serialisation. > The terminology is confusing because we can have an object that implements HTMLDocument but is not "flagged as an HTML document". All documents are HTML documents but some are more HTML than others and get special uppercasing and lowercasing behavior of their tagnames. Since the primary consumer of the DOM spec is the HTML spec, I think the editors of the DOM spec might want to change the phrase "flagged as an HTML document" since the term "html document" gets overridden by the HTML spec :-) David
Received on Tuesday, 9 August 2011 20:23:49 UTC