- From: <bugzilla@jessica.w3.org>
- Date: Sun, 30 Jan 2011 15:01:21 +0000
- To: public-html-bugzilla@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 UTC