Skip to content
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

Improvement suggestions for <<numberbox>> #40

Open
9 tasks
BawdyInkSlinger opened this issue Oct 28, 2020 · 3 comments
Open
9 tasks

Improvement suggestions for <<numberbox>> #40

BawdyInkSlinger opened this issue Oct 28, 2020 · 3 comments

Comments

@BawdyInkSlinger
Copy link

I have some suggestions for improvements to this macro:

  • It considers a decimal point to be an error unless it's .0 -- I think these should be configurable validation settings. Sometimes you want to real numbers, sometimes you only want integers.
    • The text is considered valid if you type in "1." -- This should be considered invalid.
  • It is inconsistent about when it reports errors. If you type "asdf" it reports it as an error when it loses focus. If you type "1.5" it reports it as an error as you are typing. -- this should be consistent, preferably errorring as you type
  • It lets you type in letters, but doesn't save the letters into the variable, preventing you from telling the user that "$var is not a number" (that would print as "0 is not a number") -- I think you should not be allowed to type or paste anything but numbers and decimal points (commas, depending on locale). That would fix a lot of these problems.
    • It would be nice to have way of knowing if the field is invalid. That way, I could prevent a continue button from being clicked. If 0 is a valid number in context, I don't know how to tell if somebody typed in zero or something invalid.
  • It doesn't let you specify a valid range -- I think more often than not, there is a valid range and an invalid range. It would be nice if the macro allowed you to specify it. You should not be able to use numbers outside of this range.
  • It saves a string into the variable, making it inconvenient to implement custom range validation. -- I think the variable should be a number type
  • When you click on the text field, it doesn't highlight the content of the field. This means, if you click and then type 3, it'll probably come out as 30 or 03. You have to click, delete/backspace (depending on which side of the number you clicked), then type what you want to enter -- clicking on the field should highlight the text
  • If you type in letters, clicking the up/down buttons doesn't do anything. I think it should clear the field and +/- the default number. -- ideally, you wouldn't be able to type in letters at all, but if you want to allow that, I think the buttons should clear the field, reset it to the default, and execute the up/down code
@tmedwards
Copy link
Owner

I'm going to assume that you're referring to the <<numberbox>> macro that was first added to the standard library in v.2.32.0 and updated in v.2.33.0. I'll be referring to the latest public version.

I have some suggestions for improvements to this macro:

Considering that the macro's actual UI widget is an <input type="number"> element, most of your suggestions are probably going to need to be filed with (a) the standards groups and/or (b) the browser manufacturers. If I don't specifically reply to something below, then that's the case—or I consider it such, anyway.

Additionally. As is often the case, the <input type="number"> UI is not consistent across browsers, so some of your complaints are not cross-browser—in particular, Gecko and Blink have very different behavior here. E.g., Chrome does not allow any letters to be entered—aside from the scientific notation e.

  • It considers a decimal point to be an error unless it's .0 -- I think these should be configurable validation settings. Sometimes you want to real numbers, sometimes you only want integers.
  • It doesn't let you specify a valid range -- I think more often than not, there is a valid range and an invalid range. It would be nice if the macro allowed you to specify it. You should not be able to use numbers outside of this range.

These are possible to address in SugarCube, but may not be in v2 due to argument list issues. Additionally, some, like range, can be checked by user code post-input.

  • It saves a string into the variable, making it inconvenient to implement custom range validation. -- I think the variable should be a number type

I'm unsure what you think you're seeing, but it only stores numbers within the receiver variable. Beyond that, no browser that I know of writes non-numbers to the field value of an <input type="number">, so <<numberbox>> never even sees non-numbers to begin with.

tmedwards referenced this issue in tmedwards/sugarcube-2 Nov 8, 2020
Not nearly a complete solution for decimals, but at least this keeps Firefox, and possibly others, from flagging decimal numbers as invalid.
@tmedwards
Copy link
Owner

Browsers (chiefly Firefox ) should no longer flag decimal numbers as invalid in the next release.

@tmedwards
Copy link
Owner

tmedwards commented Mar 19, 2021

With the recent inputmode change (commit tmedwards/sugarcube-2@a9984f9), I've done about as much as I can do for <<numberbox>> in v2 without introducing breaking changes. Thus, I'm going to move this issue over to the v3 repo.

@tmedwards tmedwards transferred this issue from tmedwards/sugarcube-2 Mar 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants