JavaScript Form Serialization Comparison:   jQuery • dojo • Prototype • YUI • MochiKit

This page tests two things about JavaScript form serialization: quality and speed.
If you believe the tests or comments on this page are inaccurate or unfair - please let me know. It is not my intent to misrepresent any of these libraries. Feedback can be sent to: forms at malsup dot com.
»» Special thanks to Marius Feraru for adding support for native browser output and the EOL test!
Timer Profiler Iterations:

Output (errors in red)
NATIVE
jQuery
jQuery Form
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>
<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)
Normal multiple select elements are handled correctly by each of the libraries.
<select name="S2" multiple="multiple" size="3"> (100 options)
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>
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>
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>
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>
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>
Inputs with a type attribute of something other than
PASSWORD | CHECKBOX | RADIO | SUBMIT | RESET | FILE | HIDDEN | IMAGE | BUTTON
should be treated as TEXT inputs.
<input type="bogus" name="TYPE-TEST" value="YES" />
<input type="search" name="SEARCH" value="YES" />

Notes

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

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