This post breaks down the HTML form input element, explains how they works, and shows you how to best apply them in various use cases. Get a complete run-down of the HTML form input element in this comprehensive tutorial.
According to the MDN Web Docs, the HTML <form> element represents a document section containing interactive controls for submitting information. Whenever we, as web developers, require information from our users, we present them with a <form> element.
On a high-level, it could be the commonplace login form with the user’s email address and password, or a security enhanced two-factor authentication (2FA) form to double check sensitive operations. Either way, forms represent a contractual interface between our requirements and the user’s possessions.
The basic building blocks of the <form> element are its controls. These controls range from basic interactive elements like the <input>, to structural elements like the <fieldset> used to group several other controls. Others include controls like <button> for performing a click action, and <label> for describing other controls.
Of all the controls, the input is perhaps the most variant and most used. Or as documented on MDN, it is one of the most powerful and complex in all of HTML elements due to the sheer number of combinations of input types and attributes.
A short note about the complexities of the <input> element
To understand the true complexity behind <input>s is to step back to understand the primary purpose of web forms: to get information from the user, but more importantly, to foster interaction between users and websites, and even more fundamentally between Human and Computer. This kind of interaction is sufficiently complicated and complex enough to have given rise to the multidisciplinary field of Human-Computer Interaction (HCI).
The crux here is that when a user interacts with a website, they are basically performing one of the basic CRUD (Create, Read, Update, Delete operations Query, Mutation, and Subscription in GraphQL. And when we present the user with a form, we are basically interacting with them through a “dialogue system”.
When speaking of HCI in relation to web forms, we are often led down the road of usability and security. We often do not need to augment the default form elements as many websites do, neither do we need to manually enhance validation, but attempting to provide a generic API will not serve the best, specific, and secure needs of everyone.
As you work through this dialogue system, you’ll notice that the type of data you are trying to get from the user depends on what type of <input> you use, and as you’ll learn, data type and input type are sometimes mutually exclusive.
Nevertheless, the flexibility of <inputs>s still shine above other form controls. For most every interaction, there’s often an <input> that can get you the type of data you want from the user. It also has some sensible defaults that you do not have to re-wire, like the password input where the user input is already obscured. And there are times when you need to extend the functionality of certain inputs to do just as you want them to.
The flexibility of the <input> control makes it powerful but also makes it complex, and when coupled with the fact that it is one of the controls used to achieve the goal of a web form, you can expect a plethora of ways to do it right and wrong.
<input> types
Similar to every other HTML element, the <input> element has a number of attributes that can be used to configure it to a particular need. Of all the available attributes, the type attribute is the most important because it gives an <input> its identity. When not explicitly specified or when not supported, or when a non-existing type is specified, the type defaults to text. That is, <input> or <input type="undefined"> is technically equivalent to <input type="text">
Technically, all inputs share the HTMLInputElement interface and, by extension, have the same exact set of attributes.
However, these attributes are functionally dependent on the type of the input they’re used with. For example, both the text and checkbox input have the autocomplete attribute, but while it works on a text input, it is ignored on a checkbox.
Also, an <input>’s functionality, design, and availability is dependent on the device and user agent.
Take the telephone input ( <input type="tel">) for example. It displays a telephone keypad in supported devices with on-screen/virtual keypads like a phone, and has no practical advantage over the text input when used on a device without an on-screen keypad.
Speaking of virtual keypads, how you configure or customize them and the type you use can also result in differences in what you see.
Apart from the type attribute, there are other important attributes like required(indicating that the user must provide a value for that control before the form can be submitted) or theplaceholder (representing a hint describing the <input>).
But the type attribute is the most important, not just because it gives an <input> its identity, or because they contribute to that sheer number of combinations that makes <input>s complex, but also because of the functional dependence attributes have on them.
#html #web-development #programming #developer
