- From: John J Barton <johnjbarton@johnjbarton.com>
- Date: Fri, 28 Oct 2011 11:14:33 -0700
- 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 UTC