A JavaScript Library Form Serialization Torture Test:   Floatbox • jQuery • dojo • YUI • MooTools • Prototype

Floatbox :
jQuery :
dojo :
MooTools :
Prototype (sux): Not testable. All versions either halt with an error or argue with the other libraries.
Most enabled input elements and textareas are handled correctly by each of the libraries. All but Floatbox and jQuery fail to follow the spec that says line breaks are "%0D%0A" and spaces are "+". These failures are generally harmless.
<textarea name="TA" rows="3" cols="15">? a&#10;bb</textarea>
<input type="hidden" name="HID1" value="x" />
<input type="hidden" name="HID1" value="y" />
<input type="hidden" name="HID2" />
<input type="password" name="PWD" />
<input type="text" name="TXT1" />
<input type="text" name="TXT2" value="yes" readonly="readonly" />
<input type="checkbox" name="CHK1" value="1" />
<input type="checkbox" name="CHK1" value="ab yz" />
<input type="checkbox" name="CHK2" />
<input type="radio" name="RAD1" value="1" />
<input type="radio" name="RAD1" value="2" />
<input type="text" name="TXT NAME" value="me&you" />
Submit elements should only appear in the query string when they are the element used to submit the form. Clicked image elements should report the relative clicked coordinates. Floatbox is the only library that gets this right. jQuery, Dojo and MooTools ignore all submit elements. YUI ignores image submits but will erroneously includes nameless submit inputs and buttons. Prototype always includes the first submit input, all image inputs, and never any submit buttons. MochiKit always includes all submit elements.
<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>
The reset input should never be serialized. Prototype and MochiKit get this wrong.
<input type="reset" name="RES" value="no" />
Normal Single select elements are handled correctly by each of the libraries.
<select name="SEL1"> (10 options)
Normal multiple select elements are handled correctly by each of the libraries.
<select name="SEL2" multiple="multiple" size="3"> (15 options)
The following select element has a selected option with no value attribute. The option text value should be submitted. SEL3=yes is correct. SEL3= is incorrect. Dojo gets this wrong in IE pre 9.
<select name="SEL3"><option selected="selected">yes</option></select>
The following select element has a selected option with a value attribute set to "". SEL4= is correct. SEL4=no is incorrect. Everyone gets this right.
<select name="SEL4"><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="SEL5"><option value="no">no</option></select>
Disabled elements should never be submitted. MochiKit gets this wrong.
<input type="text" name="DIS1" value="no" disabled="disabled" />
<input type="checkbox" name="DIS2" value="no" checked="checked" disabled="disabled" />
Inputs with a type attribute of something other than
should be treated as TEXT inputs. This is handled correctly by all libraries.
<input type="bogus" name="BOG" value="yes" />