Re: [whatwg] Constructors for HTML Elements
On Mon, 7 Nov 2011, James Graham wrote: There seems to be some interest in making all concrete interfaces in the DOM constructible [...]. I haven't done this for HTML element interfaces. I think Element.create(), as discussed in public-webapps, is a more scalable approach. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Constructors for HTML Elements
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.
Re: [whatwg] Constructors for HTML Elements
On Mon, 07 Nov 2011 09:00:14 -0500, James Graham jgra...@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. But, what is the ownerDocument? Will it always be window.document I assume? 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.) Side Note: Opera and Safari don't seem to have HTMLSpanElement and a span element stringifies to HTMLElement instead of HTMLSpanElement. Safari seems to be missing HTMLUnkownElement. -- Michael
Re: [whatwg] Constructors for HTML Elements
On Mon, 7 Nov 2011, Michael A. Puls II wrote: On Mon, 07 Nov 2011 09:00:14 -0500, James Graham jgra...@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. 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.. 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.
Re: [whatwg] Constructors for HTML Elements
On Mon, 07 Nov 2011 16:15:17 -0500, James Graham jgra...@opera.com wrote: On Mon, 7 Nov 2011, Michael A. Puls II wrote: On Mon, 07 Nov 2011 09:00:14 -0500, James Graham jgra...@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
