W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2011

[whatwg] relationship between Document and HTMLDocument

From: timeless <timeless@gmail.com>
Date: Thu, 11 Aug 2011 17:32:37 -0400
Message-ID: <CAACrNNej5Jyec3E2CW4dOOO0JEZ_ahf52r=aX6y6b46Ze696uQ@mail.gmail.com>
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
Received on Thursday, 11 August 2011 14:32:37 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:35 UTC