Extracted from #1542
@tvdeyen suggested
As a bonus, as we're already here we could also add required: true to trigger browser based validation.
@mtomov replies
There's actually that beast here - jQuery.validate that takes care of javascript validations. Not sure if it will play well with the html validations as it's a rather old version.
As the address form is the only one to use this plugin, as far as I know, (payment form uses a different plugin), if you consider it appropriate, I can remove jQuery validate altogether and replace the presence validations with html5 ones. Whoever wants then can add a validation plugin of their own (such as the Foundation's one Abide, or I'm sure bootstrap must also have one)
I think even for experienced developers - having a reference to what exactly the correct auto-complete attributes are, without having to search for, is great to have.
@tvdeyen responds
:+1: for removing jQuery.validate and replace it with HTML5 based validations. But this is just my 2 cents.
@cbrunsdon adds
I'm pro swapping to html5 validations as well, though I know very little about them.
My team has learned the hard way that HTML5 form validations are not supported by Mobile Safari. If you wish to support that browser, you may not want to make that change.
@bbuchalter we still have the model validations. Front-end validations are just, and should always, be an UX addition for users. Also, the form we provide is only an example and most likely will never be used on production as is. Stores that care about front end validations on mobile Safari can easily drop in some JS lib.
We can not provide front end templates that will fit all use cases. They are very easily replaceable by stores and are just an example/demo of a minimal working store and not a one-size-fit-em-all solution.
For reference
http://caniuse.com/#feat=form-validation
https://bugs.webkit.org/show_bug.cgi?id=28649
As this is the default frontend, which is widely replaced anyway, I'd be pro putting in html5 validations with a warning in the changelog that someone might want to polyfill in something for iOS.
It wouldn't stop individual stores from using whatever they wanted, and we'd be reducing our reliance on an external lib in a forward-looking way.
The iOS problem is finally about to go away.
https://webkit.org/blog/7093/release-notes-for-safari-technology-preview-19/
Completed by #2264
Most helpful comment
The iOS problem is finally about to go away.
https://webkit.org/blog/7093/release-notes-for-safari-technology-preview-19/