[whatwg] Three concerns regarding HTML5 form validation

Matias matiasnu at gmail.com
Mon Sep 26 07:50:27 PDT 2011

Hi Anne,

The reason is I would love a simple and clear way to trigger form validation (as well as displaying validation errors) programmatically in web apps. As the current implementation stands, the submit button becomes a requirement if you want to utilize native browser form validation.

Of course I don't see the big picture with legacy content etc. like you guys, but an example could be a web app using menu and command elements with different application flows/form targets depending on the command.

The developer could have listened to command events, triggering form validation where necessary.

What the developer has to do instead is;

1) Add a hidden submit button to the form.
2) On command events, trigger a fake click on the hidden submit button to activate native form validation.
3) Capture the submit event and cancel it to prevent the form from posting. 
4) Add code to block form submits when the user presses the return key while typing in an input element.

Clearly a first world problem, but not having to use workarounds like that is something I believe would benefit the community.

But if there is no other way to solve this maybe you should add that a submit button is required for validation to work at all to the spec, just to make things clear?

Best regards,

On 26 sep 2011, at 15:35, Anne van Kesteren wrote:

> On Mon, 26 Sep 2011 13:58:52 +0200, Matias <matiasnu at gmail.com> wrote:
>> 1) Is there a reason why native form validation seems to be tied to the click of the submit button? Submitting the form using JavaScript does not seem to trigger HTML5 form validation in either Firefox, Opera or the Webkit browsers (I haven't checked how IE10 behaves yet). To me this seems like an unnecessary limitation.
> Initially submit() caused validation to be done but that broke deployed content.
> What is the reason for wanting this?

More information about the whatwg mailing list