maybe focus only on masking?

[tomByrer]

Seems you are expanding the scope of masking ((not showing characters as being typed) into validation (ensuring typed characters are correct for field)? I can see some cross-over, but will exponentially increase the time to get through the validation & implementation stages.

Might be useful to explore how the 2 would interact to build the masking proposal, but I can see masking-alone get through the process in a year, while validation would take many years & TBH create a bunch of code that is rarely used for all the edge cases.
(eg the piping proposal has totally stalled out; too many moving parts

But if you want to dig into validation more, might be better just to label the proposal as js-input-validation-masking.
I used to help out with some RegEx presets; @tunnckoCore is the main organizer there.
https://github.com/regexhq

[tomayac]

Thank you very much for opening the issue. I actually was purely focusing on masking, not validating. What part of the explainer made you think it was also aimed at validation? I need to reword this then. Thanks for your help in making this clearer.

[tomByrer]

OK I'm confused.

helps users enter information in forms more correctly, and existing data can be formatted adequately

That's what I call 'validation' where you ensure the input characters & word shape are as expected. So if you enter in a 14 digit credit card number, you'll be alerted that the number is wrong (since there are not enough numbers).

But I guess 'input masking' term is more commonly used as a template, & 'validation' is when you check if that credit card is an valid data (eg postal code is real)?

Maybe an animation would help thick people like me? 😉
https://youtu.be/BMaTiGKykl8

[tomayac]

helps users enter information in forms more correctly, and existing data can be formatted adequately

That's what I call 'validation' where you ensure the input characters & word shape are as expected. So if you enter in a 14 digit credit card number, you'll be alerted that the number is wrong (since there are not enough numbers).

Oh, I see where the confusion stems from. We have been talking across each other. One thing is checking if 1234 1234 1234 1234 is a valid and existing credit card (which the example is not), and another thing is checking whether it matches the shape of the input mask, for example, 15 or 16 digits grouped as per the vendors' standards, like groups of four digits for VISA (which the example does). This proposal is definitely not about the former.

Your animation is spot on. My present thinking is that this feature should not stop you from leaving a form field mid way (like in a MM/YY input mask, if you only entered the month as 01, it would leave the current value of the input as 01/, that is, with the slash added). You would, however, have to take care of making sure that the form can't be submitted via your own logic.