getAttribute, setAttribute and removeAttribute and handled by attr() and removeAttr().

submit() and reset() should be added later...

What happens when calling this?

$('#myform').trigger('submit');

Currently, events bound to the submit event are called, nothing else. If the submit method of the form element itself is called, too, what happens to those handlers? They aren't triggered by the programmatic submit, so they can't prevent or handle the actual submit. And calling the handlers first, the method second or otherway round won't solve that problem, the association is simply lost.

And focus(), blur() and submit() (click and select, too?) have all in common that there can be only one element at once, that is, you can submit only one form, and focus or blur only one element. I don't see what we gain by handling those with jQuery methods.

Therefore I propose to close this ticket as invalid.

Maybe handlers should be triggered and the form submitted (or element clicked etc) only when none of the handlers return false. i.e. pseudo code:

$("#foo").submit()

Triggers the following

var fireEvent = true;
foreach(eventhandler in eventhandlers)
{
    if(!eventhandlers[eventhandler]()) fireEvent = false;
}
if(fireEvent ) jQuery(this)[0][event]();

Like joern says though, you can only submit one form, click one link etc, so $("form").submit() and $("a").click() would only run on the first form or anchor found.

Normally I have either 1) a form with an onsubmit handler and a submit button the user presses, or 2) a form with no submit button but some other scheme to invoke a handler when the form changes. In # 1 the submit handler validates the form and returns true/false to decide whether to submit. In # 2 the handler validates the form and only calls form.submit() if the form is ready to submit.

Are there cases where the proposed additions would help? I don't think they're needed for case 1 or 2 above.

I don't think this is a valid feature. In the case of submit for example, the bound events are usually meant to replace or buffer the normal submit event.

If the handler of a click does not return false, I think that now the default handler is triggered, isn't it? So what is John saying? That the default handler should be called anyway? mmm... I hope not.

Actually, if I type $("#foo").submit() I expect the thing to submit. $("#foo")[0].submit() does the same, but from a learning standpoint the need to exit the jQuery object and call the submit() function on the DOM object is confusing. Ease of use should be paramount, and instinctively people think .submit() would submit the form.

.submit() triggers the submit.

.submit(function() {}); overwrites it.

That makes the most sense to me at least.

Such a behaviour would be an absolute showstopper to me and I would consider that as a bug.

Obviously there would be no way of stopping a form to submit if I want to just trigger a validate function or an XHR submit that is typically attached to the submit event handler of a form.

Alex, if we remove .submit() as a method, people will quickly realize their mistake and use [0].submit() instead. I would say the problem is that the jQuery object has a .submit() method that doesn't do the "obvious" thing, and an easy fix is to remove the .submit() method as expected in jQuery 1.1 rather than trying to define the semantics.

Wheather the current submit() method is removed in 1.1 or not is another issue, but the issues described here work just fine as it is.

I improved the documentation for submit(Function) and submit(), reflecting the actual behaviour.