W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2011

Re: [DOMCore] createElement() and HTML-specific element interfaces

From: David Flanagan <dflanagan@mozilla.com>
Date: Tue, 09 Aug 2011 13:23:20 -0700
Message-ID: <4E419738.80102@mozilla.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:08 GMT