W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > January 2011

[Bug 11887] Remove useless input.valueAsNumber. Pretty much the same functionality can be achieved using parseFloat or parseInt

From: <bugzilla@jessica.w3.org>
Date: Sun, 30 Jan 2011 15:01:21 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1PjYmH-0002yy-Vn@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11887

--- Comment #3 from Mounir Lamouri <mounir.lamouri@gmail.com> 2011-01-30 15:01:21 UTC ---
(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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Sunday, 30 January 2011 15:01:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 30 January 2011 15:01:24 GMT