-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[number-field] Consider using input type="text"
for number and integer fields
#3102
Labels
enhancement
New feature or request
epic
Big feature that has subtasks
needs discussion
No decision yet, discussion needed
vaadin-number-field
Comments
web-padawan
changed the title
Consider changing
[number-field] Consider using Nov 24, 2021
vaadin-number-input
to use input type="text"
input type="text"
for number and integer fields
This was referenced Nov 24, 2021
This was referenced Nov 24, 2021
This was referenced Jan 3, 2022
9 tasks
yuriy-fix
changed the title
[number-field] Consider using
[number-field] Consider using Sep 25, 2023
input type="text"
for number and integer fieldsinput type="text"
for number and integer fields [3 days]
3 tasks
If you need more weight to put this on your roadmap: Vaadin puts itself mostly in the niche of business applications. Such applications very often deal with amounts, so i think Vaadin could have built-in first class support for entering, displaying, and binding such data in all aspects. |
juuso-vaadin
changed the title
[number-field] Consider using
[number-field] Consider using Jun 13, 2024
input type="text"
for number and integer fields [3 days]input type="text"
for number and integer fields
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
enhancement
New feature or request
epic
Big feature that has subtasks
needs discussion
No decision yet, discussion needed
vaadin-number-field
Describe your motivation
Currently
vaadin-number-input
internally uses aninput type="number"
element. That comes with a lot of benefits, such as supporting localized number formats out of the box, preventing entering non-numeric characters, stepper controls, or displaying an appropriate on-screen keyboard layout on mobile devices. However the approach also has downsides, in that all the above points do not work consistently between browsers, devices, and locales. Another issue is that a number type input does not allow much flexibility, for example when it comes the presentation number format, or when dealing with the stepper buttons. Other component libraries have chosen to implement their number field component using aninput type="text"
instead, by reimplementing some or all of the native behaviour of the native number type input. We can consider doing the same for ourvaadin-number-input
. This ticket is about collecting the benefits that we would gain from such a change, and also about noting down which behaviour we would have to replicate from the native number input if we decide to move ahead with this.What could we gain from it
value
property1
([number-field] Step property should not have default value #1224)...Feel free to add more points here
What behaviour would we have to reimplement, what do we need to look out for
value
property), which should be a numeric value that can be processed by a program, for example withparseFloat(value)
required
,min
andmax
, would have to be reimplemented,
,.
or-
....Feel free to add more points here
Additional context
We should take a look at existing component libraries, which have implemented such an approach, and have worked out most of the kinks. Some notable examples:
The text was updated successfully, but these errors were encountered: