Lesson 1 — Independent practice

3 hours · Build and inspect your own Travel Request page

You have seen how a small web page is built and how to inspect it in the browser. Now it is your turn to work from a short brief rather than following every step.

Keep the companion reference nearby when you need a reminder, and return to the guided lesson if you want to check how something works.

This task uses HTML, CSS, VS Code, the Live Server extension, and the browser. You will preview your files through the local HTTP server you learned to use in the guided lesson. There is no JavaScript file to write, no Vite, and no npm.

Your challenge

A fictional company, Northstar Travel Desk, wants a simple page where employees can see travel options and complete a demonstration request form.

You have been asked to make the page:

• easy to read;
• usable on a phone and on a desktop;
• clearly structured;
• accessible with properly labeled fields;
• easy to inspect and troubleshoot.

The form is only a demonstration. It does not save travel requests or send anything to a company system.

Skills you will practice

By the end of the lab, you should be able to:

1. Create a local HTML page and reference a CSS file.
2. Organize content using headings, semantic elements, links, and lists.
3. Build a native HTML form with correct labels and attributes.
4. Apply basic layout, spacing, and responsive CSS.
5. Inspect the page using Elements and Console.
6. Explain the difference between saved HTML and the live DOM.
7. Find, explain, and repair a simple markup defect.
8. Report what you tested and what you learned.

---

Suggested workflow

Step	Focus	Checkpoint
1	Read the brief and plan	Decide the major page sections
2	Create HTML content and form	Page is understandable without CSS
3	Add simple CSS	Page is readable on phone and desktop
4	Inspect, validate, and debug	Test results and repaired defect
5	Review and submit	Files, screenshots, and reflection are ready

Prioritize the required behavior before adding visual extras.

---

1. Starting point

Create a new folder named travel-request-practice.

Inside it, create these files:

travel-request-practice/
├── index.html
└── style.css

Open the folder in VS Code.

Use the normal HTML document skeleton from the guided lesson. The stylesheet link should refer to the CSS file next to index.html:

<link rel="stylesheet" href="./style.css" />

Right-click index.html in VS Code and select Open with Live Server. Confirm that the page opens at a local HTTP address such as http://127.0.0.1:5500/index.html (your port may differ). After changes, save the file and watch Live Server reload the page.

Work on your own page

You may reuse patterns from the guided lesson, but do not simply change the company name and submit the teacher's example. The content, fields, and requirements below are your new brief.

---

2. Page requirements

A. Header and navigation

Your header must contain:

• the site name Northstar Travel Desk;
• a link to the Available journeys section;
• a link to the Travel request section.

Use ordinary in-page links with href="#..." and matching section IDs.

Use semantic HTML for the header, navigation, and main content.

B. Main heading and introduction

Use this page heading:

Travel requests made simple

Add a short paragraph in your own words explaining what the page is for. State clearly that requests are not saved.

Your page should have one clear page-level heading and sensible section headings.

C. Available journeys

Show all three journeys below. You can choose cards, a list, or another clear layout.

Destination	Trip type	Duration	Availability
Porto	Team workshop	2 days	Open
Lisbon	Client meetings	3 days	Open
Coimbra	Training session	1 day	Limited

For each journey, display:

• destination;
• trip type;
• duration;
• availability.

Make the three journeys easy to tell apart. A simple border, space between items, or subtle background is enough.

D. Travel request form

Create the following six controls.

Field	Required?	Suggested HTML
Employee name	Yes	input with type="text"
Work email	Yes	input with type="email"
Destination	Yes	select with the three destinations
Departure date	Yes	input with type="date"
Number of travelers	Yes	input with type="number"
Additional notes	No	textarea

Follow these rules:

1. Every control has a visible <label>.
2. Every control has a unique id.
3. Every <label for="..."> matches its control's id.
4. Every control has a name attribute.
5. The five required fields use the required attribute and are visibly indicated as required.
6. Additional notes is visibly marked optional and does not use required.
7. The number input uses min="1" and step="1".
8. The destination select starts with Choose a destination and an empty value (value=""). The actual destination options have nonempty values.
9. The form contains a submit button labeled Submit demo form.
10. A notice near the button explains that no request is saved.

