2007/4/4, Martin Atkins:
* For "cancel" buttons where the server-side app just throws the submitted form data away, it's pointless to validate it client-side.
Attach the "cancel" button to a distinct 'form' (eventually having the same 'action' and 'method').
* Allowing the user to submit an unfinished form to the server to be saved for later completion. * A "preview" button that allows the user to see the results of what has been completed so far without completing the entire form. * Buttons that trigger round-trips to the server to alter the form in some way.
Those are really good use cases (imo). All three might a priori be achieved using a second 'form' with some javascript to turn every non-validating control to a valid state, and attaching every control to both forms, but that's really tricky, compared to a 'causesvalidation' attribute (I chose 'causesvalidation' because that's the name of the property used in ASP.NET to achieve the same behavior). I'd personally allow such an attribute on both submit buttons and forms (because controls can be attached to multiple forms, it makes sense that validation is triggered depending on the submitting form, not only on which button has been clicked, which might not always be the case: form submitted by javascript). My 2 c€nts -- Thomas Broyer