jQuery Forum

$("<p/>", {id:"myP", class:"myClass"}).appendTo('body');

-- Kevin

i do see your point, i'm just pointing out that there is another way. I personally would never do it this way because it is more efficient to include the class and id in the html string currently.

i'm not so sure it's more efficient. document.createElement only takes a nodename. that means the attributes must be parsed and set separately on the DOM node. looking through the source, i don't see it using innerHTML on the string to have the browser create the node, which is the only way it can be "more" efficient. on top of that, you cannot do data(), css(), events, etc in any way that wont have all your code in a huge string....unless you like that sort of thing.

also, if those attributes are dynamic you end up with a string-concat mess - probably why that object exposes access to attr() setters in the first place, and also eliminates the parsing overhead.

i saw this tested thoroughly a while back using an older version of jquery, maybe the updates of the new version made them closer together in terms of performance. I haven't been able to recreate results where there was a significant difference in performance.

Although it's not well documented, the .append method takes multiple arguments and has since the beginning (as does .prepend, before, etc.). So a two-argument form where the first argument is a single DOM element (or HTML representing it) and the second is a plain object of properties to modify the first arg would be a special case.

It's a little deep ... domManip calls buildFragment which calls clean, where it processes the args. In any case here is an example:

Yeah, sorry about the lack of documentation. We added the multi-argument signature to prepend, but haven't added it to the other ones yet.

--Karl

i see. sadly, this pattern eliminates any possibility of adding other signatures to these methods which can all use additional, useful invocations i have not even thought of.

this ninja signature seems to have very little actual necessity to have unlimited arguments at the expense of the ability to evolve these useful and powerful methods. considering how easy JS syntax makes it to wrap an array around collections i see no use at all in restricting the language-allotted flexibility of passing variable types and numbers of arguments.

perhaps since it is not documented, it can be changed to accept an array of items to be appended instead of what it does now to replicate the needed behavior?

feeling pretty strongly about freeing up additional signatures, filed a ticket:

http://bugs.jquery.com/ticket/8322