Actually, we don't want that. Olli and I tried to have it removed from the specs but I wrote a patch a long time ago so I'm going to refresh it and attach it here. Bug against the specs: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11887

I'm asking a review but this might be canceled and the bug marked as WONTFIX if the specs remove this attribute.

Use double instead of float.

I'd still like to see either a reasoning for valueAsNumber or it to be removed from HTML.

Comment on attachment 515641 [details] [diff] [review] Patch v1.1 >+nsHTMLInputElement::GetValueAsNumber(double* aValueAsNumber) >+{ >+ if (!DoesValueAsNumberApply()) { >+ *aValueAsNumber = std::numeric_limits<double>::quiet_NaN(); >+ return NS_ERROR_DOM_INVALID_STATE_ERR; >+ } XPCOM rules actually dictate that you should not assign to the out parameter here. r=me with that fixed

(In reply to comment #4) > Comment on attachment 515641 [details] [diff] [review] > Patch v1.1 > > >+nsHTMLInputElement::GetValueAsNumber(double* aValueAsNumber) > >+{ > >+ if (!DoesValueAsNumberApply()) { > >+ *aValueAsNumber = std::numeric_limits<double>::quiet_NaN(); > >+ return NS_ERROR_DOM_INVALID_STATE_ERR; > >+ } > > XPCOM rules actually dictate that you should not assign to the out parameter > here. > > r=me with that fixed Eh, this was actually, wrong: I shouldn't throw an exception when getting a value while valueAsNumber doesn't apply but just returning NaN. This is fixed locally.

Spec bug has been closed as RESOLVED WONTFIX, so I guess patch should be landed into m-c.

(In reply to Atul Aggarwal from comment #6) > Spec bug has been closed as RESOLVED WONTFIX, so I guess patch should be > landed into m-c. This will land with the entire <input type='number'> patch queue which is not ready yet.

This patch landed too early, as Firefox 16 has no input type=number, but this numberAsValue! Without number support, the result is always NaN, which breaks feature detection. if (input.valueAsNumber !== undefined){ ... input.valueAsNumber; }else{ ... parseInt(input.value, 10); }

Just for the record. The feature detection had to be changed to: if (input.type === "number" && input.valueAsNumber !== undefined) the problem is imo still valid.

See bug 866457 for documentation.