[whatwg] relationship between Document and HTMLDocument
dflanagan at mozilla.com
Tue Aug 9 14:17:59 PDT 2011
On 8/9/11 1:58 PM, Ian Hickson wrote:
> On Tue, 9 Aug 2011, David Flanagan wrote:
>>> 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.
>> So you'd declare HTMLDocument with the [NoInterfaceObject] extended
>> attribute and then add attribute HTMLDocument to the Window interface?
> That would have the same effect, but what I had in mind was actually to
> change the HTML spec to not define an HTMLDocument interface, instead
> renaming it to Document and adding the 'partial' WebIDL modifier.
> We'd also have to do this for SVGDocument and other document objects;
> before doing this it would be good to see if it's something that is
> generally agreeable to everyone.
Is the partial keyword a brand-new feature of WebIDL? I didn't see them
discussed on public-script-coord at all... A partial interface sounds
like it would work to me.
>> That changes HTMLDocument from non-enumerable to enumerable, but that
>> seems unlikely to be a compatibility issue. That works for me, I think.
> Could you elaborate on this? I'm not sure what you mean exactly.
The HTMLDocument interface object is current (at least in FF, and per
the WebIDL spec) non-enumerable. It doesn't show up in for/in loops on
the window. If the HTML spec were to add an attribute to the Window
object to define the HTMLDocument property, WebIDL would make that
property enumerable. It would also change from a data property to an
I'm not arguing that these changes would be a problem, just noting
them. The much bigger change, of course, is that HTMLDocument would be
More information about the whatwg