Re: [webcomponents]: Of weird script elements and Benadryl

On Tue, Apr 16, 2013 at 9:51 PM, Bjoern Hoehrmann <derhoermi@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:bjoern@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/
>