Use number field for decimal preference field #2232
Conversation
There are two benefits to this. The UX benefit of the increment/decrement widget on the input field itself, and now a user can no longer enter text into this field (which is rejected upon submit and the preference value is reset to 0).
There was a problem hiding this comment.
One thing I just encountered is that browsers format the decimals depending from the locale of the system (at least in macOS). So, Safari and Chrome display decimals with a comma separator (as my locale is Germany) and for US locale it displays a period separator. And this is independent from the website locale (en in the case of the solidus sandbox). It only respects the OS setting.
This is not a huge deal, because most of the time this is what users will expect. But it is strange to see all numbers localized as English numbers in the rest of the ui, but in the input field it is localized differently.
OS set to US locale
OS set to German locale
Ideally browser vendors would respect the locale setting of the website, but this should not block this PR.
kennyadsl
dismissed
their stale review
Need to revisit taking into account #1821
|
My feeling from working on #1821 is that number inputs are terrible for decimal inputs. Having the input step by 1 isn't desirable for, say, entering a tax rate. The bad browser behaviour w/r/t locale only makes this all worse. I'd rather continue using |
|
Closing due to localization issues with browser vendors. |
There are two benefits to this. The UX benefit of the
increment/decrement widget on the input field itself, and now a user can
no longer enter text into this field (which is rejected upon submit and
the preference value can be reset to 0).
Adding
step: :anyallows both integers and floats to be entered, with the widget stepping up and down by 1.I know that the preference_field_tag is deprecated, but this threw me off when I was testing something related.