With the basics out of the way, we’ll now look in more detail at the elements used to provide structure and meaning to the different parts of a form. The flexibility of forms makes them one of the most complex structures in HTML; you can build any kind of basic form using dedicated form elements and attributes. Using correct structure when building an HTML form will help you to ensure that the form is both usable and accessible.
The <form> element
As explained previously, the <form> element formally defines a form and attributes that determine the form’s behaviour. Each time you want to create an HTML form, you must start it by using this element, nesting all the contents inside. Now let’s move forward and cover the structural elements you’ll find nested in a form.
The <fieldset> and <legend> elements
The <fieldset> element is a convenient way to create groups of widgets that share the same purpose, for styling and semantic purposes. You can label a <fieldset> by including a <legend> element just below the opening <fieldset> tag. The text content of the <legend> formally describes the purpose of the <fieldset> it is included inside.
For maximum usability/accessibility, you are advised to surround each list of related items in a <fieldset>, with a <legend> providing an overall description of the list. Each individual pair of <label>/<input> elements should be contained in its own list item (or similar). The associated <label> is generally placed immediately after the radio button or checkbox, with the instructions for the group of radio button or checkboxes generally being the content of the <legend>. See the examples in the previous unit for structural examples.
Many assistive technologies will use the <legend> element as if it is a part of the label of each control inside the corresponding <fieldset> element. For example, some screen readers such as Jaws and NVDA will speak the legend’s content before speaking the label of each control.
When reading the above form, a screen reader will speak “Fruit juice size small” for the first widget, “Fruit juice size medium” for the second, and “Fruit juice size large” for the third.
The use case in this example is one of the most important. Each time you have a set of radio buttons, you should nest them inside a <fieldset> element. There are other use cases, and in general the <fieldset> element can also be used to section a form. Ideally, long forms should be spread across multiple pages, but if a form is getting long and must be on a single page, putting the different related sections inside different fieldsets improves usability.
Proposed exercise: Drink and hamburger
Using the code of the previous example, create a web page to choose the size of both a drink and a hamburger, each one inside a different <fieldset> with the corresponding <legend>. Also, as done before, the user should be able to choose among three different sizes: small, medium and large:
A form with sections
Beyond the structures specific to web forms, it’s good to remember that form markup is just HTML. This means that you can use all the power of HTML to structure a web form. As you can see in the examples, it’s common practice to wrap a label and its widget with a <p> element within. Lists are also recommended for structuring multiple checkboxes or radio buttons.
In addition to the <fieldset> element, it’s also common practice to use HTML titles (e.g. <h1>, <h2>) and sectioning (e.g. <section>) to structure complex forms. Above all, it is up to you to find a comfortable coding style that results in accessible, usable forms. Each separate section of functionality should be contained in a separate <section> element, with <fieldset> elements to contain radio buttons.
Let’s put these ideas into practice and build a slightly more involved form — a payment form. This form will contain more control types than the previous example. Read the descriptions carefully as you follow the below instructions, and start to form an appreciation of which wrapper elements we are using to structure the form, and why.
First, we will create the form by adding the outer <form> element:
<form>
...
</form>
Inside the <form> tags, we will add a heading and paragraph to inform users how required fields are marked:
<form>
<h1>Payment form</h1>
<p>Required fields are followed by <strong>*</strong>.</p>
...
</form>
We’ll also add a simple <button> of type submit, at the bottom of the form, for submitting the form data:
<form>
<h1>Payment form</h1>
<p>Required fields are followed by <strong>*</strong>.</p>
...
<p><button type="submit">Validate the payment</button></p>
</form>
Next we’ll add a larger section of code into the form, below our previous entry. Here you’ll see that we are wrapping the contact information fields inside a distinct <section> element. Moreover, we have a set of three radio buttons, each of which we are putting in a new line. We also have two standard text <input> and their associated <label> elements, each contained inside a <p>, and a password input for entering a password:
The second <section> of our form is the payment information. We have three distinct controls along with their labels, each contained inside a <p>. The first is a drop-down menu (<select>) for selecting credit card type. The second is an <input> element of type tel, for entering a credit card number; while we could have used the number type, we don’t want the number’s spinner UI. The last one is an <input> element of type date, for entering the expiration date of the card; this one will come up with a date picker widget in supporting browsers, and fall back to a normal text input in non-supporting browsers.
Using the code of the example above, create a more sophisticated payment form. Inside the “Contact information” section, you have to add a group of radio buttons so that the user can select its status (either “Student”, “Teacher”, or “Other”), and a new text field to enter the phone number. And inside the “Payment information” section you have to add a new selection box so that the user can select the preferred payment type (either “Credit card” or “Paypal”) and a new email field to enter the Paypal account:
A real example: search engine forms
Searching for text
Let’s now create a simple form which will provide all necessary data (a simple text) to be passed to some of the most known search engines:
You will notice that when you press the submit button, the query (q parameter) is included in the url, and this way the search engine will know what to search. For example, if we are searching the word “dogs” on Google, the resulting url when submitting the form will be this one: https://www.google.es/search?q=dog.
Proposed exercise: Text search
Using the example of the form above to search information on Google, DuckDuckGo and Bing, develop a web page similar to the one below to search information on several search engines (at least five).
The only difference from one form to another is the value of the action attribute (“https://google.com/search”, “https://duckduckgo.com/”, “https://bing.com/search”, “https://www.ecosia.org/search”, “https://search.givewater.com/serp”, etc.). This address can be guessed by having a look at the url when you are using each particular search engine.
Searching for images
Now we will change the code a little bit so that the results provided by the search engines are images instead of text. In some cases we only need to change the action attribute, but sometimes we have to add some additional fields:
You will notice that when you press the submit button, those hidden fields (which are not entered by the user) are included automatically in the url so that the search engine knows that has to show images instead of text. This way, in this example we are passing two parameters: q (the search string) and tbm (to search for images). For example, if we are searching for images about dogs on Google, the resulting url when submitting the form will be this one: https://www.google.es/search?q=dog&tbm=isch.
Proposed exercise: Image search
Using the code of the previous exercise, develop a new web page to search for images on several search engines (at least five).
To search for images using Bing and Ecosia, you only have to use the right value for the action attribute (“https://bing.com/images/search”, “https://www.ecosia.org/images”). You only have to use the hidden fields for Google (tbm), DuckDuckGo (iax, ia) and giveWater (qc), as done in the example above. Both the addresses and the hidden fields can be guessed by having a look at the url when you are using each particular search engine.
Choosing between text and image search
Now let’s concentrate on Google’s search engine and let’s go one step forward to add a checkbox to give the user the option to choose between searching for text or images:
Develop a web page to search either text or images on Google and giveWater search engines. You have to provide the user with a checkbox so that can easily change from one type to another:
Filtering the results
Finally let’s concentrate again on Google’s search engine to add several controls so that the user can filter the results when searching for images. We will also add a reset button to set the default values:
As you will see, we have added many options to set different values for a parameter called “tbs” (we have guessed this parameter and all its possible values by looking at the url when searching for any information on Google). This way, in this example we are passing three parameters: q (the search string), tbm (to search for images) and tbs (to filter the results). For example, if we are searching for GIF images about dogs, the resulting url when submitting the form will be this one: https://www.google.es/search?q=dog&tbm=isch&tbs=itp:animated.
Also you will notice that inside each <select> element we are using a default option: <option selected disabled>...</option> so that by default, none of the available options are selected and the results are not filtered.
Proposed exercise: Filtering images with dropdown boxes
Using the code of the previous example, develop a web page to search for images on Google and filter the results using several dropdown boxes:
Proposed exercise: Filtering images with radio buttons
Create a new web page to search for images on Google and filter the results using radio buttons:
Quiz
Test your skills with this quiz about HTML forms and some other concepts related to this unit.
An emotional story that encourage us to overcome ourselves
We will meet a doctor who only prescribes injections and medicines. Will he cure all the patients who go through his consultation? In this emotional story we will get into the skin of a child who is afraid of punctures and who may also need a special treatment.
Bilingual
Tale available in both English and Spanish. The book also contains pictures to learn the alphabet through three sections:
Learn the alphabet
Letter … is for …
Spell it out
Other books in the series Tales to find a cure
All the tales together can also be found in a single book (both English and Spanish). However, the bilingual version includes more pictures, in both e-book and printed formats:
The doctor who didn’t believe in kissing
I will write what you say
So that the cats can eat
My lunch
The storyteller
Occupation fairies
Leave it as it is!
I can’t understand you
Grrrrrrr!!!
Leo, my best friend
The princess and the traveller
The password
VHL Alliance
All funds go to Spanish VHL Family Alliance (alianzavhl.org).
This unit provides some instructions and examples that will help you to learn the essentials of web forms. Web forms are a very powerful tool for interacting with users — most commonly they are used for collecting data from users, or allowing them to control a user interface. However, for historical and technical reasons it’s not always obvious how to use them to their full potential. In the sections listed below, we’ll cover all the essential aspects of Web forms including marking up their HTML structure, validating form data, and submitting data to the server.
What are web forms?
Web forms are one of the main points of interaction between a user and a web site or application. Forms allow users to enter data, which is generally sent to a web server for processing and storage, or used on the client side to immediately update the interface in some way (for example, add another item to a list, or show or hide a UI feature).
A web form’s HTML is made up of one or more form controls (sometimes called widgets), plus some additional elements to help structure the overall form — they are often referred to as HTML forms. The controls can be single or multi-line text fields, dropdown boxes, buttons, checkboxes, or radio buttons, and are mostly created using the <input> element, although there are some other elements to learn about too.
Form controls can also be programmed to enforce specific formats or values to be entered (form validation), and paired with text labels that describe their purpose to both sighted and blind users.
Basic native form controls
In the next sections we will mark up several functional web form examples, using some form controls and common structural elements, and focusing on accessibility best practices. Now we will look at the functionality of the different form controls, or widgets, in detail — studying all the different options available to collect different types of data. In this particular section we will look at the original set of form controls, available in all browsers since the early days of the web.
The <label> element
The <label> element is the formal way to define a label for an HTML form widget. This is the most important element if you want to build accessible forms. When implemented properly, screen readers will speak a form element’s label along with any related instructions, as well as being useful for sighted users. Take this example, where we nest the form control within the <label>, implicitly associating it:
With the <label> associated correctly with the <input> a screen reader will read out something like “Name, edit text”. If there is no label, or if the form control is neither implicitly or explicitly associated with a label, a screen reader will read out something like “Edit text blank”, which isn’t very helpful at all.
Labels are clickable, too!
Another advantage of properly setting up labels is that you can click or tap the label to activate the corresponding widget. This is useful for controls like text inputs, where you can click the label as well as the input to focus it, but it is especially useful for radio buttons and checkboxes. The hit area of such a control can be very small, so it is useful to make it as easy to activate as possible.
For example, clicking on the labels “I like cherry” or “I like banana” in the example below will toggle the selected state of the cherry or banana checkboxes respectively:
<label>
<input type="checkbox" name="cherry" value="cherry" />
I like cherry
</label><br />
<label>
<input type="checkbox" name="banana" value="banana" />
I like banana
</label><br />
Text input fields
Text <input> fields are the most basic form widgets. They are a very convenient way to let the user enter any kind of data because they can take many different forms depending on its type attribute value. It is used for creating most types of form widgets including single line text fields, time and date controls, controls without text input like checkboxes, radio buttons, and color pickers, and buttons too.
All basic text controls share some common behaviors:
They can be marked as required, to specify that a form field needs to be filled in before the form can be submitted.
They can be marked as readonly (the user cannot modify the input value but it is still sent with the rest of the form data) or disabled (the input value can’t be modified and is never sent with the rest of the form data).
They can have a placeholder. This is text that appears inside the text input box that should be used to briefly describe the purpose of the box.
They can be constrained in size (the physical size of the box) and minlength and maxlength (the minimum and maximum number of characters that can be entered into the box).
They can benefit from spell checking (using the spellcheck attribute), if the browser supports it.
Keep in mind that HTML form text fields are simple plain text input controls. This means that you cannot use them to perform rich editing (bold, italic, etc.). All rich text editors you’ll encounter are custom widgets created with HTML, CSS, and JavaScript.
Single line text fields
A single line text field is created using an <input> element whose type attribute value is set to text, or by omitting the type attribute altogether (text is the default value). The value text for this attribute is also the fallback value if the value you specify for the type attribute is unknown by the browser (for example if you specify type="color" and the browser doesn’t support native color pickers).
Let’s see this example using a couple of single line text fields:
<label>
Name (5 to 10 characters):
<input type="text" name="name" required
minlength="5" maxlength="10" size="15"
placeholder="e.g. Fernando">
</label><br />
<label>
Comment:
<input type="text" name="comment" required
placeholder="e.g. I like this example">
</label><br />
HTML5 enhanced the basic original single line text field by adding special values for the type attribute that enforce specific validation constraints and other features, for example specific to entering emails, URLs or numbers. We’ll cover those in a section below (The HTML5 input types).
Password field
One of the original input types was the password text field type:
The password value doesn’t add any special constraints to the entered text, but it does obscure the value entered into the field (e.g. with dots or asterisks) so it can’t be easily read by others.
Keep in mind this is just a user interface feature; unless you submit your form securely, it will be sent in plain text, which is bad for security — a malicious party could intercept your data and steal passwords, credit card details, or whatever else you’ve submitted. The best way to protect users from this is to host any pages involving forms over a secure connection (i.e. at an https://... address), so the data is encrypted before it is sent.
Browsers recognize the security implications of sending form data over an insecure connection, and have warnings to deter users from using insecure forms. For more information on what Firefox implements, see Insecure passwords.
Multiple line text fields
The HTML <textarea> element represents a multi-line plain-text editing control, useful when you want to allow users to enter a sizeable amount of free-form text, for example a comment on a review or feedback form:
<label>Tell us your story:
<textarea name="story" rows="5">
It was a dark and stormy night...
</textarea>
</label>
You can use the rows and cols attributes to specify an exact size for the <textarea> to take. Setting these sometimes is a good idea for consistency, as browser defaults can differ. We also are using a default content (entered between the opening and closing tags), since <textarea> does not support the value attribute.
The <textarea> element also accepts several attributes common to form <input> element, such as autocomplete, autofocus, disabled, placeholder, readonly, and required.
Default values in text fields
Notice that the <input> tag is an empty element, meaning that it doesn’t need a closing tag. The <textarea> element however must be closed with the proper ending tag. This has an impact on a specific feature of forms: the way you define the default value. To define the default value of an <input> element you have to use the value attribute like this:
<input type="text" value="by default this element is filled with this text">
On the other hand, if you want to define a default value for a <textarea>, you put it between the opening and closing tags of the <textarea> element, like this:
<textarea>
by default this element is filled with this text
</textarea>
Checkable items: checkboxes and radio buttons
Checkable items are controls whose state can be changed by clicking on them or their associated labels. There are two kinds of checkable item: the check box and the radio button. Both use the checked attribute to indicate whether the widget is checked by default or not.
It’s worth noting that these widgets do not behave exactly like other form widgets. For most form widgets, once the form is submitted all widgets that have a name attribute are sent, even if no value has been filled out. In the case of checkable items, their values are sent only if they are checked. If they are not checked, nothing is sent, not even their name. If they are checked but have no value, the name is sent with a value of on.
Checkbox
A check box is created using the <input> element with a type attribute set to the value checkbox. Elements of type checkbox are rendered by default as boxes that are checked (ticked) when activated, like you might see in an official government paper form. The exact appearance depends upon the operating system configuration under which the browser is running. Generally this is a square but it may have rounded corners. A checkbox allows you to select single values for submission in a form (or not).
Let’s see and try a very simple example:
<label>
<input type="checkbox" name="carrots" value="carrots" checked />
Do you like carrots?
</label>
Including the checked attribute makes the checkbox checked automatically when the page loads. Clicking the checkbox or its associated label toggles the checkbox on and off.
Due to the on-off nature of checkboxes, the checkbox is considered a toggle button. Many developers and designers are expanding the default checkbox styling to create buttons that look like toggle switches.
Radio button
A radio button is created using the <input> element with its type attribute set to the value radio. Elements of type radio are generally used in radio groups (collections of radio buttons describing a set of related options). Only one radio button in a given group can be selected at the same time. Radio buttons are typically rendered as small circles, which are filled or highlighted when selected.
Let’s see a simple example containing several radio buttons and how a browser may render it:
As seen above, several radio buttons can be tied together. If they share the same value for their name attribute, they will be considered to be in the same group of buttons. Only one button in a given group may be checked at a time; this means that when one of them is checked all the others automatically get unchecked. When the form is sent, only the value of the checked radio button is sent. If none of them are checked, the whole pool of radio buttons is considered to be in an unknown state and no value is sent with the form. Once one of the radio buttons in a same-named group of buttons is checked, it is not possible for the user to uncheck all of the buttons without resetting the form.
The <select> element
The HTML <select> element represents a control that provides a menu of options. For example:
<label>Choose the pet you most like:
<select name="pets" id="pet-select">
<option value="">--Please choose an option--</option>
<option value="dog">Dog</option>
<option value="cat">Cat</option>
<option value="hamster">Hamster</option>
<option value="parrot">Parrot</option>
<option value="spider">Spider</option>
<option value="goldfish">Goldfish</option>
</select>
</label>
The above example shows typical <select> usage. It is associated with a <label> for accessibility purposes, as well as a name attribute to represent the name of the associated data submitted to the server. Each menu option is defined by an <option> element nested inside the <select>.
Each <option> element should have a value attribute containing the data value to submit to the server when that option is selected. If no value attribute is included, the value defaults to the text contained inside the element. You can include a selected attribute on an element to make it selected by default when the page first loads.
The <select> element has some unique attributes you can use to control it, such as multiple to specify whether multiple options can be selected, and size to specify how many options should be shown at once. It also accepts most of the general form input attributes such as required, disabled, autofocus, etc.
File picker
There is one last <input> type that came to us in early HTML: the file input type. Forms are able to send files to a server (this specific action is also detailed in the Sending form data article). The file picker widget can be used to choose one or more files to send.
To create a file picker widget, you can use the <input> element with its type attribute set to file. The types of files that are accepted can be constrained using the accept attribute. In addition, if you want to let the user pick more than one file, you can do so by adding the multiple attribute.
In the following example, a file picker is created to request graphic image files. The user is allowed to select multiple files in this case:
On some mobile devices, the file picker can access photos, videos, and audio captured directly by the device’s camera and microphone by adding capture information to the accept attribute like so:
The HTML <button> element represents a clickable button, used to submit forms or anywhere in a document for accessible, standard button functionality. By default, HTML buttons are presented in a style resembling the platform the browser runs on, but you can change buttons’ appearance with CSS.
The default behavior of the button can be changed with the type attribute. Possible values are:
submit: The button submits the form data to the server. This is the default if the attribute is not specified for buttons associated with the form or if the attribute contains an empty or an invalid value.
reset: The button resets all the controls to their initial values. You should use it only when necessary, since this behavior tends to annoy users.
button: The button has no default behavior, and does nothing when pressed by default. It can have client side scripts listen to the element’s events, which are triggered when the events occur.
Let’s see all types of buttons with a simple example:
<p>
<label>Enter your comment: <input type="text" name="comment" required /></label>
</p>
<p>
<button type="submit">This is a submit button</button>
</p>
<p>
<button type="reset">This is a reset button</button>
</p>
<p>
<button type="button">This is a simple button</button>
</p>
As you can see from the examples, <button> elements let you use HTML in their content, which is inserted between the opening and closing <button> tags. <input> elements on the other hand are empty elements; their displayed content is inserted inside the value attribute, and therefore only accepts plain text as content.
Proposed exercise: Native controls
Create a web page to show samples of all the input elements in this section: single line and multiple line text, password, checkboxes and radio buttons, select and file picker. You must include at least two examples of each of them. You have to use paragraphs and labels, and also the “required” attribute and all necessary field constraints have to be set for all of them. Check the result in your browser, and do not forget to include all basic HTML tags and validate your code. Finally, upload the code to your domain and check the result in your mobile phone.
Put all the tags inside a <form> container and use a submit button so that you can check that the fields are properly validated:
In the previous section we looked at the <input> element, covering the original values of the type attribute available since the early days of HTML. Now we’ll look at the functionality of newer form controls in detail, including some new input types, which were added in HTML5 to allow collection of specific types of data.
E-mail address field
This type of field is set using the value email for the type attribute:
<label>
Enter a valid email:
<input type="email" name="email" placeholder="e.g. [email protected]" required />
</label>
When this type is used, the user is required to type a valid email address into the field. Any other content causes the browser to display an error when the form is submitted. You can see this in action here:
You can also use the multiple attribute in combination with the email input type to allow several email addresses to be entered in the same input (separated by commas):
On some devices (notably touch devices with dynamic keyboards like smart phones) a different virtual keypad might be presented that is more suitable for entering email addresses, including the @ key. This is another good reason for using these newer input types, improving the user experience for users of these devices.
URL field
A special type of field for entering URLs can be created using the value url for the type attribute:
It adds special validation constraints to the field. The browser will report an error if no protocol (such as http: is entered, or if the URL is otherwise malformed. You can see this in action here:
On devices with dynamic keyboards, the default keyboard will often display some or all of the colon, period, and forward slash as default keys.
Phone number field
A special field for filling in phone numbers can be created using tel as the value of the type attribute:
When accessed via a touch device with a dynamic keyboard, most devices will display a numeric keypad when type="tel" is encountered, meaning this type is useful whenever a numeric keypad is useful, and doesn’t just have to be used for telephone numbers.
Due to the wide variety of phone number formats around the world, this type of field does not enforce any constraints on the value entered by a user (this means it may include letters, etc.).
Numeric field
Controls for entering numbers can be created with an <input type="number"> This control looks like a text field but allows only floating-point numbers, and usually provides buttons in the form of a spinner to increase and decrease the value of the control. On devices with dynamic keyboards, the numeric keyboard is generally displayed.
With the number input type, you can constrain the minimum and maximum values allowed by setting the min and max attributes. You can also use the step attribute to set the increment increase and decrease caused by pressing the spinner buttons. By default, the number input type only validates if the number is an integer. To allow float numbers, specify step="any" If omitted, the step value defaults to 1, meaning only whole numbers are valid.
Let’s look at some examples. The first one below creates a number control whose value is restricted to any value between 1 and 10, and whose increase and decrease buttons change its value by 2:
The second one creates a number control whose value is restricted to any value between 0 and 1 inclusive, and whose increase and decrease buttons change its value by 0.01:
The <input type="number"> makes sense when the range of valid values is limited, for example a person’s age or height. If the range is too large for incremental increases to make sense (such as USA ZIP codes, which range from 00001 to 99999), the <input type="tel"> might be a better option; it provides the numeric keypad while forgoing the number’s spinner UI feature.
Slider controls
Another way to pick a number is to use a slider. You see these quite often on sites like house buying sites where you want to set a maximum property price to filter by. Let’s look at a live example to illustrate this:
Usage-wise, sliders are less accurate than text fields. Therefore, they are used to pick a number whose precise value is not necessarily important.
A slider is created using the <input> with its type attribute set to the value range (<input type="range">). The slider-thumb can be moved via mouse or touch, or with the arrows of the keypad. It’s important to properly configure your slider. To that end, it’s highly recommended that you set the min, max, and step attributes which set the minimum, maximum and increment values, respectively.
Let’s look at the code behind the above example, so you can see how its done. First of all, the basic HTML:
<form>
<p>Choose a maximum house price:</p>
<input type="range" name="range"
min="50000" max="500000" step="100" value="250000"
oninput="number.value = this.value" />
<input type="number" name="number"
min="50000" max="500000" step="100" value="250000"
oninput="range.value = this.value" />
</form>
This example creates a slider whose value may range between 50000 and 500000, which increments/decrements by 100 at a time. We’ve given it default value of 250000, using the value attribute.
One problem with sliders is that they don’t offer any kind of visual feedback as to what the current value is. This is why we’ve included an <input type="number"> element to contain the current value using some JavaScript code (we will go into this in a future unit).
Date and time pickers
Gathering date and time values has traditionally been a nightmare for web developers. For a good user experience, it is important to provide a calendar selection UI, enabling users to select dates without necessitating context switching to a native calendar application or potentially entering them in differing formats that are hard to parse. For example, the last minute of the previous millennium can be expressed in many different ways: 1999/12/31, 23:59, 12/31/99T11:59PM, etc.
HTML date controls are available to handle this specific kind of data, providing calendar widgets and making the data uniform.
A date and time control is created using the <input> element and an appropriate value for the type attribute, depending on whether you wish to collect dates, times, or both. Let’s look at the different available types in brief:
All date and time controls can be constrained using the min and max attributes, with further constraining possible via the step attribute (whose value varies according to input type):
<label>
When is your birthday?
<input type="date" name="date" min="1975-01-01" max="2025-12-31" step="1" />
</label>
Color picker control
Colors are always a bit difficult to handle. There are many ways to express them: RGB values (decimal or hexadecimal), HSL values, keywords, and so on.
A color control can be easily created using the <input> element with its type attribute set to the value color. For example:
When supported, clicking a color control will tend to display the operating system’s default color picking functionality for you to actually make your choice with. Here is a live example for you to try out:
Search field
Search fields are intended to be used to create search boxes on pages and apps. This type of field is set by using the value search for the type attribute:
The main difference between a text field and a search field is how the browser styles its appearance. Often, search fields are rendered with rounded corners; they also sometimes display an “Ⓧ”, which clears the field of any value when clicked. Additionally, on devices with dynamic keyboards, the keyboard’s enter key may read “search”, or display a magnifying glass icon.
Another worth-noting feature is that the values of a search field can be automatically saved and re-used to offer auto-completion across multiple pages of the same website; this tends to happen automatically in most modern browsers.
Proposed exercise: HTML5 input types
Create a web page to show samples of all the input elements in this section: email, url, phone number, numeric field, slide control, date and time, color picker and search field. You must include at least two examples for each of them. You have to use paragraphs and labels, and also the “required” attribute and all necessary field constraints have to be set for all of them. Check the result in your browser, and do not forget to include all basic HTML tags and validate your code. Finally, upload the code to your domain and check the result in your mobile phone.
Put all the tags inside a <form> container and use a submit button so that you can check that the fields are properly validated:
The section provides you with your very first experience of creating a real web form, including designing a simple form, implementing it using the right HTML form controls and other HTML elements, and describing how data is sent to a server. We’ll expand on each of these subtopics in more detail later.
Designing your form
Before starting to code, it’s always better to step back and take the time to think about your form. Designing a quick mockup will help you to define the right set of data you want to ask your user to enter. From a user experience (UX) point of view, it’s important to remember that the bigger your form, the more you risk frustrating people and losing users. Keep it simple and stay focused: ask only for the data you absolutely need.
Designing forms is an important step when you are building a site or application. It’s beyond the scope of this guide to cover the user experience of forms, but if you want to dig into that topic you should read the following articles:
In this section, we’ll build a simple contact form. Let’s make a rough sketch:
Our form will contain three text fields and one button. We are asking the user for their name, their e-mail and the message they want to send. Hitting the button will send their data to a web server.
Implementing your form
Let’s start creating the HTML for our form. We will use the following HTML elements: <form>, <label>, <input>, <textarea>, <button>.
The <form> element
All forms start with a <form> element, like this:
<form action="contact.php" method="get">
</form>
This element formally defines a form. It’s a container element and it also supports some specific attributes to configure the way the form behaves. All of its attributes are optional, but it’s standard practice to always set at least the action and method attributes:
The action attribute defines the location (URL) where the form’s collected data should be sent when it is submitted.
The method attribute defines which HTTP method to send the data with (usually GET or POST).
We’ll look at how those attributes work in our sending form data section later on.
The <label>, <input> and <textarea> elements
Our contact form is not complex: the data entry portion contains three text fields, each with a corresponding <label>:
For usability and accessibility, we include an explicit label for each form control. There is great benefit to doing this — it associates the label with the form control, enabling mouse, trackpad, and touch device users to click on the label to activate the corresponding control, and it also provides an accessible name for screen readers to read out to their users.
On the <input> element, the most important attribute is the type attribute. This attribute is extremely important because it defines the way the <input> element appears and behaves:
In our simple example, we use <input type="text"> for the first input (the default value for this attribute). It represents a basic single-line text field that accepts any kind of text input.
For the second input, we use <input type="email"> which defines a single-line text field that only accepts a well-formed e-mail address. This turns a basic text field into a kind of “intelligent” field that will perform some validation checks on the data typed by the user. It also causes a more appropriate keyboard layout for entering email addresses (e.g. with an @ symbol by default) to appear on devices with dynamic keyboards, like smartphones.
Last but not least, note the syntax of <input> vs. <textarea></textarea> This is one of the oddities of HTML. The <input> tag is an empty element, meaning that it doesn’t need a closing tag. <textarea> is not an empty element, meaning it should be closed with the proper ending tag.
The <button> element
The markup for our form is almost complete; we just need to add a button to allow the user to send, or “submit”, their data once they have filled out the form. This is done by using the <button> element. We only need to add the following just above the closing </form> tag:
<button type="submit">Send your message</button>
As explained in a previous section, the <button> element also accepts a type attribute, with one of three values: submit, reset, or button:
A click on a submit button (the default value) sends the form’s data to the web page defined by the action attribute of the <form> element.
A click on a reset button resets all the form widgets to their default value immediately. From a UX point of view, this is considered bad practice, so you should avoid using this type of button unless you really have a good reason to include one.
A click on a button button does… nothing! That sounds silly, but it’s amazingly useful for building custom buttons, since you can define their chosen functionality with JavaScript.
Sending form data to your web server
The last part, and perhaps the trickiest, is to handle form data on the server side. The <form> element defines where and how to send the data thanks to the action and method attributes.
We provide a name to each form control. The names are important on both the client and server side; they tell the browser which name to give each piece of data and, on the server side, they let the server handle each piece of data by name. The form data is sent to the server as name/value pairs.
To name the data in a form you need to use the name attribute on each form widget that will collect a specific piece of data. Let’s look at our contact form again:
In our example, the form will send 3 pieces of data named “name”, “email”, and “message”. That data will be sent to the URL “contact.php” using the HTTP GET method.
On the server side, the script at the URL “contact.php” will receive the data as a list of three key/value items contained in the HTTP request. The way this script will handle that data is up to you. Each server-side language (PHP, Python, Ruby, Java, C#, etc.) has its own mechanism of handling form data. It’s beyond the scope of this guide to go deeply into that subject for each language, but we will provide an example so that you can test your own forms using PHP.
Client-side form validation
Before submitting data to the server, it is important to ensure all required form controls are filled out, in the correct format. This is called client-side form validation, and helps ensure data submitted matches the requirements set for the various form controls.
Client-side validation is an initial check and an important feature of good user experience; by catching invalid data on the client-side, the user can fix it straight away. If it gets to the server and is then rejected, a noticeable delay is caused by a round trip to the server and then back to the client-side to tell the user to fix their data.
If you go to any popular site with a registration form, you will notice that they provide feedback when you don’t enter your data in the format they are expecting. You’ll get messages such as:
“This field is required” (You can’t leave this field blank).
“Please enter your phone number in the format xxxxxxxxx” (A specific data format is required for it to be considered valid).
“Please enter a valid email address” (the data you entered is not in the right format).
“Your password needs to be between 8 and 30 characters long and contain one uppercase letter, one symbol, and a number” (A very specific data format is required for your data).
This is called form validation. When you enter data, the browser and/or the web server will check to see that the data is in the correct format and within the constraints set by the application. Validation done in the browser is called client-side validation, while validation done on the server is called server-side validation. In this chapter we are focusing on client-side validation.
If the information is correctly formatted, the application allows the data to be submitted to the server and (usually) saved in a database; if the information isn’t correctly formatted, it gives the user an error message explaining what needs to be corrected, and lets them try again.
One of the most significant features of HTML5 form controls is the ability to validate most user data. This is done by using validation attributes on form elements. We’ve seen many of these earlier in the unit, but to recap:
required: Specifies whether a form field needs to be filled in before the form can be submitted.
minlength and maxlength: Specifies the minimum and maximum length of textual data (strings). You can constrain the character length of all text fields created by <input> or <textarea> using these attributes. A field is invalid if it has fewer characters than the minlength value or more than the maxlength value.
min and max: Specifies the minimum and maximum values of numerical input types.
type: Specifies whether the data needs to be a number, an email address, or some other specific preset type.
If the data entered in a form field follows all of the rules specified by the above attributes, it is considered valid. If not, it is considered invalid.
Further reading
We want to make filling out web forms as easy as possible. So why do we insist on validating our forms? There are three main reasons:
We want to get the right data, in the right format. Our applications won’t work properly if our users’ data is stored in the wrong format, is incorrect, or is omitted altogether.
We want to protect our users’ data. Forcing our users to enter secure passwords makes it easier to protect their account information.
We want to protect ourselves. There are many ways that malicious users can misuse unprotected forms to damage the application (see Website security).
Keeping this in mind, client-side validation should not be considered an exhaustive security measure! Your apps should always perform security checks on any form-submitted data on the server-sideas well as the client-side, because client-side validation is too easy to bypass, so malicious users can still easily send bad data through to your server. Read Website security for an idea of what could happen; implementing server-side validation is somewhat beyond the scope of this module, but you should bear it in mind.
On the server side: retrieving the data
Whichever HTTP method you choose, the server receives a string that will be parsed in order to get the data as a list of key/value pairs. The way you access this list depends on the development platform you use and on any specific frameworks you may be using with it.
PHP offers some global objects to access the data. Assuming you’ve used the GET method, the example in the next sections just takes the data and saves it to a file. Of course, what you do with the data is up to you. You might display it, store it into a database, send it by email, or process it in some other way. We will use PHP to complete our examples.
The GET method
The GET method is the method used by the browser to ask the server to send back a given resource: “Hey server, I want to get this resource”. In this case, the browser sends an empty body. Because the body is empty, if a form is sent using this method the data sent to the server is appended to the URL.
Considering our contact form, and keeping in mind that GET method has been used, when we submit the form, we’ll see that the data appear in the URL at the browser address bar. For example, if you enter “Fernando” as the user name, “[email protected]” as the email address, and “Hello” as the message, and you press the submit button, your should see something like this in the address bar: “contact.php?name=Fernando&[email protected]&message=Hello“.
The data is appended to the URL as a series of name/value pairs. After the URL web address has ended, a question mark is included (?) followed by the name/value pairs, each one separated by an ampersand (&). In this case we are passing three pieces of data to the server:
Create a new web page with a contact form, using the code in the previous example. It should look like the one below (probably not so nice). Check the result in your browser and validate your code. Also try to send the data by pressing the button and check the URL inside the address bar. Finally set the minimum and maximum length of the text fields to any values you consider suitable to ensure the data in this form is correct before sending it to the server.
Note that if you press the submit button, you will go to the “contact.php” page, which is not implemented yet. At this point you will get an error, but your will see all the information in the URL, since we are using the GET method.
Proposed exercise: Full contact form
Let’s go ahead with some simple PHP code to save our data from the contact form. Create a file “contact.php” with the code below. Upload the form and the php code to your server and test your full example of the contact form to check that the messages are now saved into the server. Also tell some friends to test the web page and check that the data they have entered is also saved.
<?php
// The global $_GET variable allows you to access the data sent with the GET method by name
$name = $_GET['name'];
$email = $_GET['email'];
$message = $_GET['message'];
// We put all data into the file "messages.csv" in a new line each time
file_put_contents("messages.csv", "$name;$email;$message\n", FILE_APPEND);
// We show a link to the previous page and also to the file to check the results
echo "<p>Data saved</p>";
echo "<p>Click <a href='".$_SERVER['HTTP_REFERER']."'>here</a> to go back</p>";
echo "<p>Click <a href='messages.csv' target='_blank'>here</a> to see all messages</p>";
?>
Proposed exercise: Greetings form
Create a new web page with a form similar to the one below, check the result in your browser and validate the code. Press the submit button and have a look at the browser address bar. After that enter another data different from the default values, press the submit button and check that the new URL contains the right information. Finally change the default value of both text fields (“Hi” and “Mom”) to use some other values, and check the result again.
Note that if you press the submit button, you will go to the “greetings.php” page, which is not implemented yet. At this point you will get an error, but your will see all the information in the URL, since we are using the GET method.
<form action="greetings.php" method="GET">
<p>
<label>
What greeting do you want to say?: <input name="say" value="Hi" required />
</label>
</p>
<p>
<label>
Who do you want to say it to?: <textarea name="to" required>Mom</textarea>
</label>
</p>
<p>
<button>Send my greetings</button>
</p>
</form>
Proposed exercise: Full greetings form
Let’s go ahead with some simple PHP code to save our data from the greetings form. Create a file “greetings.php” with the code below. Upload the form and the php code to your server and test your full example of the greetings form to check that the greetings are now saved into the server. Also tell some friends to test the web page and check that the data they have entered is also saved.
You will see the similarities from the previous example (we have only changed the variables ($say and $to) and the file name where the data is saved (“greetings.csv”).
<?php
// The global $_GET variable allows you to access the data sent with the GET method by name
$say = $_GET['say'];
$to = $_GET['to'];
// We put all data into the file "greetings.csv" in a new line each time
file_put_contents("greetings.csv", "$say,$to\n", FILE_APPEND);
// We show a link to the previous page and also to the file to check the results
echo "<p>Data saved</p>";
echo "<p>Click <a href='".$_SERVER['HTTP_REFERER']."'>here</a> to go back</p>";
echo "<p>Click <a href='greetings.csv' target='_blank'>here</a> to see all messages</p>";
?>
The POST method
The POST method is a little different. It’s the method the browser uses to talk to the server when asking for a response that takes into account the data provided in the body of the HTTP request: “Hey server, take a look at this data and send me back an appropriate result”. If a form is sent using this method, the data is appended to the body of the HTTP request instead of the URL. It is more secure than the GET method, since when the form is submitted using the POST method, the data cannot be seen by any other person around. This method is recommended for example to be used in forms where a password is sent.
Let’s look at the following example, which is quite similar to the form in the GET section above, but with the method attribute set to POST and the type of the input box set to “password”:
Create a new web page with a login form, using the code in the previous example. It should look like the one below (probably not so nice). Check the result in your browser and validate your code. Also try to send the data by pressing the button and check if there is any information in the URL. Finally set the minimum length of the user text field to 5 and the maximum to 10, and do the same for the password field.
Note that if you press the submit button, you will go to the “login.php” page, which is not implemented yet. At this point you will get an error, but you will not see any information in the URL, since we are using the POST method.
Proposed exercise: Full login form
Let’s go ahead with some simple PHP code to check the user and the password from the login form. Create a file “login.php” with the code below. Upload the form and the php code to your server and test your full example of the login form to check the user (“admin”) and the password (“1234”). Also tell some friends to test your web page. After that, change the password from the file “login.php” and ask your friends to try to guess your new password. You must use a very simple password from “https://en.wikipedia.org/wiki/List_of_the_most_common_passwords” (otherwise your friends may be not able to guess it).
You will see the similarities from the previous example (we have only changed the variables ($user and $password) and we have used a condition to show an image with a thumb up or down, depending on whether the password is correct or not.
<?php
// The global $_POST variable allows you to access the data sent with the POST method by name
$user = $_POST['user'];
$password = $_POST['password'];
// Check the user and the password
if ($user == "admin" && $password == "1234") {
echo "<img src='https://raw.githubusercontent.com/twbs/icons/main/icons/hand-thumbs-up.svg' width='100' />";
echo "<p>Perfect! :-)</p><p>Click <a href='".$_SERVER['HTTP_REFERER']."'>here</a> to go back</p>";
}
else {
echo "<img src='https://raw.githubusercontent.com/twbs/icons/main/icons/hand-thumbs-down.svg' width='100' />";
echo "<p>Invalid user or password! :-(</p><p>Click <a href='".$_SERVER['HTTP_REFERER']."'>here</a> to try again</p>";
}
?>
Quiz
Test your skills with this quiz about HTML forms and some other concepts related to this unit.
If you are working with audio and video on the web, you may find useful some test resources in various formats and quality. This collection consists of various permissively licenced works you can use for testing purposes. As a bonus, they’re fun to watch and listen to.
Note that file sizes, compression and quality vary wildly. This is due to using different parameters when encoding, and the codecs themselves evolving over time.
Caminandes 3: Llamigos (2016)
It’s winter in Patagonia, food is getting scarce. Koro the Llama engages with Oti the pesky penguin in an epic fight over that last tasty berry.
Now that we are comfortable with adding text and simple images to a web page, the next step is to start adding video and audio players to your HTML documents! In this unit we’ll look at doing just that with the video and audio elements; we’ll then finish off by looking at how to add captions to your videos, and as a bonus, how to add maps to your pages.
Video and audio on the web
Web developers have wanted to use video and audio on the Web for a long time, ever since the early 2000s when we started to have bandwidth fast enough to support any kind of video (video files are much larger than text or even images). In the early days, native web technologies such as HTML didn’t have the ability to embed video and audio on the Web, so proprietary (or plugin-based) technologies like Flash (and later, Silverlight) became popular for handling such content. This kind of technology worked ok, but it had a number of problems, including not working well with HTML/CSS features, security and accessibility issues.
A native solution would solve much of this if implemented correctly. Fortunately, a few years later the HTML5 specification had such features added, with the <video> and <audio> elements, and some shiny new JavaScriptAPIs for controlling them. We’ll not be looking at JavaScript here — just the basic foundations that can be achieved with HTML.
We won’t be teaching you how to produce audio and video files — that requires a completely different skillset. For your own experimentation you can use some sample audio and video files as for example the ones available at “https://fernandoruizrico.com/test-audio-and-video/“.
The <video> element
The <video> element allows you to embed a video very easily. In the same way as for the <img> element, the src (source) attribute contains a path to the video you want to embed (it works in exactly the same way). You can also allow the users to be able to control video and audio playback through the controls attribute to include the browser’s own control interface. If this attribute is present, the browser will offer controls to allow the user to control video playback, including volume, seeking, and pause/resume playback. A really simple example looks like this:
You can insert a paragraph inside the video tag. This is called fallback content. It will be displayed if the browser accessing the page doesn’t support the <video> element, allowing us to provide a fallback for older browsers. This can be anything you like; in this case, we suggest providing a direct link to the video file, so the user can at least access it some way regardless of what browser they are using:
You can control the video size either with these attributes or with CSS. By setting the value in pixels of each attribute, you can choose to change either the width or the height of the video’s display area. In both cases, videos maintain their native width-height ratio — known as the aspect ratio. If the aspect ratio is not maintained by the sizes you set, the video will grow to fill the space horizontally, and the unfilled space will just be given a solid background color by default. For example, to set the width of the video to 720px and maintain the aspect ratio:
Create a web page with the previous example, and copy the code three times to show the same video three times in total. Change the width to set a different value for each video (1080, 720 and 480) and also change the src attribute accordingly. Finally, check the results in your browser (refresh your web page to assure that the browser is rendering the last changes in your code). Do not forget to include all necessary basic HTML tags and validate your code.
You can set a URL for an image (poster attribute) to be shown while the video is downloading. If this attribute isn’t specified, nothing is displayed until the first frame is available, then the first frame is shown as the poster frame. This image can be easily set like this:
Modify the code of the previous exercise, where you have the same video with three different sizes. Now you have to use the poster attribute to set three different images (you can find below the links to the posters, which are available at https://fernandoruizrico.com/test-audio-and-video/, or you can use any other images you like). When you finish, check the results in your browser (refresh your web page to assure that the browser is rendering the last changes in your code). Do not forget to include all necessary basic HTML tags and validate your code.
Usually some codecs are used to compress video and audio into manageable files, since raw audio and video are both exceedingly large. Each web browser supports an assortment of codecs, which are used to convert the compressed audio and video into binary data and back. Each codec offers its own positive and negative features affecting your decisions about which to use. In order to maximize the likelihood that your web site or app will work on a user’s browser, you may need to provide each media file you use in multiple formats. If your site and the user’s browser don’t share a media format in common, your media simply won’t play.
One additional thing to keep in mind: mobile browsers may support additional formats not supported by their desktop equivalents, just like they may not support all the same formats the desktop version does. On top of that, both desktop and mobile browsers may be designed to offload handling of media playback (either for all media or only for specific types it can’t handle internally). This means media support is partly dependent on what software the user has installed.
So how do we do this? Take a look at the following updated example:
Here we’ve taken the src attribute out of the actual <video> tag, and instead included separate <source> elements that point to their own sources. In this case the browser will go through the <source> elements and play the first one that it has the codec to support. First WebM is tried. If that can’t be played, then MP4 is tried. Usually, including WebM and MP4 sources should be enough to play your video on most platforms and browsers these days. Also in the example, a fallback message is displayed if the video element isn’t supported, but not if all sources fail.
Each <source> element also has a type attribute. This is optional, but it is advised that you include it. The type attribute contains the MIME type of the file, and browsers can use the type to immediately skip videos they don’t understand. If type isn’t included, browsers will load and try to play each file until they find one that works, which obviously takes time and is an unnecessary use of resources.
You can refer to the Mozilla’s guide to media types and formats for help selecting the best containers and codecs for your needs, as well as to look up the right MIME types to specify for each.
Proposed exercise: Caminandes animated film
You have to modify the code of the previous exercise where you have three videos displaying the animated film “Caminandes”, each one with a different size and a different poster. You have to insert now a couple of source elements so that all three videos contain links for both the webm and mp4 codecs (you can find the links in the example below and also at https://fernandoruizrico.com/test-audio-and-video/). Check the results in your browser and do not forget to add all necessary HTML tags and validate your code.
Notice that the width of the video is set through the width attribute, and we have also used the poster attribute to set the image that will be displayed before the video is played:
Create a new web page with the code below to show the “Sintel” animated film. After that, duplicate the code a couple of times to show three videos in total. Change the size of the videos to 1080, 720 and 480 and set the source elements accordingly (also remove the old src attribute, so that you get a similar code as the one shown in the example below). Finally change the poster image so that each video is displaying a different image when the page has just been loaded. You may find the links to both the videos and posters at https://fernandoruizrico.com/test-audio-and-video/, and also here:
A boolean attribute. If specified, the video automatically begins to play back as soon as it can do so without stopping to finish loading the data.
Important: You are advised not to use autoplaying video (or audio) on your sites, because users can find it really annoying (some browsers will not even allow the audio or video start playing right away). Keep in mind that sites that automatically play audio (or videos with an audio track) can be an unpleasant experience for users, so should be avoided when possible. If you must offer autoplay functionality, you should make it opt-in (requiring a user to specifically enable it). However, this can be useful when creating media elements whose source will be set at a later time, under user control. See our autoplay guide for additional information about how to properly use autoplay.
The loop attribute
Makes the video (or audio) start playing again whenever it finishes. This can also be annoying, so only use if really necessary.
The muted attribute
A boolean attribute that indicates the default setting of the audio contained in the video. If set, the audio will be initially silenced. Its default value is false, meaning that the audio will be played when the video is played.
The preload attribute
This enumerated attribute is intended to provide a hint to the browser about what the author thinks will lead to the best user experience with regards to what content is loaded before the video is played. It may have one of the following values:
none: Indicates that the video should not be preloaded.
metadata: Indicates that only video metadata (e.g. length) is fetched.
auto: Indicates that the whole video file can be downloaded, even if the user is not expected to use it.
Proposed exercise: Additional attributes
Following the previous examples, create a new web page with three videos you like, and set different values of the following attributes: loop, muted and preload. You can also try the autoplay attribute, although keep in mind that some browsers may have this feature disabled. Finally check the results in your browser and validate the code.
Create a web page to show the top ten videos you most like. You must set at least the width and poster attributes and also the source element to assure all of them are displayed in the right way as the previous examples.
The HTML <audio> element is used to embed sound content in documents. It may contain one or more audio sources, represented using the src attribute or the <source> element: the browser will choose the most suitable one. It works just like the <video> element, with a few small differences as outlined below. A typical example might look like so:
The above example shows simple usage of the <audio> element. In a similar manner to the <img> and <video> elements, we include a path to the media we want to embed inside the src attribute. We can include other attributes to specify information such as whether we want it to loop, whether we want to show the browser’s default audio controls, etc.
As with the <video> tag, the content inside the opening and closing <audio></audio> tags is shown as a fallback in browsers that don’t support the element.
This takes up less space than a video player, as there is no visual component — you just need to display controls to play the audio. Other differences from HTML video are as follows:
The <audio> element doesn’t support the width/height attributes — again, there is no visual component, so there is nothing to assign a width or height to.
It also doesn’t support the poster attribute — again, no visual component.
Proposed exercise: Sample audios
Following the previous example, create a web page to insert at least ten figures containing audio samples. Update the caption of each figure to show a brief description of each audio file, and check the results in your browser. Do not forget to add all necessary HTML basic tags and validate your code.
By now you should really be getting the hang of embedding things into your web pages, including images, video and audio. At this point we will like to take somewhat of a sideways step, looking at an element that allow you to embed a wide variety of content types into your webpages: the <iframe> element.
Embed a video from Youtube
In this section we are going to jump straight into an active learning example to immediately give you a real idea of just what embedding technologies are useful for. The online world is very familiar with Youtube, but many people don’t know about some of the sharing facilities it has available. Let’s look at how Youtube allows us to embed a video in any page we like using an <iframe>:
First, go to Youtube and find a video you like.
Below the video, you’ll find a Share button — select this to display the sharing options.
Select the Embed button and you’ll be given some <iframe> code — copy this.
Following the previous example, create a web page to insert at least ten figures containing videos from Youtube. Update the caption of each figure to show a brief description of each video, and check the results in your browser. Do not forget to add all necessary HTML basic tags and validate your code.
Embed a map from Google Maps
You will also find quite interesting embedding a Google Map. Let’s see how to do this with an example:
Go to Google Maps and find a map you like.
Click on the “Hamburger Menu” (three horizontal lines) in the top left of the user interface.
Select the Share or embed map option.
Select the Embed map option, which will give you some <iframe> code — copy this.
Following the previous example, create a web page to insert at least ten figures containing locations from Google Maps. Update the caption of each figure to show a brief description of each location, and check the results in your browser. Do not forget to add all necessary HTML basic tags and validate your code.
Quiz
Test your skills with this quiz about audio and video, and some other concepts related to this unit.
