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

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
easier.

Received on Tuesday, 2 August 2011 18:24:02 UTC