Use a demonstration form such as:

<form action="#" method="get">
  <!-- Your labeled controls go here -->
  <button type="submit">Submit demo form</button>
</form>

About the submit button

Because Live Server hosts this demonstration page locally, a valid GET submission can add form values to its URL. You are being assessed on form structure, labels, and validation, not on sending the request anywhere. No request is stored. Use invented information only.

You do not need to check whether a date is in the future, validate a company-specific email domain, or create a database.

E. Footer

Include the site name and a short training-demo notice.

---

3. CSS requirements

Choose your own colors and spacing. Keep the styling simple.

Your page must:

• have readable text and sufficient contrast;
• have comfortable spacing around content;
• distinguish the journey items visually;
• show form labels clearly;
• keep fields usable at a narrow phone-sized width;
• avoid horizontal scrolling at that narrow width;
• remain readable on a wide desktop screen;
• keep keyboard focus visible on interactive controls.

You may use basic selectors, classes, spacing, borders, flexible widths, Flexbox, or a simple media query. You do not need a complex layout.

A good starting order

First make the HTML understandable without CSS. Then add only enough styling to make it comfortable to use.

---

4. Test your page in stages

Checkpoint A — HTML structure

Before refining the styling, ask yourself:

• Can someone understand the page headings?
• Do the navigation links lead to the correct sections?
• Are all three journeys present, with every required detail?
• Does the form make sense when read from top to bottom?
• Is the optional field clearly marked?

If you have already added CSS, you can temporarily remove the stylesheet <link> to inspect the unstyled document. Restore it afterward.

Checkpoint B — Form validation

Start with valid, invented values for all required fields, such as Alex Example and alex@example.com.

Keep all other required controls valid while testing one item at a time.

Test	Expected result
Leave Employee name empty and submit	Browser blocks normal submission
Use not-an-email in Work email and submit	Browser rejects the email format
Return Destination to the empty prompt option	Browser blocks normal submission
Leave Departure date empty	Browser blocks normal submission
Enter 0 in Number of travelers	Browser rejects it because the minimum is 1
Enter 1.5 in Number of travelers	Browser rejects it because whole-number steps are required
Leave Additional notes empty	Notes do not prevent submission
Fill all five required fields correctly	Native validation should pass; the URL may gain query parameters, but nothing is saved

You are not trying to prove that the form saved anything. You are checking what the browser can validate using HTML.

Checkpoint C — Keyboard and labels

1. Click each visible label. Does it focus or activate the correct control?
2. Use Tab and Shift+Tab to move among links, fields, and the button.
3. Can you tell which control is focused?
4. Can you select a destination with the keyboard?
5. Is the order of interactive elements logical?

Checkpoint D — Screen widths

View your page at approximately:

• 375 CSS pixels wide (a narrow mobile viewport);
• 1280 CSS pixels wide (a desktop viewport).

Use the browser's device toolbar or resize the window.

Check that no text, navigation, cards, labels, or controls become clipped or unusable. The page must not require horizontal scrolling at the narrow width.

Checkpoint E — DevTools

Open the browser developer tools and complete these checks:

• [ ] In Elements, find the page's <main>.
• [ ] Inspect one journey card and identify the CSS rule that styles it.
• [ ] Find the Work email label and its matching input.
• [ ] In Console, evaluate document.title.
• [ ] In Console, evaluate document.querySelector("h1").textContent.
• [ ] In Console, count all <label> elements using document.querySelectorAll("label").length.
• [ ] Make a temporary heading-text change in Elements or Console, then refresh and explain what happened.
• [ ] Open Network and refresh. Find index.html and style.css served from localhost or 127.0.0.1, and record one HTTP status code (normally 200).

