11887 2011-01-27 10:39:06 +0000 Remove useless input.valueAsNumber. Pretty much the same functionality can be achieved using parseFloat or parseInt 2011-08-04 05:12:35 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified Other other RESOLVED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#common-input-element-apis P3 normal --- 12220 1 contributor ian adrianba ayg bugs ian mike mounir pecoraro public-html-admin public-html-wg-issue-tracking shadow2531 public-html-bugzilla oldest_to_newest 44791 0 contributor 2011-01-27 10:39:06 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html Section: http://www.whatwg.org/specs/web-apps/current-work/#common-input-element-apis Comment: Remove useless input.valueAsNumber. Pretty much the same functionality can be actieved using parseFloat or parseInt Posted from: 80.220.69.171 44807 1 pecoraro 2011-01-27 18:57:41 +0000 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 44886 2 adrianba 2011-01-30 01:45:23 +0000 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. 44890 3 mounir 2011-01-30 15:01:21 +0000 (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. 44892 4 bugs 2011-01-30 17:16:51 +0000 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? 45794 5 mounir 2011-02-18 11:56:36 +0000 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. 45795 6 mounir 2011-02-18 12:07:00 +0000 (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... 46099 7 ian 2011-02-28 20:01:43 +0000 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. 46105 8 bugs 2011-02-28 21:04:55 +0000 OK, so let's remove it. 46178 9 mounir 2011-03-02 17:05:53 +0000 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. 46185 10 adrianba 2011-03-02 17:41:44 +0000 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. 46186 11 bugs 2011-03-02 17:45:12 +0000 How makes adding yet another method to DOM/JS the code more readable? And actually, because of bug 12220, valueAsNumber works currently rather strangely. 46187 12 adrianba 2011-03-02 17:46:57 +0000 It's more readable because it's just a property access with a name that indicates what is happening. 48104 13 ian 2011-05-05 21:23:07 +0000 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. 48382 14 ian 2011-05-09 21:49:03 +0000 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)); 52133 15 ian 2011-08-03 07:21:14 +0000 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 53310 16 mike 2011-08-04 05:12:35 +0000 mass-move component to LC1