On Tue, Apr 16, 2013 at 9:51 PM, Bjoern Hoehrmann <derhoe...@gmx.net> wrote:
> * Rick Waldron wrote:
> >Of course, but we'd also eat scraps from the trash if that was the only
> >edible food left on earth. document.createElement() is and has always been
> >"the wrong way"—the numbers shown in those graphs are grossly skewed by a
> >complete lack of any real alternative.
> >
> >If I want to make a new button to put in the document, the first thing my
> >JS programming experience tells me:
> >
> > new Button();
>
> And if you read code like `new A();` your programming experience would
> probably tell you that you are looking at machine-generated code.
I'm not sure what your own experience is, but I completely disagree.
> And if
> you read `new Time();` you would have no idea whether this creates some
> `new Date();`-like object, or throw an exception because the browser you
> try to run that code on does not support the `<time />` element "yet" or
>
I would expect a <time> element to be constructed with:
new HTMLTimeElement();
... since that's the name of the constructor/prototype that's defined for
the <time> element.
> "anymore" (the element was proposed, withdrawn, and then proposed again)
> and if it's something like
>
> var font = new Font("Arial 12pt");
> canvas.drawText("Hello World!", font);
>
> The idea that you are constructing `<font />` elements probably wouldn't
> cross your mind much.
Because I would constructor a <font> element with:
new HTMLFontElement()
... since that's the name of the constructor/prototype that's defined for
the <font> element.
> And between
>
> new HTMLButtonElement();
>
> and
>
> new Element('button');
>
> I don't see why anyone would want the former in an environment where you
> cannot rely on `HTMLHGroupElement` existing (the `hgroup` element had
> been proposed, and is currently withdrawn, or not, depending on where
> you get your news from).
The latter is indeed a much nicer to look at then the former, but Element
is higher then HTMLButtonElement, so how would Element know that an
argument with the value "button" indicated that a HTMLButtonElement should
be allocated and initialized? Some kind of nodeName => constructor map, I
suppose...? (thinking out loud)
> Furthermore, there actually are a number of
> dependencies to take into account, like in
>
> var agent = new XMLHttpRequest();
> ...
> agent.open('GET', 'example');
>
> Should that fail because the code does not say where to get `example`
> from, or should it succeed by picking up some base reference magically
> from the environment (and which one, is `example` relative to from the
> script code, or the document the code has been transcluded into, and
> when is that decision made as code moves across global objects, and so
> on)?
I'm not sure how this is a dependency or even relevant to the discussion.
> Same question for `new Element('a')`, if the object exposes some
> method to obtain the "absolute" value of the `href` attribute in some
> way.
>
> >But I live in the "bad old days" (assuming my children won't have to use
> >garbage APIs to program the web) and my reality is still here:
> >
> > document.createElement("button");
>
> That very clearly binds the return value to `document` so you actually
> can do
>
> var button = document.createElement("button");
> ...
> button.ownerDocument.example(...);
>
As a static factory, sure, but implied ownerDocument context binding isn't
a strong argument for neutering the specific element constructors. Really,
I should be able to do both... If I create a new element, I should have the
ability to bind that element to whatever document that makes the most sense
for my application's needs (an iframe's document? an xml document?).
Inserting a new-born-detached element into a specific document or
explicitly binding that element to a document via some imperative mechanism
makes just as much sense as your example.
>
> in contrast to, if you will,
>
> var button = new Button();
> button.ownerDocument.example(...);
>
I would expect this:
var button = new HTMLButtonElement();
button.ownerDocument === null; // true
document.body.appendChild(button);
button.ownerDocument === document; // true
Or
// pass a context arg?
var button = new HTMLButtonElement(document);
button.ownerDocument === document; // true
OR
var button = new HTMLButtonElement();
// explicitly set the context?
button.ownerDocument = document;
>
> where `button.ownerDocument` could only have a Document value if there
> is some dependency on "global state" that your own code did not create.
>
I agree that's bad
> I would expect that code to fail because the ownerDocument has not been
> specified,
I should hope so as well
> and even if I would expect that particular code to succeed,
> I would be unable to tell what would happen if `example` was invoked in
> some other way, especially when `example` comes from another global.
>
document !== [[Global]], so I'm not sure what other global this `example`
method could be defined on that this would ever possibly be true. Let's
just agree that this will fail for all the right reasons.
Rick
> --
> Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>
