Forms
Last updated
Last updated
Table of Contents
Q: What is a form and why is a form useful?
A form is a collection of inputs that can be filled out by a user to submit a collection of data.
Q: What kinds of data might we collect in a form?
Q:When should we use a form? For all user input?
Click a button to pop open a tab with more data - use a button
, not a form
A text input that filters the list of data shown - use an input
, but not a full form
A link that takes the user to a new location - use an anchor
or a button
, not a form
Registering a new user with a name, password, and user details - use a form
!
Forms are made up of a few parts:
<form>
: the container for the form
h2 (or other header)
: A heading to describe your form
<label>
: A label for each input
<input>
: A place for the user to enter some data. There are many types (text, radio, checkbox, etc...)
<button>
: A button to submit the form
Below is a full example! For now, just focus on the Elements that are in the example (form
, h2
, label
, input
, button
)
There are a lot of attributes to learn, particularly for label
and input
. We'll go over them but here are the essential new ones that we'll cover:
form
Elements have an aria-label
for accessibility
input
Elements have a type
attribute to determine the kind of input (text, number, color, etc...)
input
Elements have a name
attribute which will be used to extract data from the form
input
Elements MUST have an id
attribute
label
Elements MUST have a for
attribute equal to the input
Element's id
. This connects them.
Inputs are where users can input their data. Each input
Element has a type — the basic inputs are "text"
or "number"
but there are many more cool ones.
Here is an example (note we're missing label
s!)
💡 Best Practice: Use
kabob-case
forid
andcamelCase
forname
(we'll learn why in a moment)
Some other types of inputs Elements (other than the literal input
tag) are the select
and textarea
(and technically buttons
).
Inputs must have a name
attribute. We'll use those later when we are getting data from the form when it is submitted.
Right now, our form is just a bunch of inputs. But how does the user know which input is for which value? Well, for one, we could add a header:
But that only helps our seeing users! When designing websites, we must design for ALL of our users.
Labels are crucial for our non-seeing users and accessibility. They tell screen readers what the purpose of an element is. There are two kinds of labels that we'll use:
The aria-label
/aria-labelledby
attribute — describes the purpose of a form
(or really of any element).
The <label>
element — describes the purpose of an <input>
element.
A few notes about aria-lablledby
Accessible Rich Internet Applications (ARIA) is a set of roles and attributes that define ways to make web content and web applications more accessible to people with disabilities.
We added an id
to the h2
element
We added the aria-lablledby
attribute to the form
element so that screen readers know to use the h2
element text as the aria label.
Here are a few notes about the <label>
element:
Connect the <label>
to the <input>
with the for
attribute. It should be the same as the input's id
:
Labels make it so that clicking a label will focus the input or check the checkbox.
Labels help our seeing users too by describing the input!
Notice that we also wrap each label
+ input
pair inside of a div
. This isn't necessary but it makes styling each pair of elements a lot easier.
All forms should end with a submit button.
By default button
elements have a type="submit"
so you don't need to put it. But you can if you want! There are other types of buttons we'll discuss later.
Clicking the submit button (or pressing enter while focused inside a form) will fire the 'submit'
event on the form.
Our objective is to...
listen for this 'submit'
event
create an event handler that extracts the user input data
do something with that data! (save it in a database, show it in the UI, etc...)
But first...
Originally (and still with some frameworks) form submissions actually change the page.
See this difference by filling out the form in 1/old-form/original-way.html
which redirects the user to the new page after submitting.
Q: See how the URL changes to results-page.html
? Notice the stuff appended to the end?
Old forms used a few attributes to achieve this behavior:
action
= the new page to go to
method
= "get"
or "post"
("get"
is default). "get"
means we are requesting data using the form, "post"
means we are sending data to be stored by the application
The form data becomes “query params” in the URL of the new page if you use "get"
This is the “default” behavior of the forms, which is NOT what we want.
Instead of having the browser take us away from the page, most modern web applications are "single-page-applications" meaning they operate on a single HTML page that dynamically handles all DOM interactions through JavaScript.
To handle a form submission while staying on the same page, we will need to:
prevent the default behavior
collect the form data
utilize the form data in some way (maybe render it to the screen, or send it to an API)
reset the form
If these are our inputs:
Then, we can handle this form on the same page like so:
event.preventDefault()
stops the form submission from redirecting/reloading the page
The event.target
value will point to the form
element
Using the form
element, we can access each input
using the name
attribute
We can access the value of most input
elements using the .value
property but checkboxes use the .checked
property.
form.reset()
empties out the form!
Another, potentially faster, way to get the values of a form is to use the FormData
API. It starts off the same, we have to grab the form
using event.target
:
Let's break this down:
We again store the form
using event.target
We invoke the function new FormData()
with that form
as an argument
We immediately take the returned value and pass it to Object.fromEntries()
which generates an Object with our form values!
When using checkboxes, you would think they'd use a true
/false
setup, but nope! They use "on"
and undefined
.
So you'll need to do a little extra work to get them to be true
/false
:
By converting the formValues.isHungry
property into a Boolean, it will be true
if the value is "on"
or false
if the value is undefined
.
After you submit, sometimes you want to clear the form, so you can do that with form.reset()
in the js, or on the form html itself, add a button with a type of reset
On the index.html
go over the basic text inputs, but then also radio groups (with fieldsets and legends), and the select. Point out when to use them:
<input type="text">
: any open ended but short data
<input type="number">
: any number, min and max can lock you in (not featured on form, just mention)
<input type="radio">
: when you want to pick one of a few options
<textarea>
: any open ended but long data
<select>
and <option>
: when you want to pick one of a lot of options
You can use an input
event on an input (or fieldset) to track the changes at a more granular level:
If you specify a type of button
on a button, it will not trigger a submit automatically. This is a pretty rare occurrence, but it's good to know!
HTML:
JS: