[number-field] Consider using `input type="text"` for number and integer fields

[sissbruecker]

Describe your motivation

Currently vaadin-number-input internally uses an input 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 an input 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 our vaadin-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

• Configurable representation number formats, i.e. how should a number entered by the user be formatted and displayed in the input (groups separator, decimal separator, number of decimals, prefix / suffix)
• Configurable parsing number formats, i.e. how should the number entered by the user be parsed and provided through the value property
• Enforce preventing entering invalid characters consistently in all browsers (#1169)
• Being able to notify the user when they entered an invalid character, rather than have it swallowed by the browser.
• Make steps optional, instead of having a default of 1 (#1224)
• Select an appropriate on-screen keyboard layout for mobile devices, considering whether negative numbers or decimals are allowed (#3100 )
• ...Feel free to add more points here

What behaviour would we have to reimplement, what do we need to look out for

• A default, locale-based, number parsing mechanism would have to be reimplemented from scratch. This is not a trivial task, and we would need to spend a lot of effort to make sure we do not degrade the UX for specific locales.
• Our component would need to differentiate between the presentation value, which is what the user entered and sees in the input in their locale number format, and the internal value (observable from the value property), which should be a numeric value that can be processed by a program, for example with parseFloat(value)
• Validation, such as required, min and max, would have to be reimplemented
• Preventing entering invalid characters would have to be reimplemented. This very likely also depends on the locale, as not all locales use just ,, . or -.
• Steps logic would have to be reimplemented. This also ties into validation, as using the stepper controls should always result in a valid value.
• Native number inputs have some additional ways of controlling them, for example scrolling up/down, or using the arrow keys triggers the stepper controls, and increases or decreases the value.
• We would need to ensure a reasonable numeric on-screen keyboard layout is used for mobile devices
• ...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:

• react-aria
  • useNumberField
  • NumberParser

[jorgheymans]

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.