input.valueAsNumber is useful for date and range input types. It isn't even allowed on text input types. See the table at:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element

Some input type likes type=range store the value internally as a number. Converting to a string for .value and then back to a number in script is a waste. valueAsNumber is useful to avoid this.

(In reply to comment #1)
> input.valueAsNumber is useful for date and range input types. It isn't even
> allowed on text input types. See the table at:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element

For range and number, |input.valueAsNumber| is equivalent to |parseFloat(input.value)|.
For date related types, |input.valueAsNumber| is equivalent to |input.valueAsDate.milliseconds|.
So, it's not really useful, it's only shorter (in term of characters).
In addition, I think the way .valueAsNumber behaves is really weird: returning the number of milliseconds from the UNIX epoch for date related types isn't intuitive.

(In reply to comment #2)
> Some input type likes type=range store the value internally as a number.
> Converting to a string for .value and then back to a number in script is a
> waste. valueAsNumber is useful to avoid this.

According to the specs: "The input element [in the Range state] represents a control for setting the element's value to a string representing a number.". It's the same for the Number state. And according to the specs you have to parse the value to a floating number when .valueAsNumber is called.
Though, I can understand that implementation could try to optimize .valueAsNumber by storing the value as a number but I don't think it worths keeping this method.

From API usage point of few the fact that some 
implementation may store the value as number doesn't really matter.
JS developers do know parseInt and parseFloat. Is there any reason why
they should use valueAsNumber?

I've actually found one situation where .valueAsNumber and parseFloat() would differ: if .value begins with a valid number which is followed by a string.
For example: "42 foo"; parseFloat() will return 42 and .valueAsNumber NaN.

That might be a good reason to keep .valueAsNumber I think.

(In reply to comment #5)
> I've actually found one situation where .valueAsNumber and parseFloat() would
> differ: if .value begins with a valid number which is followed by a string.
> For example: "42 foo"; parseFloat() will return 42 and .valueAsNumber NaN.
> 
> That might be a good reason to keep .valueAsNumber I think.

Actually, when valueAsNumber is available, value can't contain something else than a number so my previous comment doesn't apply...

valueAsNumber was really just added for completeness after we added valueAsDate, IIRC. I don't mind removing it if people don't want to implement it. As the comments above say, it's purely an authoring convenience, it doesn't provide anything that can't be obtained in another way.

OK, so let's remove it.

It seems like parsing a floating point number in HTML and in Javascript specifications might differ. I've open bug 12220 about that. I guess we should make sure it's fixed before removing valueAsNumber.

In our prototyping we've found the valueAsNumber concept is a useful convenience API that avoids a round-trip through a string. It's not hard to implement and since almost every use case where valueAsNumber is valid involves dealing with the value as a number why not keep it? It makes JavaScript code more readable.

How makes adding yet another method to DOM/JS the code more readable?
And actually, because of bug 12220, valueAsNumber works currently
rather strangely.

It's more readable because it's just a property access with a name that indicates what is happening.

Right now Opera and WebKit support it, and IE and Firefox don't, but Microsoft is arguing in favour. This to me seems to suggest we should keep it, even though it's very much a convenience method and doesn't really provide anything truly novel. I'm not closing this bug yet, though; if the people who want for us to drop this can convince the vendors who have shipped with it to remove it then I'd be happy to remove it.

Came across an interesting example of the convenience for this recently: changing the value of a range control by a certain known delta:

   input.valueAsNumber += delta;

The alternatives are a bit of a pain:

   input.value = parseFloat(input.value) + delta;

   if (delta > 0)
     input.stepUp(delta/parseFloat(input.step));
   else
     input.stepDown(delta/parseFloat(input.step));

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: see last two comments

mass-move component to LC1