[whatwg] relationship between Document and HTMLDocument

Tue Aug 9 12:53:51 PDT 2011

On Tue, 9 Aug 2011, David Flanagan wrote:
>
> §3.1.1 includes the following:
> 
> interface HTMLDocument { ... };
> Document implements HTMLDocument;
> 
> If I'm reading WebIDL correctly, this means that this expression must be
> false:
> 
>    document instanceof HTMLDocument
> 
> And also that this code will have no visible effect on the document object:
> 
>     HTMLDocument.prototype.foo = function() { ... }
> 
> Furthermore, if I want to monkeypatch a method like getElementsByName() that
> is defined by HTML, the correct place to do that is on Document.prototype, not
> HTMLDocument.prototype
> 
> Currently, of course (tested in FF, Chrome and Safari), browsers treat
> HTMLDocument as if it were declared like this:
> 
>     interface HTMLDocument : Document { ... };
> 
> This means that in the current generation of browsers:
> 
>    document instanceof HTMLDocument    // => true
>    HTMLDocument.prototype.foo = function() {...}  // affects document
>    Document.prototype.getElementsByName // undefined; can't monkeypatch it
> 
> I would guess (but have no data) that web compatibility will make these
> behaviors difficult to change.

Possibly. I think an alternative is to make the HTML spec just add all the 
members to Document, and then define window.HTMLDocument as returning the 
Document interface object. This would make instanceof and "monkeypatching" 
work as today.

> I assume that the use of an implements declaration rather than direct 
> inheritance is done to create a clean boundary between the DOM spec and 
> the HTML spec.

No, it was done because inheritance here makes no sense. A Document is a 
Document, you can take it and replace its root <html> element with a root 
<svg> element, or mix <html> and <svg>, or any number of other similar 
things, and it seems to me that it should all work. Why have different 
Document objects? What if an <html> file has some <svg> in it, should it 
not be able to get to the SVG API? etc.

> But it seems to me that this clean boundary does not reflect messy 
> reality.

Indeed, this is an example of a new feature that browsers haven't 
implemented yet.

> Ian: any chance you'd change HTML to specify that HTMLDocument is a 
> regular subclass of Document?

Not unless we find no other way to fix the bugs in the current API in a 
backwards-compatible way. :-)

On Tue, 9 Aug 2011, Boris Zbarsky wrote:
> 
> In particular, the current spec text (which indeed does not match either 
> older DOM specs or current implementations) requires all Document 
> objects to implement the HTMLDocument interface.  I don't believe that's 
> the case in current UAs, fwiw...

Correct. This is an instance of the spec attempting to show the way 
forward.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'