[whatwg] relationship between Document and HTMLDocument

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 
accessor property.

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 
=== Document.

Received on Tuesday, 9 August 2011 14:17:59 UTC