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
