DEV Community: Daniel Gropp

Useful HTML input attributes

Daniel Gropp — Thu, 03 Feb 2022 12:31:23 +0000

Forms are an integral part in many web apps - registering a new user, logging into an existing one, collecting payment methods, subscribing to newsletters, and much more.
On both mobile and desktop, we'd like to help the user fill these forms in the easiest and most intuitive manner as possible. On desktop it's mostly by setting the type and autocomplete attributes correctly, as we're using an actual keyboard. On mobile it's even more crucial, as the keyboard is virtual and the screen is smaller.
Let's create an initial form, that collects the user's details and payment method.

<form>
  <h2>Details</h2>
  <input name="first_name">
  <input name="last_name">
  <input name="phone">
  <input name="email">
  <h2>Address</h2>
  <input name="street">
  <input name="city">
  <input name="postal_code">
  <input name="country">
  <h2>Payment Method</h2>
  <input name="cardholder_id">
  <input name="credit_card_number">
  <input name="exp_month">
  <input name="exp_year">
  <input name="ccv">
  <button type="submit">Submit</button>
</form>

Typing
As some of you may have noticed, the inputs above are not typed. This means, that by default they are of type="text". Now, typing an input can be a bit tricky. Once we change the type of the input we get a few things: We get autocomplete suggestions, a validation that checks if the value is suitable to its type, and an appropriate virtual keyboard on mobile devices.
For instance, if we'd use type="email", it would suggest us emails that are stored in our browser, it would check if we enter a valid email address and it would show a virtual keyboard with @, ., and sometimes .com (depends on the device).
If we'd use type="tel" we would get a numbers only keypad (and also #, + and * characters). Now, this can be very useful, and not only for phone numbers, but if we'd use it for a postal code or credit card number, we'd get a phone number validation and autocomplete suggestions, which is not good.
As a rule of thumb, I would suggest to change the type of an input from the default type="text" only if the input is the type. So let's apply this rule in our form.

<form>
  <h2>Details</h2>
  <input name="first_name">
  <input name="last_name">
  <input name="phone" type="tel">
  <input name="email" type="email">
  <h2>Address</h2>
  <input name="street">
  <input name="city">
  <input name="postal_code">
  <input name="country">
  <h2>Payment Method</h2>
  <input name="cardholder_id">
  <input name="credit_card_number">
  <input name="exp_month">
  <input name="exp_year">
  <input name="ccv">
  <button type="submit">Submit</button>
</form>

