- From: Ms2ger <ms2ger@gmail.com>
- Date: Tue, 09 Aug 2011 22:20:28 +0200
- 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. HTH Ms2ger >> [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