On Tue, Aug 2, 2011 at 2:05 PM, Tab Atkins Jr. <jackalm...@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 <ch...@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.
