You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 3, 2024. It is now read-only.
When a dcc.Input component has type="number", it's difficult to get the field to accept negative numbers due to the client-side validation. A - character is not permitted unless it precedes a number, which means you have to to enter the digits of your desired number first, before moving the cursor to the start of the field and entering the - character.
When the last character in the field is deleted the field's contents are also immediately set to 0, which I find incurs some amount of cognitive friction when editing the field's contents. I'm guessing both these properties of the validation are intended to always ensure the current value of the field is a valid number, however this comes at the cost of usability I think. I also wonder how important this invariant is to maintain given that an invalid (ie non-numeric) value can be set as an initial value in the layout and therefore can be sent through to the callback.
The text was updated successfully, but these errors were encountered:
@ned2 Thanks for pointing this issue out. Agree that usability is taking a toll here and needs to be improved -- something as simple as behaving like a normal <input type='number' /> would be better.
When a
dcc.Input
component hastype="number"
, it's difficult to get the field to accept negative numbers due to the client-side validation. A-
character is not permitted unless it precedes a number, which means you have to to enter the digits of your desired number first, before moving the cursor to the start of the field and entering the-
character.When the last character in the field is deleted the field's contents are also immediately set to
0
, which I find incurs some amount of cognitive friction when editing the field's contents. I'm guessing both these properties of the validation are intended to always ensure the current value of the field is a valid number, however this comes at the cost of usability I think. I also wonder how important this invariant is to maintain given that an invalid (ie non-numeric) value can be set as an initial value in the layout and therefore can be sent through to the callback.The text was updated successfully, but these errors were encountered: