Forms I

Forms in HTML are used to collect user input (and submit it). Interactivity is a huge part of webpages and the internet, which is why we’ll spend several chapters on this topic.

For example, when you log into a website, you probably go through a form.

• A text field for your username
• A text field for your password
• A button to submit this information and login

Your email client also uses forms. (Text fields for the subject, recipient and content, then a button to submit.) They’re everywhere! In many shapes and sizes!

Always remember, though, that HTML is merely a markup language. It defines which elements go into the page; which input the page wants to collect. Actually doing something with that input, is the responsibility of another language (like JavaScript).

For that reason, learning about forms might feel a bit boring for now. I promise to keep it short and practical!

The form element

To create a form, use the <form> element.

This is not just great for semantics, it also tells browsers to activate a few bonus features.

Such as …

• Asking the user if they want to save the username + password they just entered
• Allowing users to navigate the form with keyboard controls
• The form acts as a container. When you click a submit button inside the form, it will automatically submit all data inside the form! (No need to collect or group them manually.)
• The form still works, even if the user has an older browser or has disabled many other features. (That’s why many websites still use this form element, instead of doing everything through JavaScript.)
• Clicking on a label will automatically focus on the interactive element associated with it.
• And more.

Below is an image that displays the general lifecycle of a loop. Further explanation of all the details appears below it.

The general structure

As always, HTML wants to add structure. It wants to subdivide the form into smaller and smaller parts. These are …

• <fieldset> for a group of related inputs
• <legend> to provide a title for a fieldset
• Pairs of input elements and a title/name for such element.
• And finally, a submit button. (There’s no point collecting data if there’s no way to use it afterward!)

As such, the general structure will be something like this.

Input pairs

As stated, input should always come in pairs.

• A <label> that contains a description for the input.
• The actual input element.

How are these connected?

• The label needs a for="someid" attribute.
• And the input element needs an id="someid" attribute.

They are connected through the id you give it. This also means the label doesn’t have to be close to the input element, although it usually is. (It just makes more sense.)

See the example for a barebones login screen, which contains two of such “pairs”.

An alternative is to add the input inside the <label>. In that case, you don’t need the for and id attributes. I don’t like this, however, as it makes no semantic sense: you created a label element … and the content is actually a label and some other input element? That’s confusing.

Submit button

Next chapters will tell you about all the things that the <input> element can do. For now, you will only learn one: how to create a submit button with it.

To do so, create an <input> element, and set its type attribute to submit.

The input element is a void element. To set the text on the submit button, set the value attribute. (If left out, the browser automatically translates the word “submit” to the user’s language. Try it!)

If you click the button … it will probably do nothing, or give an error. Why?

Because we haven’t told the form where to go or what to do.

Actually submitting

As said, HTML is not meant for doing stuff. All it has to do is hand the data over to something else—another page or another script.

To set this other page, use the action attribute. It takes any URL. (Even another website, if you know how to send information to it.)

At the other page, the submitted form data will be available.

But how? In what format?

Unfortunately, currently, we need a second attribute to deal with this: name. (In the future, I imagine this isn’t needed anymore, and it will take the id by default.)

Give each input element a name. Now the submitted data will be a list of those pairs we created!

• The name of each pair comes from that attribute
• The value of each pair is whatever value your input element had when submitted

Only data from within its own <form> element is submitted. If another form also had an input named usn, for example, it wouldn’t matter.

Generally, don’t use the same name for multiple form elements. In the upcoming chapters, however, you’ll learn about some rare elements that require you to use the same name multiple times.

GET vs POST

The details of this process aren’t important now. Just know that there are two ways to pass form information: get or post. You can set your method using the method attribute.

• GET = puts the data into the url. This makes it faster and easier to use, but also makes the data public. Do not use for sensitive information.
• POST = hides the data behind the scenes. Slower and harder to access, but suited for sensitive information

The example below creates a form that hands its data to Google for a search! If you check the URL, you’ll see the data is added to the end (?q=yoursearchterm), because we used the GET method.