This page tests two things about JavaScript form serialization: quality and speed.

• Quality is dertermined by analyzing the serialized output according to the W3C Recommendation.
• Speed is measured using Firebug to time (or profile in FireFox) numerous iterations of the serialization process.^[1]

Timer Profiler Iterations: 1 25 50 100 200

Output (errors in red)

NATIVE	check your browser's *native* form serialization
jQuery
dojo
YUI
MochiKit
Prototype

The following form contains each of the possible elements that can be submitted (with the exception of <input type="file">). Which elements, and how they should be submitted, is specified here: http://www.w3.org/TR/html401/interact/forms.html#h-17.13

Most enabled input elements and textareas are handled correctly by each of the libraries.
<textarea name="T3" rows="2" cols="15">? Z</textarea>	? Z
<input type="hidden" name="H1" value="x" />
<input type="hidden" name="H2" />
<input type="password" name="PWD" />
<input type="text" name="T1" />
<input type="text" name="T2" value="YES" readonly="readonly" />
<input type="checkbox" name="C1" value="1" />
<input type="checkbox" name="C2" />
<input type="radio" name="R1" value="1" />
<input type="radio" name="R1" value="2" />
<input type="text" name="My Name" value="me" />
The reset input should never be serialized. Prototype and MochiKit get this wrong.
<input type="reset" name="reset" value="NO" />
Normal Single select elements are handled correctly by each of the libraries.
<select name="S1"> (100 options)	ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC
Normal multiple select elements are handled correctly by each of the libraries.
<select name="S2" multiple="multiple" size="3"> (100 options)	ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC ABC
The following select element has a selected option with no value attribute. The option text value should be submitted. S3=YES is correct. S3= is incorrect. dojo gets this wrong in IE.
<select name="S3"><option selected="selected">YES</option></select>	YES
The following select element has a selected option with a value attribute set to "". S4= is correct. S4=NO is incorrect.
<select name="S4"><option value="" selected="selected">NO</option></select>	NO
The following select element has its selectedIndex property set to -1 before serialization. It should not be submitted. dojo and MochiKit get this wrong.
<select name="S5"><option value="NO">NO</option></select>	NO
Submit elements should only appear in the query string when they are the element used to submit the form. Only jQuery and dojo get this right. YUI always includes the first submit element. Prototype sends all the input submit elements (but not button submit elements). MochiKit sends them all.
<input type="submit" name="sub1" value="NO" />
<input type="submit" name="sub2" value="NO" />
<input type="image" name="sub3" src="submit.gif" value="NO" />
<button type="submit" name="sub4" value="NO">NO</button>	NO
Disabled elements should never be submitted. MochiKit and mootools get this wrong.
<input type="text" name="D1" value="NO" disabled="disabled" />
<input type="checkbox" name="D2" value="NO" checked="checked" disabled="disabled" />
<input type="radio" name="D3" value="NO" checked="checked" disabled="disabled" />
<select name="D4"><option selected="selected" value="NO" disabled="disabled">NO</option>	NO

Notes

This test page does not expose serialization problems that occur during an actual form submit. These include:

• YUI, Prototype and MochiKit do not support input elements of type="image".
• dojo does not capture the click coordinates of input elements of type="image". However, it does correctly recognize it as the submitting element.
• dojo does not properly support semantic serialization when the form contains an input of type="image". When such an element is used to submit the form, it will always appear last in the query string regardless of its semantic position. (This is likely a very low-percentage use case.)
• mootools is not compatible with Prototype and is not included on this test page. A test page that includes mootools can be found here. In summary, mootools does not support semantic serialization and it incorrectly submits disabled fields.

Encoding

Each of the libraries tested use JavaScript's encodeURIComponent^[2] function to encode form data. Technically, this does not conform to the HTML spec which states the following about the application/x-www-form-urlencoded content type (emphasis added):

This is the default content type. Forms submitted with this content type must be encoded as follows:

1. Control names and values are escaped. Space characters are replaced by `+', and then reserved characters are escaped as described in [RFC1738], section 2.2: Non-alphanumeric characters are replaced by `%HH', a percent sign and two hexadecimal digits representing the ASCII code of the character. Line breaks are represented as "CR LF" pairs (i.e., `%0D%0A').
2. The control names/values are listed in the order they appear in the document. The name is separated from the value by `=' and name/value pairs are separated from each other by '&'.

While this does not seem to cause any problems, it is interesting and noteworthy.

Links

• jQuery
• dojo
• YUI
• MochiKit
• Prototype
• mootools