Why aren't some technically serializable input properties serializable?

Serializable property is defined as:

• When you set a property of the element, it will be reflected in serialization queries such as getAttribute and you can see the changes in DOM Inspector
• When you get the .innerHTML of the element's parentnode, the returned html string will contain all the serializable properties as their attribute counterparts

I have made a page that looks like it's reliably printing a table of all serializable properties of the input element in Chrome and Firefox: http://jsfiddle.net/tEVLp/16/. Custom properties are never serializable, so in firefox webkitSpeech etc are not serializable. Test in chrome for best results.

All booleans are true because serialization of a false property would be the absence of the attribute which is a false negative in the test.

So my question is, why are not properties such as .value and .checked serializable?

Technically, both are serializable. .value is just a string and the browser has no problems with serializing other boolean properties, such as .readOnly and .disabled.

My best guess is that since .defaultValue serializes to "value"-attribute and .defaultChecked serializes to "checked"-attribute, there would be a conflict and thus the .value and .checked cannot be serialized. In that case, why are the defaultX ones chosen for these and not the ones that reflect the more useful current .value and .checked states?

Solution 1:

The Specification for input elements defines the exact behaviour. Start reading from here (before that, the DOM interface, attributes and types are defined).

Concise summary (value is defined similarly to checked, so for brevity, I'm going to explain value only).

The "property" value reflects value ^def,
the "attribute" value reflects the value content attribute ^def.

• The attribute defines the default value property ^(ref). This value is also reflected ^def by the defaultValue property (ref).
• When the value attribute is set, then the value property changes (ref) *.

That was worded very concisely. I've skipped an important detail. The specification is very clear at this point, so I'll just quote the dirty value flag section:

Each input element has a boolean dirty value flag. The dirty value flag must be initially set to false when the element is created, and must be set to true whenever the user interacts with the control in a way that changes the value.

The value content attribute gives the default value of the input element. When the value content attribute is added, set, or removed, if the control's dirty value flag is false, the user agent must set the value of the element to the value of the value content attribute, if there is one, or the empty string otherwise, and then run the current value sanitization algorithm, if one is defined.

Solution 2:

value and checked properties do not correspond to HTML attributes so they cannot be serialized to HTML. As to why a defaultX property maps to the x attribute, I'm not sure. The alternative, a property x mapping to the x attribute and having another property such as currentX to represent the current value, seems slightly less intuitive because in general a script is going to need the current value more often than the default value.