[whatwg] Three concerns regarding HTML5 form validation

Hi Mounir and sorry for the late reply,

>> 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.
> 
> .submit() by-passes all possible submit cancellation per spec: there is 
> no submit event sent and given that the validation checks were done in 
> the submit event handler, it seems reasonable to disable the automatic 
> HTML5 form validation.

OK, I understand... so is there a reason not to have a method for triggering the display of validation errors in addition to triggering a click on a submitControl? (I can understand not wanting duplication of functionality, but it would be great for clarity) 

>> 2) How about adding a method to programmatically display the native validation error messages instead of waiting for the form submit click? We already have a way to (more or less) detect if the form is valid or not, but no way of forcing the native validation error messages to render without using some submit button click hack.
> 
> I guess submitControl.click() should work and isn't that hacky.

Yes and no. :) If I want to validate a form (for example if it's sectioned into tabs and the user switches tab after typing an invalid value somewhere) I have to trigger a click event on a button instead of actually calling a validation method on the form which (maybe only for me) seems to be a bit of a hack. But if that's what it takes to stay compatible with the legacy web as we move forward, so be it.

>> 3) Should there be a way of detecting if the browser actually understood all input element types? Browsers believe that a form is valid even when it contains invalid data for input types the browser doesn't understand. (Like the string 'asdf' in an input type=number field in Firefox.)
>> 
>> So checking if the browser has a checkValidity method is not a guarantee that the form validates according to the HTML5 specified constraints. If there was a method or property like form.containsUnknownInputs and maybe element.isUnknownInput (not the best names, but you get the idea) we could determine the best way to handle further validation.
> So, theoretically, you should be able to do:
>   input.type = "foo";
>   if (input.type == "foo") {
>   }
> 
> But last I checked Webkit brokes that by recognizing types it does not 
> [fully] understood. Though, maybe the validation is done as expected.

Thanks, it seems Modernizr/Webshims Lib takes care of that issue in Firefox.

> However, I don't think it would be a good idea to have a website using 
> only HTML5 Form Validation for a wide audience. It is better to have a 
> path for browsers who do not understand HTML5 Forms Validation. 
> Basically, that means keeping the checks in the submit event handler. 
> These checks will be done for non-supported types too.

Fortunately my audience is from the enterprise sector and the web app I'm building is not free, so I can have pretty strict browser requirements.

Best regards,
Matias

Received on Wednesday, 28 September 2011 06:56:23 UTC