Do not write these Console expressions into a separate JavaScript file. Today we are using the Console only to inspect the page.

---

5. Required debugging challenge

A developer reports that clicking the Departure date label does not focus the date field.

The relevant HTML is:

<label for="departure">Departure date</label>
<input id="departure-date" name="departureDate" type="date" required />

Your task

1. Reproduce this kind of mismatch in your own page by changing the existing label's for value. Do not create a duplicate input.
2. Save, let Live Server reload, and test by clicking the label.
3. Use Elements to inspect the label and the date input.
4. Identify exactly which attribute is wrong.
5. Fix the HTML in VS Code, save, let Live Server reload, and retest.
6. Write two or three sentences explaining the symptom, the cause, and the fix.

Check your reasoning after completing the task

The label's for value must match the input's id. In the example, departure and departure-date are different, so the label is not associated with that input. Fix the mismatch and retest.

Optional extra defect

Temporarily change the stylesheet link to a file that does not exist. Confirm that the layout loses its CSS, inspect the link path, then restore the correct filename.

---

6. Acceptance criteria

Use this checklist as your definition of finished.

Area	Requirement
Local preview	index.html and style.css run through Live Server at a local HTTP address
HTML	Correct document structure, semantic page regions, logical headings
Navigation	Both same-page navigation links work
Content	All three required journeys and their details are present
Form	All six fields, correct types, labels, IDs, and names
Validation	Required fields, email format, destination prompt, and travelers constraints behave correctly
Accessibility	Labels are associated; keyboard focus is visible; controls are usable without a mouse
CSS	Readable spacing/layout, distinct journey items, no narrow-screen overflow
Browser inspection	You can explain the DOM and demonstrate Elements, Console, and Network HTTP status codes
Debugging	You repaired and explained the broken-label defect
Demo behavior	No claim that the form saves data

How your work is assessed

Area	Points
Page structure, navigation, and journeys	20
Form markup, labels, and native validation	25
Simple responsive CSS and keyboard usability	20
DevTools inspection and DOM understanding	20
Debugging explanation	10
Clear submission and reflection	5
Total	100

---

7. Submission

Submit your own work, consisting of:

1. index.html;
2. style.css;
3. one screenshot at desktop width;
4. one screenshot at narrow/mobile width;
5. a short written reflection (plain text or Markdown).

You do not need to submit an application scaffold, npm dependencies, or Live Server configuration. Submit only the files and evidence requested above.

Reflection prompts

Answer each question in one or two sentences:

1. What part of the page still works when CSS is removed?
2. What is the difference between changing HTML in VS Code and changing the DOM in DevTools?
3. What was wrong with the deliberately broken label, and how did you fix it?
4. What did you learn by using the browser Console?
5. Which part of the task was most challenging?

---

8. Optional stretch tasks

If all required checks pass early, choose one:

• Add a fourth journey with realistic sample details.
• Improve the visual presentation of availability, but do not rely only on color.
• Add a fieldset and legend to group related form fields.
• Add a link in the footer that returns to the page heading.
• Inspect the box model for one journey card and explain its padding, border, and margin.
• Add a brief explanation below the form showing which fields are required.

No JavaScript programming is necessary for these tasks.

Before you finish

• [ ] Both HTML and CSS files are saved.
• [ ] The browser displays the latest saved changes through Live Server.
• [ ] Network shows the HTML and CSS HTTP requests.
• [ ] All three journeys are visible.
• [ ] The form contains the six required controls with correct labels and attributes.
• [ ] Native browser validation has been tested with invalid and valid sample values.
• [ ] Navigation and keyboard focus work.
• [ ] The page is usable on narrow and wide screens.
• [ ] The debugging defect has been repaired.
• [ ] You can demonstrate at least two Console expressions.
• [ ] Screenshots and reflection are ready.

Looking ahead

In Lesson 2, we begin JavaScript programming: values, variables, operators, conversions, and expressions. You will already know what the browser is, what the DOM represents, and where to look when something goes wrong.