Inputmode
As you can see above, I only changed the types of the phone and email inputs, but we'd still like to see a numbers only keypad for the postal code input, and all the credit card inputs.
We could use the type="number" but this type sucks in so many ways. It shows by default 2 arrows in it, that increases or decreases its values, and the virtual keyboard it shows also shows a lot of non-numeric characters.
For this scenario we can use the inputmode attribute. This is an extremely useful attribute, as it tells our mobile device which virtual keyboard to open. One of its more useful values is inputmode="numeric", which opens a numbers only (no # and *) keyboard. There are other useful values, check them out here. Now, we can use this attribute on the appropriate inputs.

<form>
  <h2>Details</h2>
  <input name="first_name">
  <input name="last_name">
  <input name="phone" type="tel">
  <input name="email" type="email">
  <h2>Address</h2>
  <input name="street">
  <input name="city">
  <input name="postal_code" inputmode="numeric">
  <input name="country">
  <h2>Payment Method</h2>
  <input name="cardholder_id" inputmode="numeric">
  <input name="credit_card_number" inputmode="numeric">
  <input name="exp_month" inputmode="numeric">
  <input name="exp_year" inputmode="numeric">
  <input name="ccv" inputmode="numeric">
  <button type="submit">Submit</button>
</form>

Autocomplete
Now we show the most appropriate virtual keyboard to all our inputs. But what about helping the users use their stored details. For that we have the autocomplete attribute. This is an insanely useful one (especially for the user) if we use it correctly. Note that for already typed inputs, like tel and email, we don't need to set autocomplete values, as their type already uses it.
There are many values to the autocomplete attribute, and chances are we could find a suitable one to all our inputs. Once we assign the correct values, if our users have stored data in their browser, it could take them a few seconds to fill out this form. Also, if we have stored credit cards in our browser it would fill them out automatically as well.
Some fields, like cardholder id, are better left out of the autocomplete fields for security reasons. This can be easily set, by setting this field with autocomplete="off".

<form>
  <h2>Details</h2>
  <input name="first_name" autocomplete="given-name">
  <input name="last_name" autocomplete="family-name">
  <input name="phone" type="tel">
  <input name="email" type="email">
  <h2>Address</h2>
  <input name="street" autocomplete="street-address">
  <input name="city" autocomplete="address-level2">
  <input name="postal_code" inputmode="numeric" 
         autocomplete="postal-code">
  <input name="country" autocomplete="country-name">
  <h2>Payment Method</h2>
  <input name="cardholder_id" inputmode="numeric" 
         autocomplete="off">
  <input name="credit_card_number" inputmode="numeric" 
         autocomplete="cc-number">
  <input name="exp_month" inputmode="numeric" 
         autocomplete="cc-exp-month">
  <input name="exp_year" inputmode="numeric" 
         autocomplete="cc-exp-year">
  <input name="ccv" inputmode="numeric" 
         autocomplete="cc-csc">
  <button type="submit">Submit</button>
</form>

Auto-capitalize and Auto-correct
The autocapitalize and autocorrect attributes are mobile-only attributes (autocorrect is only for iOS). The autocapitalize attribute can show us a CAPS only virtual keyboard, or only for each first letter. The autocorrect attribute can enable or disable the iOS auto-correct for this input.
These can be quite useful for name and address inputs, as their values sometimes don't match with auto-correct values.

<form>
  <h2>Details</h2>
  <input name="first_name" autocomplete="given-name"
         autocapitalize="words" autocorrect="off">
  <input name="last_name" autocomplete="family-name"
         autocapitalize="words" autocorrect="off">
  <input name="phone" type="tel">
  <input name="email" type="email">
  <h2>Address</h2>
  <input name="street" autocomplete="street-address"
         autocapitalize="words" autocorrect="off">
  <input name="city" autocomplete="address-level2"
         autocapitalize="words" autocorrect="off">
  <input name="postal_code" inputmode="numeric" 
         autocomplete="postal-code">
  <input name="country" autocomplete="country-name"
         autocapitalize="words" autocorrect="off">
  <h2>Payment Method</h2>
  <input name="cardholder_id" inputmode="numeric" 
         autocomplete="off">
  <input name="credit_card_number" inputmode="numeric"
         autocomplete="cc-number">
  <input name="exp_month" inputmode="numeric"
         autocomplete="cc-exp-month">
  <input name="exp_year" inputmode="numeric"
         autocomplete="cc-exp-year">
  <input name="ccv" inputmode="numeric" autocomplete="cc-csc">
  <button type="submit">Submit</button>
</form>

Check out a demo for this article on CodePen.

Conclusion
As users, forms can be a pain. As developers we can make the users lives a bit easier by providing them with all the tools to fill these forms as quickly as possible by using the correct input attributes.
Do you think of any other attributes that can assist users with tedious forms?

for ... of operator and Symbol.iterator

Daniel Gropp — Sun, 16 Jan 2022 09:34:24 +0000

JavaScript's for ... of operator loops over iterable objects. This type of loop exists in many programming languages.

// JavaScript
for (const user of users) {
  /* do something */
}

// Java
for (User user : users) {
  /* do something */
}

// PHP
foreach ($users as $user) {
  /* do something */
}

# Python
for user in users:
  # do something

In JavaScript we also have the for ... in operator that loops over an object's enumerable properties, which means its keys.

const john = {name: "John Lennon", age: 40, isAlive: false};
const beatles = ["John", "Paul", "George", "Ringo"];

for (const key in john) {
  console.log(key); // "name", "age", "isAlive"
}
for (const key in beatles) {
  console.log(key); // 0, 1, 2, 3
}

JavaScript arrays are basically special objects with indices as keys. We can imagine that a very simple implementation of a JavaScript array will look like this:

const arrayObject = {
  0: "John", 
  1:  "Paul", 
  2:  "George", 
  3: "Ringo", 
  length: 4
}

that's why the for ... in operator will loop over its indices.
Using a for ... of operator on an array will loop over its entries.

for (const beatle of beatles) {
  console.log(beatle); // "John", "Paul", "George", "Ringo"
}

But using the same operator on a plain object will throw an error.

for (const value of john) {
  console.log(value); // Uncaught TypeError: john is not iterable
}

Our simple array implementation, will work using a regular for loop, but will throw the same error when using the for ... of operator.

for (let i = 0; i < arrayObject.length; i++) {
  console.log(arrayObject[i]); // "John", "Paul", "George", "Ringo"
}
for (const beatle of arrayObject) {
  console.log(beatle); 
  // Uncaught TypeError: arrayObject is not iterable
}

JavaScript arrays (and for that matter also Set, Map, NodeList, etc.) are basically objects, So why on earth does a for ... of work on an array and not on plain objects?
The reason is a property called Symbol.iterator, which accepts a Generator function that allows for any object to be iterated with a for ... of loop and accept the spread syntax.
Array.prototype and other iterable interfaces, have that property defined,

Array.prototype[Symbol.iterator]; // ƒ values() { [native code] }
Set.prototype[Symbol.iterator]; // ƒ values() { [native code] }
Map.prototype[Symbol.iterator]; // ƒ entries() { [native code] }
NodeList.prototype[Symbol.iterator]; // ƒ values() { [native code] }

while other objects don't.

Object.prototype[Symbol.iterator]; // undefined
Date.prototype[Symbol.iterator]; // undefined

So, if for some reason we'd really like to use a for ... of loop on an object, we could define it a Symbol.iterator method. (Note that it's currently impossible to use arrow functions for a generator function).

