<form name="form1" id="form1" method="post" action="formvalidation1.asp?validationtype=asp" onSubmit="return validate();"><input type="text" name="name" tabindex="1" id="name" onblur="validateMe(this.value, 'req_y/name', 'namemsg');"/>
To follow along, you can download the examples here or see them in action below.
Use Hidden Fields
The first method comes from onlinetools.org and it uses hidden fields to hold the validation requirements. Now, I modified the script a bit to make it a little more versatile, but here’s what the markup would look like on a typical form:
<input type="hidden" name="required" id="required" value="name,emailaddress" /> <input type="hidden" name="additional" id="additional" value="emailaddress/email,zipcode/zip" /><input type="text" name="name" tabindex="1" id="name" /><input type="text" name="zipcode" tabindex="2" id="zipcode" /> <input type="text" name="emailaddress" tabindex="2" id="emailaddress" />
In the example above, the the first hidden input field tells us that the values ‘name’ and ‘emailaddress’ are required according to the id. The second ‘emailaddress’ must be in valid email format and ‘zipcode’ must be in a valid zip format.
My concern about this method is that while it does provide better markup, it just doesn’t seem very elegant. It’s confusing just trying to interpret what’s going on. Throw in a sizelimit=”100” and it’s even more taxing. Yes, this method is unobtrusive, but it doesn’t look like it scales very well (imagine what the hidden fields would look like on a large form with multiple validation types). This method gets bulky fast on large forms and seems prone to human errors.
Use the Class Atrribute
Another unobtrusive method uses the class attribute to hold our validation requirements. Here’s what the markup would look like:
<input type="text" name="name" tabindex="1" id="name" class="validate required name namemsg"/> <input type="text" name="nick" tabindex="2" id="nick" class="validate notrequired none nickmsg"/> <input type="text" name="email" tabindex="2" id="email" class="validate required email emailmsg"/>
It works because W3C allows us to place multiple properties in a class attribute :
The class attribute assigns a class name or set of class names to an element. Any number of elements may be assigned the same class name or names. Multiple class names must be separated by white space characters.
One question we should ask ourselves, however, is if this is proper use of the class attribute? Does our page become confusing and lose some of its relevant meaning when some classes define how the page looks while other defines how it will act? Classes are usually associated with the presentation of a web page. In the above example, we are passing information on how we want the input box to behave.
If we look to the authority on this one, the W3C says to use classes with semantics in mind :
Think about why you want something to look a certain way, and not really about how it should look. Looks can always change, but the reasons for giving something a look stay the same.
Good class names like ‘submenu’ or ‘warning’ describe the content . A bad class name, like ‘prettypinkbackground’, might not accurately describe the content when things need to be changed in the future (a div might not be pretty nor pink 3 months down the road). While ‘validate’ is not as bad as ‘prettypinkbackground’, is it appropriate? Who knows.
It’s a very nice method, but each developer should decide and evaluate whether this is an acceptable use of classes in their project.
Create your own Attributes and DTD
If you’re not into putting ‘validate required email’ in class names or hidden fields, you could go all hardcore and add your own custom attributes to the input fields and use a custom DTD to keep your page from not validating.
The markup would look a little something like this.
<input type="text" name="name" tabindex="1" id="name" required="true" message="namemsg"/> <input type="text" name="zipcode" tabindex="2" id="zipcode" validate="zip" message="zipcodemsg"/> <input type="text" name="emailaddress" tabindex="2" id="emailaddress" required ="true" validate="email" message="email"/>
Now that’s a sexy looking form. No hidden fields and no fooling around in the classname. If a field is required we add required=”true”. If there is more validation to be performed we add ‘validate”typeofvalidation”. The message attribute tell us where the feedback will be displayed. Very easy to use, very easy to read.
To make it all validate I simply use the w3c DTD and added the following lines:
<!ATTLIST input required (true|false) #IMPLIED> <!ATTLIST input validate (email|zip|phone|none) #IMPLIED> <!ATTLIST input message (zipcodemsg|emailaddressmsg|namemsg) #IMPLIED>
We then attach our custom DTD to the web page at the top of the html document wit a simple doctype declaration.
<!DOCTYPE html SYSTEM "http://www.particletree.com/examples/unobtrusive-validation/dtd/xhtml1-custom.dtd">
Before you take the code and run, let’s learn a little more about what we’re doing above. A DTD or Document Type Definition is what you put at the top of your web pages to help the browser determine a list of legal elements that can be used on your page. It usually looks something like this:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The above DTD, for example, is what tells us that a <p> tag is valid but <newparagraph> is not. When your page run is through a validator, the code is checked against the page’s DTD. Since ‘required = “true”’ is an attribute we for inputs, the above DTD would not allow our markup to validate. By creating a custom DTD with new custom legal elements, we can say ‘required = “yes”’ or ‘validate = “zip”’.
Unfortunately, there’s a dark side to all of this. Even thgough we’re technically allowed to create our own DTDs, doing so makes the web a very confusing place and if it got crazy would defeat the whole point having the w3c around to create standards for web development. Plus, the page is not totally future proof. Things could get ugly if a browser or W3C decided that ‘required=”true”’ actually means something different. If you’re curious about DTD’s and futureproofing you might want to look into namespaces.
When it comes down to it, there is no real right answer to which of the above methods works best. Personally, I prefer the class method of validation when it comes to my forms. The solution is a good balance on the issues and features I’m looking for and it’s very versatile. And I think the sacrifice to semantics is a bit trivial. Even though custom attributes and DTDs are appealing in their own rebellious, nerd-like fashion, creating a custom DTD just doesn’t sit right in my stomach, especially when I believe W3C works very hard to give me the valid tools I need to create a reusable and easy to use validation system.
The following articles and sites were great resources of information that lead to the creation of this guide.