Replying to [comment:44 dmethvin]:
What's wrong with
.filter()? Actually, nevermind, this thread is definitely off topic because we're not talking about a bug or a feature removal at this point. To get help with traversal, filtering, or writing a plugin, ask a question on our forum or StackOverflow.
The purpose of my comments was to pose an argument against deprecating this particular selector until/unless an equally effective & simple-to-use alternative is offered. So far, i'm not convinced the suggestions match those requirements, which are fundamental qualities of jQuery.
.filter() doesn't help unless the INPUT/etc. elements are already in the collection, in which case you're in the same boat as above: using a long selector to get them or wrapping the DOM
form.elements which someone suggested may cause problems in old IE. If you meant
.find(), you still start from the FORM and feed a long selector to get the full list of elements.
So it goes back to: This selector provides an EASY way to get all the inputs of a form, regardless of tag, but it hurts performance. On the other hand, the alternatives are either inconvenient or perform as badly as this selector. Weighed against each other, i say the ease of use wins and the selector should be kept.
i personally feel adding a method to replace this wouldn't be that harmful. It would use
.find(), but would handle the long selector internally. Optionally, if a selector is passed to it, that would filter
.find()'s results. The resulting executions should wash:
Let's assume a requirement to obtain all inputs of a form, no immediate filters (which is what this selector does in the first place).
/* Current (lack-of) alternative */
$("#myForm").find("input, select, textarea, button")
$("#myForm").inputs() /* inputs() handles the above selector */
/* Optional filtering argument */
$("#myForm").find("input, select, textarea, button").filter("[name^=foo]")
$("#myForm").inputs("[name^=foo]") /* inputs() handles the selector & filters */
So to emphasize the point: this feature impacts performance but keeps code simple. If it's removed, the alternatives offered improve performance, but do not retain simplicity.