HTML - Forms and Tables Part 1
Instructors: Jess, Carmen, and Eda
Forms and Tables
Before this session, please:
- Read Working with Forms: How Do Forms, Labels, and Inputs Work in HTML? and take notes
- Read Working with Forms: What Are the Different Types of Buttons, and When Should You Use Them? and take notes
- Read Working with Forms: What Is Client-Side Form Validation in HTML Forms, and What Are Some Examples? and take notes
- Read Working with Forms: What Are the Different Form States, and Why Are They Important? and take notes
- Try and complete as many steps as you can from Build a Hotel Feedback Form recording questions and new concepts introducted
During this session, we’ll:
- Review notes
- Review notes
- Review notes
- Review notes
- We’ll work through key steps from Build a Hotel Feedback Form together to help support your understanding of forms. Please make sure to complete this solo.
After this session, please:
- Read Working with Tables: What Are HTML Tables Used For, and What Should They Not Be Used For? and take notes
- Complete all steps from Build a Final Exams Table, recording any questions or new concepts introduced
- Please complete Build a Book Catalog Table over the next few days
Jess’ Notes
Working with Forms: How Do Forms, Labels, and Inputs Work in HTML?
Form elements: are HTML elements that capture data your users give you. The little quiz at the end of our theory readings are form elements! This data can be text, email addresses (which are text, but we treat them a little differently or various types of multiple choice. When we build a form element, we chose what type of data users can send us by nesting input elements with different type attributes in our form.
Action attribute: is used to set the URL the form data should be sent to and needs to be paired with a method attribute to set how the form data should be processed. But Jess! Wait! Where do I get this URL for my website? We’ll talk about this when we look at the workshop, but a lot of aspects of this will be out of scope for this bootcamp.
Input elements: these elements sit inside our form element and will let us collect different types of information by setting the type attribute. These are void elements, so we don’t need a closing tag. If you don’t set a type attribute the default is a text element. Setting a unique ID for each of our input elements allows us to semantically link them to labels
Label elements: Add context, telling your users what this input element is asking for. We can add a for attribute and pass in the ID related to this input element to add extra context that enables better accessibility
Placeholder attribute: can be added to your input element if you want to include example or placeholder text to show your users
Working with Forms: What Are the Different Types of Buttons, and When Should You Use Them?
We use buttons when we want to offer users a way to trigger an action on your website. A “send” button on your web email client is a good example. When your user presses this button it will send the email that they’ve drafted. One way we can create buttons is by using the button element.
We’re going to ignore the JavaScript example for now, because we’re not going to worry about JavaScript in this course.
By default, button elements won’t do anything unless you set a type attribute that enables them to perform a type of action.
As we work with forms, we’ll want to focus on exploring the type attribute being set to submit, which will allow your users to submit the information they’ve put into your form.
Button creation without creating button elements: We can also create a button by creating an input element which has the type attribute set to submit, reset or button
Let’s look at the example in the interactive editor together.
Working with Forms: What Is Client-Side Form Validation in HTML Forms, and What Are Some Examples?
In order for this to make sense, we need to talk a little bit about servers before we talk about client side and server side actions.
Servers are computers that users or other computers can connect to. Servers store and manage access to data (like the HTML files that make up a website that users view in their browser) or services. They serve access to these for their clients: the users or other computers who request access.
I like to think of servers as the waiters of the internet. And we can think of our users computers or browsers as their customers, the clients. They are just waiting for a client to make a permitted request for one of their resources and then they bring the requested cake (really, data) right to them.
Remember that anything client side happens on your user’s computer or browser. It’s over by them, on their side!
Any server side actions are happening on the server that hosts the data, services or resources. It’s on the server’s side of the action!
Validation is the process of checking that data or an action is valid. For example, when you use a password to log into a service, you’re validating that you should be allowed to use the service.
Form validation is done on the client side. What do you think this means and where is this action being processed?
Required attributes and email format validation are two examples of client side validation being done with forms. You can further set minimum or maximum lengths for input in your form.
- Why might setting a maximum input for a form question like “what is your favorite color?” be a good idea?
- Why might setting a minimum (of maximum) length for a form question asking someone’s name be a bad idea?
Working with Forms: What Are the Different Form States, and Why Are They Important?
Because users can interact with form inputs, we need different states to be possible for inputs.
If we don’t add a state to our input element, the default state is applied. This means that the user’s focus isn’t directed to the form, the input can be written to by the user and the input element hasn’t been disabled for the user.
In the focused state the user’s input device has engaged with the input element. The user can now write their data in a text type input element or select the desired data for other types of input types.
Input elements with the disabled state set cannot be put into the focused state and users can’t write data into this input element.
Input elements with the readonly state set can be put into a focused state but users cannot add input into this element.
Build a Hotel Feedback Form
All of the form concepts we’ve looked at so far feel very abstract. Let’s walk through some of the steps of building a form together. We’ll skip ahead to step 3 to where we start building our form
Method attribute: We talked a little before about the HTTP protocol, one standardized way that data is handled on the web. The method attribute can be used to set one of four HTTP methods you can use to send your form. These could include post (send the form data to the specified URL), get or dialog. We’ll just focus on get for now, but you can read more about HTTP or the method attribute on MDN
Action attribute: Ok, if we’re using the post method to send our data somewhere, where is that data going to go? We’re learning to set this attribute to a pre-supplied URL, but in a real world context you might want to send the data to a database or process it using a script. These are both server-side actions that require a level of backend knowledge we aren’t going cover in this bootcamp. You can preview some of the concepts and skills in the MDN tutorials on sending form data.
Fieldset elements: allows us to semantically group input options together with the labels that apply to them. Let’s look at the MDN documentation for fieldset elements, partially because it uses a cryptids example!