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

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

From: Ms2ger <ms2ger@gmail.com>
Date: Tue, 09 Aug 2011 22:20:28 +0200
Message-ID: <4E41968C.6050106@gmail.com>
To: David Flanagan <dflanagan@mozilla.com>
CC: www-dom@w3.org
On 08/09/2011 08:52 PM, David Flanagan wrote:
> On 8/9/11 9:20 AM, Ms2ger wrote:
>> Hi David,
>> On 08/09/2011 05:56 PM, David Flanagan wrote:
>>> I can't see anything in the DOMCore spec that references the fact that
>>> HTML defines lots of Element subclasses and that createElement('table'),
>>> for example, is supposed to return an instance of HTMLTableElement.
>>> Also, it is unclear to me what should happen if d is a document returned
>>> by createDocument (not createHTMLDocument) and I call
>>> d.createElement("table"). The spec is clear that the element will use
>>> the HTML namespace, but it is not clear whether the resulting object is
>>> instanceof HTMLTableElement or just Element.
>>> createElementNS() is similarly underspecified: under what circumstances
>>> does it create instances of the HTML-specific interfaces defined in the
>>> HTML spec?
>> Indeed, this is left up to the HTML specification. It defines [1] that
>> elements must implement the interface listed in the definition box,
>> which is HTMLTableElement for table elements [2].
> Thanks; I had not found that paragraph of the HTML spec. I'd say that it
> would be worth adding a note to the DOM spec mentioning that HTML
> imposes these additional requirements...

This is covered somewhat by [3]

> When vendor-neutral extensions to this specification are needed,
> either this specification can be updated accordingly, or an extension
> specification can be written that overrides the requirements in this
> specification. When someone applying this specification to their
> activities decides that they will recognise the requirements of such
> an extension specification, it becomes an applicable specification
> for the purposes of conformance requirements in this specification.

I'm not sure if it's particularly useful to add another note; after all, 
this is only a specific instance of the general pattern where another 
spec builds upon DOM Core.

> 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
> It seems clear to me that 1 & 3 should result in an HTMLTableElement,
> but I honestly don't know about the other cases. And I think that the
> DOM spec needs to define this.

All such elements in the HTML namespace. I'd say I can back that up with 
what I mentioned above [1-2] and [4] (rather well hidden, I'll admit):

> Except where otherwise stated, all elements defined or mentioned in
> this specification are in the http://www.w3.org/1999/xhtml namespace,
> and all attributes defined or mentioned in this specification have no
> namespace.

What kind of Document you're working in is rather orthogonal to this issue.

> 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). And I think that the DOM spec also needs to normatively
> state whether the object returned by createDocument() implements
> HTMLDocument or not. The HTML spec says that it does, but since HTML
> depends on DOM and not the other way around, it seems to me that the DOM
> spec needs to say something about this.

I disagree here. The HTML specification defines the HTMLDocument 
interface, and defines that all Documents should implement it. Note that 
HTML doesn't impose additional requirements on createHTMLDocument (or 
createDocument); it imposes additional requirements on Document objects, 
regardless of their origin.

> 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!

These are orthogonal as well. Even in current browsers, "XML documents" 
(at least sometimes) implement HTMLDocument, in particular for documents 
sent as application/xhtml+xml.


>> [1] http://www.whatwg.org/html/#element-definitions
>> [2] http://www.whatwg.org/html/#the-table-element

[3] http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#extensibility
[4] http://www.whatwg.org/html/#xml
Received on Tuesday, 9 August 2011 20:21:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:18 UTC