[whatwg] relationship between Document and HTMLDocument

[timeless]

Partial interface [1] was added for the 12 July 2011 – LCWD. It was
designed to replace "Supplemental" [2]. I think the beginning of it
was in a thread on public-script-coord [3].

[1] http://www.w3.org/TR/WebIDL/#dfn-partial-interface
[2] http://www.w3.org/TR/2010/WD-WebIDL-20101021/#es-extended-attributes
[3] http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0084.html

On 8/9/11, David Flanagan <dflanagan at mozilla.com> wrote:
> 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.
>

-- 
Sent from my mobile device