jQuery Forum

I was reading an article about .live() and .delegate() and noticed that some of the example code seemed rather longwinded:

1.  for(i = 0; i < rows; i++) { $("#container").append("<tr>") } $("tr").each(function() { for(j = 0; j < columns; j++) { $(this).append("<td>"); } }); 

It made me think that by enhancing .append() to take a second argument (the number of copies to append) it would reduce the code to this:

1.  $("#container").append("<tr>", rows);
    $("tr").each(function() {
         $(this).append("<td>", columns);
    }); 

I realise that it would be even better to build a set of TDs once, append it to a TR, then append that multiple times to the container (which is a TABLE of course), but this post isn't about rewriting his code, it's about using it as an example of how making it possible to append elements multiple times without requiring a loop would make such code shorter and cleaner.

So on the face of it, enhancing .append() seems like the way to go.

However, looking at .clone() and its optional parameter [withDataAndEvents] I'm wondering whether the multiple copy ability might be better added to .clone() so that it returns a set of cloned elements, and then using that in conjunction with .append() as it is, to permit something like this:

1.  var $TDs = $("<td>").clone(false, columns);

2.  var $TRs = $("<tr>").append($TDs).clone(false, rows);

3.  $("#container").append($TRs);

So what do you guys think? Or is it already possible to do this somehow that I haven't realised?

I was reading an article about .live() and .delegate() and noticed that some of the example code seemed rather longwinded:

1. for(i = 0; i < rows; i++) {

2.       $("#container").append("<tr>")

3. }

4. $("tr").each(function() {

5.       for(j = 0; j < columns; j++) {

6.             $(this).append("<td>");

7.       }

8. }); 

It made me think that by enhancing .append() to take a second argument (the number of copies to append) it would reduce the code to this:

1. $("#container").append("<tr>", rows);

2. $("tr").each(function() {

3.       $(this).append("<td>", columns);
   

4. }) 

I realise that it would be even better to build a set of TDs once, append it to a TR, then append that multiple times to the container (which is a TABLE of course), but this post isn't about rewriting his code, it's about using it as an example of how making it possible to append elements multiple times without requiring a loop would make such code shorter and cleaner.

So on the face of it, enhancing .append() seems like the way to go.

However, looking at .clone() and its optional parameter [withDataAndEvents] I'm wondering whether the multiple copy ability might be better added to .clone() so that it returns a set of cloned elements, and then using that in conjunction with .append() as it is, to permit something like this:

1.  var $TDs = $("<td>").clone(false, columns);

2.  var $TRs = $("<tr>").append($TDs).clone(false, rows);

3.  $("#container").append($TRs);

So what do you guys think? Or is it already possible to do this somehow that I haven't realised?

jQuery appears to be missing a way to retrieve an array of attribute names for a given element, and to (optionally) retrieve their values at the same time.

riddlemd has created two concise plugins to address this shortcoming - listAttributes and mapAttributes - but I think this functionality should be core, and ideally unified into a single function - perhaps called attrs() - which optionally retrieves a map rather than a list via an optional parameter, set to true for map, false for list... not sure which should be the default though...

Not only does the name .fadeTo() logically suggest that the first parameter should be the opacity value to fade to (it's actually the second parameter, the duration comes first), it's also inconsistent with .animate() which takes the form .animate({properties}, duration) that one would naturally expect.

Ideally I'd like to see the .fadeTo() function/effect (and any others which are similarly counter-intuitive with regard to parameter order) revised so that the parameter order becomes as one would intuitively expect. However I realise that (primarily for reasons of backwards compatibility) this may not be viable... what do others think?

And can we at least agree that any future/new functions named in a similar way - e.g. .rotateTo() - should have their first parameter as the expected main target value(s) followed by any others - e.g. .rotateTo({xDeg,yDeg,zDeg},{xOrigin,yOrigin,zOrigin},duration,etc)

Alternatively, since they are really just lazy shortcuts to a slightly longer call to .animate() can we do away with .fadeTo(), .rotateTo(), etc altogether? Or is it heresy to suggest doing so?

creditcard2 significantly improves upon the default credit card validation functionality in validate but requiring the user to select the correct credit card type in order to validate the card number is (IMHO) adds unnecessary complexity.

I suggest that the credit card type should be detected by the validator and the correct type autoselected in the dropdown, giving the user the opportunity to override. The validator should of course then throw an error if they select a type which conflicts with the number (or when the card type cannot be automagically determined), but otherwise the user has been saved an unnecessary input (and probably impressed that the card was correctly determined), which is surely a user experience improvement.

No doubt I could override the current creditcard2 plugin functionality to achieve this just for me, but I propose that what I have suggested above is preferable in almost all cases and should therefore become the default behaviour for the plugin so that all users can benefit from this ux improvement.

For completeness I should mention that this existing problem includes a link to definitive data on how to detect which card type a given number is, and this other existing idea also suggests that the credit card should be detected and provides some simplistic detection code, but I don't think it's sophisticated enough to do the job properly, and neither of those suggestions replied to, which is why I have written this rather more lengthy new proposal.

Thoughts/responses please...?