john[Symbol.iterator] = function* () {
  for (const key in john) {
    yield john[key];
  }
}

Now we can use a for ... of loop on that object, and even use the spread syntax.

for (const value of john) {
  console.log(value); // "John Lennon", 40, false
}

const values = [...john]; // ["John Lennon", 40, false]

But, setting a Symbol.iterator property to every object instance is overtly complicated and unnecessary. Instead, we can add it to Object.prototype.

Object.prototype[Symbol.iterator] = function* () {
  for (const key in this) {
    yield this[key];
  }
}

And while this works like a charm, adding methods to built-in prototypes is discouraged. Think of the confusion it can cause with people unfamiliar with your code, and of future errors it could cause, read more about this here.
To iterate over the values of an object, we'd better use the Object.prototype static method Object.values, and then we could easily use a for ... of loop, or any Array.prototype methods.

for (const value of Object.values(john)) {
  console.log(value); // "John Lennon", 40, false
}

So when should we define a Symbol.iterator method? For instance when we implement our own data structure, and we'd like it to be iterable. Check out my linked list implementation on GitHub

class LinkedList {

  /* Class implementation */

  [Symbol.iterator]() {
    return function* () {
      let node = this.head;
      while (node !== null) {
        yield node.value;
        node = node.next;
      }
    }
  }
}

Also, we can create a class that handle array-like objects, that will add the ability to use for ... of loops. That way we could use the object as is without using Object.prototype static methods and without polluting Object.prototype.

class IterableObject {
  constructor(obj) {
    Object.assign(this, obj);
  }

  * [Symbol.iterator]() {
    for (const key in this) {
      yield this[key];
    }
  }
}

const beatles = new IterableObject({
  john: {name: "John Lennon", age: 40, isAlive: false},
  paul: {name: "Paul McCartney", age: 79, isAlive: undefined},
  george: {name: "George Harrison", age: 58, isAlive: false},
  ringo: {name: "Ringo Starr", age: 81, isAlive: true}
});

Now we can use a for ... of loop and run queries and tests on it using the spread syntax.

for (const beatle of beatles) {
  console.log(beatle.name);
  // "John Lennon", "Paul McCartney", "George Harrison", "Ringo Starr"
}

[...beatles].filter((beatle) => beatle.isAlive).length; // 1

One thing to keep in mind about for ... of operator and Symbol.iterator, is that according to caniuse.com, while widely supported in 95% of browsers, they are not supported in (you guessed it) Internet Explorer. If you care about IE (and I think you shouldn't) you should avoid using this operator, as there's no polyfill - you can't polyfill syntax...