[whatwg] Constructors for HTML Elements
Michael A. Puls II
shadow2531 at gmail.com
Mon Nov 7 13:17:03 PST 2011
On Mon, 07 Nov 2011 16:15:17 -0500, James Graham <jgraham at opera.com> wrote:
> On Mon, 7 Nov 2011, Michael A. Puls II wrote:
>> On Mon, 07 Nov 2011 09:00:14 -0500, James Graham <jgraham at opera.com>
>>> There seems to be some interest in making all concrete interfaces in
>>> the DOM constructible (there also seems to be some interest in making
>>> abstract interfaces constructible, but that seems insane to me and I
>>> will speak no further of it).
>>> This presents some special difficulties for HTML Elements as there is
>>> not generally one interface per tag (e.g. HTMLHeadingElement is used
>>> for h1-h6) and making all zero-argument constructors work seems like a
>>> more natural API than sometimes having to say 'new HTMLDivElement()'
>>> and sometimes having to say 'new HTMLHeadingElement("h1")'. So the
>>> question is whether we can change this without breaking compat. The
>>> only problem I foresee is that adding new interfaces would change
>>> stringification. But I think it is possible to override that where
>> You'd have to do HTMLUnkownElement("name") anyway, so new
>> HTMLHeadingElement("name") wouldn't be bad.
> I think it is quite acceptable to break HTMLUnknownElement.
O.K. No strong feeling either way.
>> But, what is the ownerDocument? Will it always be window.document I
> It would work like new Image; i.e. "The element's document must be the
> active document of the browsing context of the Window object on which
> the interface object of the invoked constructor is found.".
>> Anyway, I think it'd be great to have this. It wouldn't really solve a
>> problem except for making code a tiny bit shorter. But, it's kind of
>> something that seems like it should work (as in, makes sense, intuitive
> FWIW the two cited reasons for wanting it to work are "it makes the DOM
> subclassing as part of the component model".
More information about the whatwg