W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Element.create(): a proposal for more convenient element creation

From: Aryeh Gregor <ayg@aryeh.name>
Date: Tue, 2 Aug 2011 14:23:13 -0400
Message-ID: <CAKA+AxnPyY=mO6YpUYos6cu1M0b+f44-MmK-kL2dPi4QyZG71A@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>, Charles Pritchard <chuck@jumis.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Maciej Stachowiak <mjs@apple.com>, Alex Russell <slightlyoff@google.com>, WebApps WG <public-webapps@w3.org>
On Tue, Aug 2, 2011 at 2:05 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> Read again - the idea is to auto-expand arrays.
> (I don't have much of a preference between "just use an array" and
> "use varargs, but expand arrays".  I agree that using only varargs
> without expansion would be bad.)

I'm against "use varargs, but expand arrays" if it would make sense to
have one of the arguments be an array itself, as with Array.concat(),
since then your code is going to mysteriously fail in the varargs case
if you provide one argument that happens to be an array one time.
It's also bad if we might want to add more arguments later.  But in
this case it seems fine.

On Tue, Aug 2, 2011 at 2:12 PM, Charles Pritchard <chuck@jumis.com> wrote:
> http://mootools.net/docs/core/Element/Element
> . . .
> // moo enables: new Element('a.className') as a shorthand.
> . . .
> http://api.jquery.com/attr/
> var myAnchor = $('<a href="http://api.jquery.com">');

These both seem interesting.  Allowing class or id to be specified as
part of the first argument instead of the second one would make some
very common use-cases simpler.  Often you want to create some kind of
wrapper with a static class or id, and Element.create("div.myClass")
is both immediately understandable and significantly shorter than
Element.create("div", {class: "myClass"}).

The second one seems like it might be useful as a separate API.  It
could be a function that accepts a text/html string, and if the
resulting tree has a single root node, it could return that.  If not,
it could return a DocumentFragment containing the result.  Or maybe it
could return a DocumentFragment unconditionally for consistency, so it
would be like a much easier-to-use version of
Range.createContextualFragment.  Of course, this kind of thing is bad
because it doesn't allow easy escaping, so maybe we shouldn't make it
Received on Tuesday, 2 August 2011 18:24:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:23 UTC