Cleave.js: Inconsistent behavior of backspace around delimiters

[aDudman]

I've noticed that the Backspace key does not seem to be behaving consistently around delimiters. Specifically, delimiters which are the last character in an input field are treated differently from delimiters in the middle of the field when attempting to backspace over them.

For an example, suppose I enter a date in the format YYYY/MM/DD, then realize I made a mistake in the Month. Two possible ways to solve the problem could be:

• Backspace 4 times, then enter both the Month and Day again. Intuitively, the '/' character inserted by Cleave will be deleted alongside the 4 characters typed by the user.
• Use the left arrow key twice to skip the Day characters, then Backspace twice to delete just the Month characters and enter them again. Currently this does _not_ work as expected: the first backspace gets "eaten" by Cleave and doesn't delete any of the characters entered by the user.

To me, the keystrokes "Backspace x4, type x4" and "Left x2. Backspace x2, type x2" should both be usable to correct the error. However, the first method will always correctly delete 4 user-entered characters (thus typing 4 new characters will replace them) while the second can delete _fewer_ than two user-entered characters giving unusual results. Arrow keys also lack the ability to skip over delimiters, but they are consistent about it (i.e. arrow keys work the same around delimiters regardless of whether that delimiter is in the middle or at the end).

TL;DR: When using Backspace at the end of an input, each keystroke deletes one _user-entered_ character regardless of what delimiters are present. When using Backspace in the _middle_ of an input, delimiters will "consume" keystrokes to give unintuitive results.

This behavior is easily visible on the demo page or the basic JSFiddle playground, just place your cursor to the right of any delimiter (e.g. the '/' in dates, the ',' in numerics, or the ' ' in credit cards) and backspace will skip over the delimiter without deleting any characters.

[amit-coditas]

+1, Can someone let me know thisis intentional?

[LavaToaster]

Here's another example of this in action

[grahamharper]

+1

[iuriiismirnov]

+1

[ArsenBatyuchok]

+1

[svewag]

Is this issue under active investigation? Are there any plans or ideas for a fix?

[leerob]

+1

[rqroz]

+1

[nosir]

Yea, the team has evaluated the potential fix, the ideal behaviour is to hold the deleted character and either replace it with placeholders or somehow not fill up them.
But it's hard since how the lib works is totally based on string replacement but not mask input actions.
TL;DR: won't fix this soon :(
Thanks for the detailed description.