Change course on `editor-number-arrow-keys` customizability change

[DNin01]

Pull request #6625 added string settings so you could fully customize the step increments in this addon. Then pull request #6744 changed the setting types from fully-customizable strings (which the type of which was incorrectly set, by the way; it should've been untranslated, not string) to decimal settings, which accept only numerical values but don't accept any values more precise than their step increments, which were set to 0.1 (except for one, which was 0.01). This led to some mixed opinions:

@WorldLanguages (posted in #6744 (comment))
Why was this merged? String settings worked just fine and were actually customizable and functional

mxmou said:

The decimal input should at least accept all values of the select setting. It's currently only possible to set "change on regular key press" to 0.01 if "use custom values" is disabled.

DNin01 said:

it would be kind of strange to put up another update notification to say the settings got even more precise

We should either revert this PR or possibly revert #6625 instead (and wait until v1.36 is released to allow for custom values in this addon).
Or as secret-chest said, "fix the steps" (tip: I had no idea what you meant by that, try being more clear such as saying 0.01 can't be entered)

Reverting would be an opportunity to have more time to discuss the best way to implement this. What should we do, @ScratchAddons/admins, @Secret-chest, @Samq64, @mxmou?

And before you say, "we'll just change it later", we can technically do that, but we're already about to say that the values are fully customizable, and I just think that if we decide to upgrade this again in the future, it would be kind of strange to announce again (in a notification, blog post, or anywhere, except the changelog, probably) that the settings became even more flexible. Once we announce our addition of these custom value fields, which weren't there from the start, they'll already feel like they're in their final form, and not really in need of an upgrade to most users. By reversing course, we don't announce the changes and can therefore announce them in whatever state they're in when we release them.

(Maybe we should also remove the select settings and "use custom values" switch and only have input fields for numbers?)

[WorldLanguages]

Why not just reverse the decimal PR and keep the settings as "untranslated"? (untranslated string)
We wouldn't need to "announce" anything if we ever add the decimal settings properly, they would have the same level of customizability as previously. I don't think I understand why that PR was rushed for this release

[Samq64]

Maybe we should also remove the select settings and "use custom values" switch and only have input fields for numbers?

I was actually going to make an issue about that. I think the main reason the select settings were kept was because we didn't have proper decimal settings but now we do.

For the step I suggest decreasing all of them to 0.005 (or maybe 0.001?)

[DNin01]

I like the idea of using decimal settings instead of strings but the whole stepping thing is complicated, and maybe we shouldn't even set step increments. But if we do and the step property affects what values are valid, the increment shouldn't be too small because then it'd take forever to increment the setting with the arrow buttons. I think this is exactly why the pull request proposed the step increments it did.

It's also funny talking about stepping for an addon about stepping.

[DNin01]

Related for cross-compatibility with string settings: maxlength can be used to limit the length limit of input fields, and I believe we could also use it here. This could essentially act as a precision limit, and we could pair it with max. For example, to allow numbers between 0 - 1,000 and down to the thousandth (so 1,000x in both directions), we could set max to 1000 and maxlength to 5 for the 0, decimal place, and decimal digits.

[Secret-chest]

I like the idea of using decimal settings instead of strings but the whole stepping thing is complicated, and maybe we shouldn't even set step increments. But if we do and the step property affects what values are valid, the increment shouldn't be too small because then it'd take forever to increment the setting with the arrow buttons. I think this is exactly why the pull request proposed the step increments it did.

I think it's more important to be able to type your value. Going from 0.25 to 0.26 with a click is not important, but being able to set 1/8 (0.125) is.

Related for cross-compatibility with string settings: maxlength can be used to limit the length limit of input fields, and I believe we could also use it here. This could essentially act as a precision limit, and we could pair it with max. For example, to allow numbers between 0 - 1,000 and down to the thousandth (so 1,000x in both directions), we could set max to 1000 and maxlength to 5 for the 0, decimal place, and decimal digits.

But why?

[mybearworld]

Related for cross-compatibility with string settings: maxlength can be used to limit the length limit of input fields, and I believe we could also use it here. This could essentially act as a precision limit, and we could pair it with max. For example, to allow numbers between 0 - 1,000 and down to the thousandth (so 1,000x in both directions), we could set max to 1000 and maxlength to 5 for the 0, decimal place, and decimal digits.

Why have a precision limit at all? Also, this would act as a length limit for the whole number, which would certainly be annoying.

[mxmou]

Why not just reverse the decimal PR and keep the settings as "untranslated"? (untranslated string)
We wouldn't need to "announce" anything if we ever add the decimal settings properly, they would have the same level of customizability as previously. I don't think I understand why that PR was rushed for this release

If we do this, the decimal settings need to have step="any" when they're implemented so that they actually have the same level of customizability. Wouldn't it be easier to change the step value to any now?

[WorldLanguages]

Oh, didn't know step="any" is an HTML feature. Could anyone submit a PR and test it though?

[WorldLanguages]

I'll have to guess step=any wasn't chosen for a reason, and I don't have the time to test for bugs, so I'll just revert to string settings for now.
As I said, we don't need to announce decimal settings, so it will be a silent enhancement.

[WorldLanguages]

I merged #6767 which reverted decimal settings, this whole issue already delayed the release by a day it's enough

[DNin01]

I'll see if I can find some ways to still use a decimal setting input while maintaining the current level of customizability. Other than that, this issue's all done!