tomayac / js-input-masking

Input Masking 🎭

Author: Thomas Steiner ([email protected], @tomayac)

Last updated: 2021-09-07

The problem

By "restricting input using preformatted input masks (telephone number, birthday, Social Security number), or even auto-correcting input by appending or removing unnecessary characters" [cf. Klimczak], input masking helps users enter information in forms more correctly, and existing data can be formatted adequately. Many implementations of input masking exist in user land, proving that there is a true need for this feature.

A beginning of a proposal

This proposal is to gauge interest in making input masking part of the language, maybe as a new interface of Intl. Here're some code snippets that show what this could look like in practice:

• Globally agreed-on input mask:

  // 16 digits.
  new Intl.InputMask("credit-card-number").format("4012888888881881");
  // "4012 8888 8888 1881"
  
  // 15 digits.
  new Intl.InputMask("credit-card-number").format("378282246310005");
  // "3782 822463 10005"

• Locale-aware input mask with customization options:

  new Intl.InputMask("phone-number", {
    locale: "de-DE",
    countryCode: "leadingPlus",
    areaCode: "leadingZero",
    groupSize: 2,
  }).format("00494012345678");
  // "[phone]"

• Fully custom input mask with a mask function:

  new Intl.InputMask("custom", {
    maskFunction: (input) => input.toLowerCase().replaceAll(" ", ""),
  }).format("No Spaces No Uppercase");
  // "nospacesnouppercase"

Polyfill

Work on a polyfill that implements this proposal has started in tomayac/js-input-masking-polyfill. You can see Intl.InputMask in action in the demo.

Isomporhic JS™

Making this part of the language would allow people to use this on the client and the server.

On the client

For example, a client-side implementation could use this as follows (note that the type="tel" of the <input> does not mean the input value is "automatically validated to a particular format before the form can be submitted, because formats for telephone numbers vary so much around the world" [cf. MDN]):

<label for="phone">Enter your phone number:</label>
<input type="tel" id="phone" name="phone" />

const formatPhoneNumber = (value) => {
  return new Intl.InputMask("phone-number", {
    locale: "de-DE",
    countryCode: "leadingPlus",
    areaCode: "leadingZero",
    groupSize: 2,
  }).format(value);
};

document.querySelector("#phone").addEventListener("input", (e) => {
  e.target.value = formatPhoneNumber(e.target.value);
});

On the server

For a server-side implementation, this could look as follows:

SELECT phone FROM users_legacy;
# Returns a mix of formats from a legacy dataset:
# 00494012345678\n+494012345678\n04012345678

const formatPhoneNumber = (value) => {
  return new Intl.InputMask("phone-number", {
    locale: "de-DE",
    countryCode: "leadingPlus",
    areaCode: "leadingZero",
    groupSize: 2,
  }).format(value);
};

// Express.js YOLO example.
app.get("/phones", (req, res) => {
  const rawPhones = getPhoneNumbersFromLegacyDB();
  const formattedPhonesHTML = rawPhones
    .map((rawPhone) => {
      return formatPhoneNumber(rawPhone);
    })
    .join("<br>");
  res.send(formattedPhonesHTML);
});

Alternatives

Just leaving this to the user land is an obvious alternative. The ecosystem of input masking libraries is alive, and great implementations exist. Pulling any of those in comes at a cost for each locale that's needed though, and the weight of the particular input masking library itself.

Another alternative would be to add new (and smarter) input types. A recent example is the input[type=currency] proposal. The declarative burden for advanced formatting needs is not to be underestimated, though (see the above countryCode and areaCode examples). This also does not solve the issue on the server side.

Feedback

Feedback on this early-stage idea is welcome. Please open a new Issue.

Acknowledgements

I'm thankful for the contributions from:

• @charmander
• @tomByrer
• @hemanth

js-input-masking's Issues

maybe focus only on masking?

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