input directive does not update html5 native validation.

[refactorthis]

Just an idea, not an issue. Perhaps the $setValidity method in the input directive could call the HTML5 constraint validation api?

Some validation attributes are the same as the standard html5 attributes and will cause native browser validation, however others will not. Perhaps we could force the input directive to be more html5 compatible by integrating better with the element.validity.* properties?

[caitp]

One of my patches tries to do this sort of (at least for type=number), although it doesn't make any calls to checkValidity() or anything... There are some issues with it, but if you'd care to take a look, it would be appreciated. #4293

[IgorMinar]

this should be simple to implement for everything using ngModel directive. We should just update the validity state somewhere in $setValidity method of NgModelController.

the only tricky thing that will require some experimentation is to make sure that by setting that property we don't trigger some native form behavior that would interfere with existing user interface (native browser validation popovers etc).

[refactorthis]

Yeah that's what I was thinking. From there you easily have access to the element and the validationErrorKey. I believe the submit event must be called for validation to take place so setting the property won't trigger any changes to the UI until the submit event has been raised.

I don't see many side effects as some attributes (min, max) would be causing this already unless the form has the novalidate attribute on it. This change would make the experience more consistent so that all validation will cause HTML5 validation unless novalidate is specified. I guess we would need to experiment with multiple validation functions on one element, as AFAIK the HTML5 spec only allows for one error message at a time.

Would also allow for styling of inputs in a more standardized manner via the :invalid and :valid psuedo classes.

[caitp]

ValidityState doesn't expose any writable properties, the best you can really do is politely ask the browser to do it, and it might decide not to. To be honest, the logic in blink/webkit for this is a bit tricky to follow, and it isn't spelled out super clearly in the draft --- So there may be some issues in doing this consistently across browsers. There are instances where the form control's novalidate is entirely ignored, or where willValidate has an unexpected value for the surrounding markup, etcetera. It's sort of bizarre.