[whatwg] Constructors for HTML Elements

[Michael A. Puls II]

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>  
>> wrote:
>>
>>> 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  
>>> needed.
>>
>> 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  
>> assume?
>
> 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.".

O.K.

>> 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  
>> etc.)
>
> FWIW the two cited reasons for wanting it to work are "it makes the DOM  
> feel more like other javascript" and "it helps us use element  
> subclassing as part of the component model".

O.K.

-- 
Michael