This is an excerpt from Form Design Patterns. We’re in the middle of chapter 2, A Checkout Form, where we’ve been looking at the payment details form consisting of card number, expiry, security code from fields etc.

The number input (<input type="number">) lets mobile users more quickly type a number via a numeric keypad. On desktop, the input will contain increment and decrement buttons called spinners, which make it easy to make small adjustments without having to select and type.

(Note: spinner buttons are tiny and hard to use which I’ll address later. And scrolling can interfere with number inputs.)

You might think the number input is appropriate for the card number, expiry date, and CVC number — after all, they all consist of numbers. But it’s more complicated than that. By looking at what the spec says, what browsers do, and what users want, we can more easily determine when the number input is appropriate or not.

Let’s start with some definitions. Wikipedia says that:

“A number is a mathematical object used to count, measure, and label. […] numerals are often used for labels (as with telephone numbers), for ordering (as with serial numbers), and for codes (as with ISBNs).”

Most of us think of numbers this way. We use them to count and measure, but equally we use them in dates and codes. However, the HTML specification only agrees in part with this definition. It says that:

“The type=number state is not appropriate for input that happens to only consist of numbers but isn’t strictly speaking a number. […] When a spinbox interface is not appropriate, type=text is probably the right choice (possibly with a pattern attribute).”

In other words, numbers and numerals are different. Numbers represent an amount of something such as:

• my age announced “thirty-four years old”
• the price of an apple announced “forty-five pence”
• the time it took me to cook breakfast announced “ten minutes”

Conversely, numerals might be used for dates and codes such as:

• birth date announced “nineteenth of June, nineteen eighty-three”
• pin code announced “eight, double five, three, two, six”

There’s a difference between the way these values are announced. Understanding this helps us see that while the way browsers implement the number input may seem buggy at first — it isn’t.

For example, IE11 and Chrome will ignore non-numeric input such as a letter (not including e which is valid) or a slash. Some older versions of iOS will automatically convert “1000” to “1,000.” Safari 6 strips out leading zeros. Each example seems undesirable, but none of them stop users from entering true numbers.

Some numbers need a decimal point such as a price; negative numbers need a minus symbol. Unfortunately, some browsers don’t provide buttons for these symbols on the keypad. If that wasn’t enough, some desktop versions of Firefox will round up huge numbers.

In these cases, it’s safer to use a regular text box to avoid excluding users unnecessarily. Remember, users are still able to type numbers this way — it’s just that the buttons on the keypad are smaller. To further soften the blow, the numeric keyboard can be triggered for iOS users by using the pattern attribute.

<input type="text" pattern="[0-9]*">

In short, only use a number input if:

• incrementing and decrementing makes sense
• the number doesn’t have a leading zero
• the value doesn’t contain letters, slashes, minus signs, and decimal points.
• the number isn’t very large

Let’s apply these rules to the expiry date. Incrementing it doesn’t make sense, the number could start with a zero, and credit cards put a slash in the middle of the expiry date which users should be able to copy. Using a number input is not only inappropriate, but it creates a jarring experience as the user types a slash which would be ignored.

We’ll look at appropriate use cases of the number input in the next chapter.

A note about the telephone input

The telephone input (<input type="tel">) is sometimes used as a makeshift number input because…and you’ll just have to get the book to continue reading 😉.