W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: A proposal for Element constructors

From: John J Barton <johnjbarton@johnjbarton.com>
Date: Fri, 28 Oct 2011 11:14:33 -0700
Message-ID: <CAFAtnWx9qzSJO5iM97hZNLfxEC1h2YJCKBZD=WjMO6ZZ+0A17g@mail.gmail.com>
To: Kentaro Hara <haraken@chromium.org>
Cc: John-David Dalton <john.david.dalton@gmail.com>, public-webapps@w3.org, Rick Waldron <waldron.rick@gmail.com>, Dominic Cooney <dominicc@chromium.org>
On Thu, Oct 27, 2011 at 12:35 AM, Kentaro Hara <haraken@chromium.org> wrote:
>
> ...
> John-David wrote:
> > Something like Element('<div>') is so so soo nice compared with more
> > verbose alternatives and you can still add attributes to elements via
> > a second argument. I know some prefer smth like Element('div#foo') ->
> > <div id="foo"></div> but that get's ugly when trying to expand that
> > syntax to an element's children.
>
> In terms of syntax sugar, I agree that Element constructors may lose
> Element.create("button", ...), new Element("button", ...) or some
> possible extension of .createElement("button", ...). However, Element
> constructors are desirable to the consistency:
>
> > (b) Consistency with other constructable DOM objects
> > new XMLHttpRequest(), new Image(), new Event(), new CustomEvent(), new
> > MessageEvent(), ...
>
> and are required for the sub-typing:
>
> > (c) Enables to subtype DOM objects in the future
> > We are planning to make DOM objects subtype-able, like this:
> >
> >     function MyButton(text) {
> >         HTMLButtonElement.call(this);    /* (#) */
> >         this.textContent = text;
> >     }
> >     MyButton.prototype = Object.create(HTMLButtonElement.prototype, {...});
> >     var fancyButton = new MyButton("Click Me!!");
> >
> > In order to make the line (#) work, HTMLButtonElement must have a
> > constructor.

Sadly, your consistency argument has a flaw. If you try
   XMLHttpRequest.call(...);
you get
  TypeError: Object function XMLHttpRequest() { [native code] } has no
method 'call'
Similarly for Image and perhaps others.

This is just a trivial way of saying that the model you are promoting
as the use-model isn't current practice. I like it, I think it should
be used, but consistency with the past isn't a strong argument to
support it. Furthermore, if we want this kind of consistency we have
to change the current spec to support it.

A plus and minus you probably already discussed: A standard based on
eg HTMLButtonElement() with HTMLButtonElement.prototype would allow
library implementation of Element('button',...), but the other way
around seems hard.  On the other hand, a specification for
Element('button', otherArgs) that must call eg
HTMLButtonElement(otherArgs) would be straight-forward except for
error conditions.

jjb
Received on Friday, 28 October 2011 18:15:01 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT