Add support for the input type=range #5892
Comments
|
+1 |
6 similar comments
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
Indeed. It sounds petty, and it's probably easy to learn how to write a directive to fix this by passing through Most use cases of input ranges will expect/need a number, and it's not terribly inefficient to support that. |
|
+1 |
|
+1.. It should have something like ns-type="integer" or ns-type="float" |
|
+1 |
1 similar comment
|
+1 |
|
+1 |
Bind model of <input type="range"> to number (like <input type="number">) rather than string. Range inputs represent numerical values; therefore, a numerical binding makes more sense than a string binding. Closes angular#1189, angular#5892
|
+1 |
1 similar comment
|
+1 |
|
+1 |
|
People have been writing +1 for 1.5 years. Can someone on the angular team comment? |
|
(You mean like add a +1 themselves ? 😛) |
|
This issue has the So, there's not much more to comment about it I guess (for the time being at least). If they haven't taken care of it yet, it's probably because they have been attending to other issues (bug fixes, perf improvements, features, chores) that were higher in priority (for whatever reason). Patience poor issue...your turn will come...(unless, you know, it doesn't)... (Not speaking on behalf of the team or anything...) |
|
+1 |
7 similar comments
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1. Just traced a weird-looking bug to this - in a language where ("7" + 3) * 10 is 730, having obviously-numeric values be strings is just asking for sensible-looking code to produce insane values. |
|
+1 |
1 similar comment
|
+1 |
|
+1 |
the input[type=range] behavior is the same of an input[type=number] with min=0, max=100 and step=1 as defaults Closes angular#5892 Closes angular#9715
the input[type=range] behavior is the same of an input[type=number] with min=0, max=100 and step=1 as defaults Closes angular#5892 Closes angular#9715
Thanks to @cironunes for the initial implementation in angular#9715 Adds support for binding to input[range] with the following behavior / features: - Like input[number], it requires the model to be a Number, and will set the model to a Number - it supports setting the min/max values via the min/max and ngMin/ngMax attributes - it follows the browser behavior of never allowing an invalid value. That means, when the browser converts an invalid value (empty: null, undefined, false ..., out of bounds: greater than max, less than min) to a valid value, the input will in turn set the model to this new valid value via $setViewValue. -- this means a range input will never be required and never have a non-Number model value, once the ngModel directive is initialized. -- this behavior is supported when the model changes and when the min/max attributes change in a way that prompts the browser to update the input value. -- ngMin / ngMax do not prompt the browser to update the values, as they don't set the attribute values. Instead, they will set the min / max errors when appropriate - browsers that do not support input[range] (IE9) handle the input like a number input (with validation etc.) Closes angular#5892 Closes angular#9715 Close angular#14870
Thanks to @cironunes for the initial implementation in angular#9715 Adds support for binding to input[range] with the following behavior / features: - Like input[number], it requires the model to be a Number, and will set the model to a Number - it supports setting the min/max values via the min/max and ngMin/ngMax attributes - it follows the browser behavior of never allowing an invalid value. That means, when the browser converts an invalid value (empty: null, undefined, false ..., out of bounds: greater than max, less than min) to a valid value, the input will in turn set the model to this new valid value via $setViewValue. -- this means a range input will never be required and never have a non-Number model value, once the ngModel directive is initialized. -- this behavior is supported when the model changes and when the min/max attributes change in a way that prompts the browser to update the input value. -- ngMin / ngMax do not prompt the browser to update the values, as they don't set the attribute values. Instead, they will set the min / max errors when appropriate - browsers that do not support input[range] (IE9) handle the input like a number input (with validation etc.) Closes angular#5892 Closes angular#9715 Close angular#14870
Thanks to @cironunes for the initial implementation in #9715 Adds support for binding to input[range] with the following behavior / features: - Like input[number], it requires the model to be a Number, and will set the model to a Number - it supports setting the min/max values via the min/max and ngMin/ngMax attributes - it follows the browser behavior of never allowing an invalid value. That means, when the browser converts an invalid value (empty: null, undefined, false ..., out of bounds: greater than max, less than min) to a valid value, the input will in turn set the model to this new valid value via $setViewValue. -- this means a range input will never be required and never have a non-Number model value, once the ngModel directive is initialized. -- this behavior is supported when the model changes and when the min/max attributes change in a way that prompts the browser to update the input value. -- ngMin / ngMax do not prompt the browser to update the values, as they don't set the attribute values. Instead, they will set the min / max errors when appropriate - browsers that do not support input[range] (IE9) handle the input like a number input (with validation etc.) Closes #5892 Closes #9715 Close #14870
Thanks to @cironunes for the initial implementation in #9715 Adds support for binding to input[range] with the following behavior / features: - Like input[number], it requires the model to be a Number, and will set the model to a Number - it supports setting the min/max values via the min/max and ngMin/ngMax attributes - it follows the browser behavior of never allowing an invalid value. That means, when the browser converts an invalid value (empty: null, undefined, false ..., out of bounds: greater than max, less than min) to a valid value, the input will in turn set the model to this new valid value via $setViewValue. -- this means a range input will never be required and never have a non-Number model value, once the ngModel directive is initialized. -- this behavior is supported when the model changes and when the min/max attributes change in a way that prompts the browser to update the input value. -- ngMin / ngMax do not prompt the browser to update the values, as they don't set the attribute values. Instead, they will set the min / max errors when appropriate - browsers that do not support input[range] (IE9) handle the input like a number input (with validation etc.) Closes #5892 Closes #9715 Close #14870
|
To summarize: https://code.angularjs.org/1.5.9/docs/api/ng/input/input%5Brange%5D |
and others
Originally filed here: #1189
(This was incorrectly closed and despite requests to reopen, has remained closed so I'm reposting as a new ticket. For future reference, closing old tickets due to lack of activity is probably not a good idea.)
With multiple inputs to the same model doesn't play ball. It works as an input but updating it to a value set from another input always fails. Even if the source is also constrained as numeric (type="range" in chrome). This is due to the model being stored as a string.
Demo: http://jsfiddle.net/TXazw/5/Edit
Edit any input except the number and everything updates except the number input. Edit the number input and everything works fine.
A workaround is included. Uncomment parseFloat line and all inputs work correctly.
Should values not be automatically parsed when applied to a number type input? At the very least type="range" should be outputting a number rather than a string.
Discussed in the group:
https://groups.google.com/forum/?fromgroups#!topic/angular/Ecjx2fo8Qvk
The text was updated successfully, but these errors were encountered: