A lot has changed in the way web pages work over the years. One thing that hasn't changed is the usefulness of JavaScript in being able to validate form fields in advance of sending the form to the server so as to make it easier for the person filling out the form to correct their errors. What has changed is how to best go about doing this.
Unobtrusive JavaScript has grown in popularity over the years since keeping your JavaScript completely separate from the HTML makes both of them easier to maintain and also improves how things work for those minority who for one reason or another do not have JavaScript. So one thing that we want to do if we want to modernise the way our form field validations work is to get rid of all the onblur, onchange, onkeypress, onsubmit etc. attributes out of our HTML and attach the validations using event listeners from within the JavaScript itself (of course using attachEvent as well for those of our visitors still using Internet Explorer 8 or earlier).
Another thing we ought to consider is just how we go about identifying the particular form fields that we want to attach these listeners to. Traditionally, JavaScript form validation has used the field names to reference the individual fields from within the form collection. The introduction of the Document Object Model means that we now have alternative ways of referencing the individual form fields. With the change to the way that modern forms are defined in HTML, most form fields now have a label and if you write your HTML semantically and don't make the form field itself a part of its own label, you will need to give each form field an id in order to be able to attach the corresponding label. We can also use this id in our JavaScript to attach our processing to the form field without needing to reference the field's name at all. This makes for more flexibility, allowing the names to be used specifically for the subsequent server side processing and so form fields that are not to be passed to the server need not have a name at all.
Perhaps the biggest recent change to the way forms can be defined is all of the additional attributes introduced in HTML5. The new attributes mean that some form validation can be performed without the need for any JavaScript at all. At the time of writing this these attributes are just a part of a draft proposal and are a long way from becoming a standard but some browsers have already implemented some of them. Even without support for these new attributes in all browsers we can make use of them to greatly simplify our JavaScript validation.
The required attribute does away with the need for us to maintain a separate list of the mandatory fields in each form. Instead of having to hard code the test for whether the field has had something entered into it into each field validation or looking up a separate list of which fields are mandatory we can simply check for the presence of this attribute when validating the field and perform the appropriate test for something having been entered.
The pattern attribute is even more useful to us because it allows a regular expression to be specified as the pattern against which the field is to be validated. As most of our form field validations are best done using a regular expression to define a pattern that the entered content must match (rather than performing a whole series of separate tests) we can again simplify our processing by retrieving the expression to validate the field against from the HTML rather than hard coding it into the JavaScript. Of course a single expression may not cover everything that we want to validate for and so we will still need to add whatever extra validation each field requires using JavaScript regardless of what support a particular browser provides for these attributes.
The addition of the list attribute and datalist tag provides us with a way of creating combo boxes that will work even without JavaScript in those browsers that recognise it. While waiting for everyone to upgrade to browsers that add this support we can amend the way we code our combo boxes to replace the unordered list that we were using with our JavaScript combo box script with a datalist. In browsers that do support combo boxes the datalist automatically hides any entries that do not match what has already been typed into the input field and so we might consider adding that functionality into our JavaScript version in order to support longer lists.
HTML5 also adds a number of additional form field types. Browsers that do not yet support these additional types will treat them as if they were ordinary text fields. If we decide to use any of these thirteen new form field types in our web page then we might consider adding JavaScript that tests the type of the field so as to apply at least some additional validations for when the browser itself doesn't recognise them. We could also consider actually using JavaScript to make them behave more like they would in browsers that do support them.
Given how slowly people using Internet Explorer upgrade their browser it will probably be a long time before all of the new form functionality added in HTML5 will actually run in all of our visitor's browsers and so while we are waiting we can add equivalent support using JavaScript. In the case of field validations the only effect of performing the validations in JavaScript that may have already been applied in HTML will be an unnoticeable delay in the processing of the page. Of course where we decide to implement some of the other functionality that the new field types will have we will need to test first if the browser supports the HTML version since otherwise we will be overlaying our JavaScript generated version over the HTML generated one.
Of course these additions to HTML once all browsers do support them will not do away with the need to use JavaScript to validate forms. The validations that some form fields will require will still be too complicated to be able to specify them as a single regular expression. Also there is nothing in the new HTML that caters for validating form fields dynamically as they are being entered and nothing to allow for any required validations involving more than one field.