UNIT 1 · WEB BASICS, HTML & CSS PART A · CLASS 6 OF 12 UI23PC510CS · THEORY

Today's craft

Forms, part 1 — the page finally listens.

Every page you've built so far talks — headings, lists, tables, all one-way. Today the direction reverses: forms are how a page asks the visitor a question and collects the answer. Every order you've placed, every login, every OTP box — all forms. By the end of this hour the Poshtik Campus order form is born.

Walk out of this room able to…

Build a working <form> and explain action / method in plain English

Choose the right input type — text, email, date, tel, number

Pair every input with a <label for> the accessible way

Answer the 2-mark input-types exam question on sight

THE HOUR, POINT BY POINT

01Why forms exist — every "order", "sign up", "log in" you've ever doneIDEA

02<form>, action, method — the envelope, the address, the sending styleIDEA

03Text and email inputs — the two workhorsesIDEA

04<label for> — the pairing that makes forms humaneIDEA

05date, tel, number — and the exam question they carryIDEA EXAM Q

06Fill in the code — the Poshtik order form beginsTRY IT

07Order form — worked solutionSOLUTION

08placeholder & required — hints and guard railsIDEA

09Diagnose the blocked submit — what required really doesTRY IT

10Blocked submit — worked solutionSOLUTION

11Self-study — the full input-type reference tableSELF-STUDY

12Close — what you can do now, homework, what Class 7 unlocksWRAP

Idea one

Why forms exist.

Count today's taps: you logged in to the college portal (a form), maybe ordered breakfast (a form), searched something (a one-field form), entered an OTP (a form). The web without forms is a notice-board; the web with forms is every product you actually use. HTML gave pages this power with a small family of tags, and the head of that family is <form>.

The mental model for today: a form is an envelope. The inputs inside collect answers; the envelope's address says where those answers go; and the sending style says how they travel. Address and sending style have exact HTML names — that's the next idea.

DEPTH FOR THE CURIOUS · FORMS PREDATE ALMOST EVERYTHING

Forms arrived in HTML 2.0 (1995) — before CSS, before JavaScript was everywhere, before "web app" was a phrase. The design was so right that a 1995 form still works in a 2026 browser unchanged. Everything fancier — React controlled inputs in Unit 3, API submissions in Unit 4 — is built on the exact element you meet today.

Idea two

<form>, action, method — the envelope, addressed.

Three words carry the whole structure. <form> is the envelope that wraps every question. action is where the answers are sent — an address on a server. method is how they travel — get (answers visible in the address bar, fine for searches) or post (answers carried privately in the request body, right for orders and logins).

MINI PROBLEM · FIRST-FORM.HTML

PROBLEM

Write the envelope before the questions: an empty <form> that already knows where its answers will go and how they'll travel — and see with your own eyes that an empty envelope draws nothing.

REQUIREMENTS

Create the class-06 folder in your sandbox, save as first-form.html · title text: Poshtik Campus — Order
<h1>, then <form action="/place-order" method="post"> holding only a comment

EXPECTED OUTPUT

Only the heading renders — the form is invisible until inputs live inside it. (The /place-order server doesn't exist yet; that's Unit 4's job.)

class-06/first-form.htmlBUILDS ONE LINE PER PRESS
1<!DOCTYPE html>
2<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Poshtik Campus — Order</title>
</head>
<body>
  <h1>Poshtik Campus — Order</h1>
  <form action="/place-order" method="post">
    <!-- inputs will live here -->
  </form>
</body>
13</html>

Poshtik Campus — Order

file:///C:/Users/student/Desktop/fswd-practice/class-06/first-form.html

Poshtik Campus — Order

The form itself is invisible — an empty envelope draws nothing. Only the heading renders. Everything visible about a form comes from the inputs we're about to put inside it.

SAVE THIS AS

FOLDERC:\Users\student\Desktop\fswd-practice\class-06\ — today's first file, so create the class-06 folder inside your sandbox first (right-click, New, Folder), same ritual as every class.

FILENAMEfirst-form.html

EDITORVS Code

VIEW ITRight-click the file in VS Code's explorer, then Open with Live Server. Only the heading renders — an empty form draws nothing, exactly as the preview shows.

GIT?No commit. fswd-practice\ is your scratch sandbox — it is never a git repository. Commits happen only inside poshtik-campus\, the real project you put under git in Lab 1 — and we don't touch it today.

Honesty flag (write it in your notes): the address /place-order points at a server we have not built yet. What actually receives form data is Unit 4's job — Express and Node. Today we learn to build and read the envelope; the post office opens in Unit 4. Nothing about the HTML changes then, which is exactly why learning it now is safe.

DEPTH FOR THE CURIOUS · GET vs POST IN ONE SENTENCE EACH

get appends answers to the URL — /search?dish=ragi — visible, bookmarkable, wrong for anything private. post carries answers inside the HTTP request body (remember Class 2's request anatomy?) — invisible in the URL, the default choice for orders, sign-ups and logins. Your exam may ask for exactly this one-line contrast.

Idea three

The two workhorses: type="text" and type="email".

One void tag — <input> — plays a dozen roles, and its type attribute picks the role. The two you'll type most for the rest of your life: text (any short answer) and email (an answer that must look like an address — the browser itself checks the shape).

MINI PROBLEM · TWO-INPUTS.HTML

PROBLEM

Put two questions inside the envelope — a name box and an email box — and prove they carry different contracts even though they look identical.

REQUIREMENTS

Save as two-inputs.html inside class-06 · title text: Two inputs
Inside the same <form action="/place-order" method="post">: an <input type="text" name="student-name"> and an <input type="email" name="student-email">
Every input carries a name — a nameless answer is never sent

EXPECTED OUTPUT

Two identical-looking boxes. Type ananya into the second and press Enter — the email box objects, because "ananya" isn't shaped like an address. Same look, different contract.

class-06/two-inputs.html · the whole fileBUILDS ONE LINE PER PRESS
1<!DOCTYPE html>
2<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Two inputs</title>
</head>
<body>
  <form action="/place-order" method="post">
    Your name:
    <input type="text" name="student-name">
    College email:
    <input type="email" name="student-email">
  </form>
</body>
15</html>

Two inputs

file:///C:/Users/student/Desktop/fswd-practice/class-06/two-inputs.html

Your name: College email:

Two boxes that look identical — but type into the second one. Type ananya and press Enter: the email box objects, because "ananya" isn't shaped like an address. Same look, different contract.

SAVE THIS AS

FOLDERC:\Users\student\Desktop\fswd-practice\class-06\ — the same folder you created for first-form.html; every file today lives there.

FILENAMEtwo-inputs.html

VIEW ITOpen with Live Server. Type ananya into the email box, press Enter, and watch the browser object — the render check from §the preview, on your own machine.

GIT?No commit. Everything inside fswd-practice\ is scratch — git never watches it. Commits belong only to poshtik-campus\ (the repo you made in Lab 1), and that folder doesn't change today.

The attribute that isn't optional: every input needs a name. When the form is sent, answers travel as name=value pairs — student-name=P. Ananya. An input without a name is a question whose answer gets thrown away: the browser simply doesn't send it.

Idea four

<label for> — the pairing that makes forms humane.

On the last slide the words "Your name:" were just loose text floating near a box — the browser had no idea they belonged together. <label> makes the bond official: its for attribute names the input's id, and the two become one unit.

MINI PROBLEM · LABELLED.HTML

PROBLEM

Make the words and the box officially belong to each other: bond a <label> to its input so a click on the words lands the cursor in the box.

REQUIREMENTS

Save as labelled.html inside class-06 · title text: Labelled input
<label for="student-name">Your name:</label> followed by an input whose id matches the for exactly — plus the usual name

EXPECTED OUTPUT

One labelled box — and the proof: click the words "Your name:" and the cursor jumps into the box. Loose text never does that.

class-06/labelled.html · the whole fileBUILDS ONE LINE PER PRESS
1<!DOCTYPE html>
2<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Labelled input</title>
</head>
<body>
  <form action="/place-order" method="post">
    <label for="student-name">Your name:</label>
    <input type="text" id="student-name" name="student-name">
  </form>
</body>
13</html>

Labelled input

file:///C:/Users/student/Desktop/fswd-practice/class-06/labelled.html

Your name:

Click the words "Your name:" right here, in this preview — the cursor jumps into the box. THIS OUTPUT IS REAL: the preview's label carries the same for/id bond as the code, so it behaves exactly as your own file will. Loose text never does this.

SAVE THIS AS

FOLDERC:\Users\student\Desktop\fswd-practice\class-06\

FILENAMElabelled.html

VIEW ITOpen with Live Server, then click the words "Your name:" — if the cursor jumps into the box, your for/id pair is correct.

GIT?No commit — sandbox file. The rule since Lab 1: git guards poshtik-campus\ only.

Why professionals never skip labels — three returns for one line: ① a bigger click target (labels are tap-friendly on phones); ② screen readers announce "Your name, edit text" instead of a nameless box — this is the accessibility habit from Class 3, applied to forms; ③ examiners award the mark for for/id matching. Match them exactly — for="student-name" pairs only with id="student-name".

Idea five

Three more types — and the exam question they carry.

type="date" gives a calendar picker. type="tel" raises the number keypad on phones. type="number" accepts only digits and grows little step arrows. Choosing the right type per question is exactly what your exam asks — and here is the actual past paper.

HOW THIS IS ASKED IN YOUR EXAM PAPER 2 · Q2 2 MARKS

one type per field — that's the whole mark!

Q. Which input types would you use to accept a user's name, date of birth and email address? Write the HTML. [2M]

model answer — pyq-input-types.html · the whole fileONE POINT PER PRESS
1<!DOCTYPE html>
2<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Input types — exam answer</title>
</head>
<body>
  <form>
    <label for="name">Name:</label>
    <input type="text" id="name" name="name"><br>
    <label for="dob">Date of birth:</label>
    <input type="date" id="dob" name="dob"><br>
    <label for="email">Email:</label>
    <input type="email" id="email" name="email">
  </form>
</body>
17</html>

Input types — exam answer

file:///C:/Users/student/Desktop/fswd-practice/class-06/pyq-input-types.html

Name: Date of birth: Email:

Type the answer file yourself and confirm this render: an ordinary text box, a box that opens a calendar, and a box that rejects a non-address on submit. Three fields, three correct types — that's the full 2 marks.

DATA → TYPE → FREE BEHAVIOUR · THE MIDDLE COLUMN IS THE 2 MARKS · THE RIGHT COLUMN IS WHY THE TYPES EXIST

Beyond the marks: the exam pays for the middle column; a developer is really choosing the right column — every correct type is a contract the browser honours with free UI and free validation. Wrong type = silently lost behaviour: a DOB in type="text" still renders, but the calendar, the format guarantee and the mobile keypad all quietly vanish. “It looks the same” is not “it is the same” — the difference only shows when a user touches it.

name takes text · date of birth takes date · email takes email, each with a label = full 2 marks ✓ — diagram + depth past the marks, by course rule

SAVE THIS AS

FOLDERC:\Users\student\Desktop\fswd-practice\class-06\

FILENAMEpyq-input-types.html — yes, type the exam answer as a real file; a rendered answer is remembered ten times longer than a read one.

VIEW ITLive Server — confirm the three renders: plain box, calendar picker, address-checking box.

GIT?No commit — exam-practice scratch lives in the sandbox, outside git.

DEPTH FOR THE CURIOUS · THE SHAPE OF A 2-MARK "WHICH TYPE" ANSWER

The examiner wants to see three decisions, each visible: the type per field named in code, and labels attached. Don't write an essay; write the eight lines above and one sentence — "text for free-form names, date for a calendar-picked DOB, email for browser-validated addresses." Naming why each type fits is what separates a 2 from a 1.

FILL-IN-CODE ACTIVITY · 6 MINUTES · ON PAPER OR IN YOUR SANDBOX

The Poshtik order form begins.

This is a historic file: the first piece of the order form that will carry real orders by Unit 4. Below it stands with three holes. Fill all three, then type the whole file into your sandbox and check your render against the solution's preview — use exactly the text shown, so your page and the answer sheet must match character for character.

class-06/order-form-start.html · the whole fileTHREE GAPS TO FILL
1<!DOCTYPE html>
2<html lang="en">
3  <head>
4    <meta charset="UTF-8">
5    <title>Order from Poshtik Campus</title>
6  </head>
7  <body>
8    <h1>Order from Poshtik Campus</h1>
9①  open the form — answers go to /place-order, travelling privately
10      <label for="student-name">Your name:</label>
11②  the input for that label — free-form text, name and id both "student-name"
12      <br><label for="student-email">College email:</label>
13③  the input for that label — the type that checks address shape, name and id both "student-email"
14    </form>
15  </body>
16</html>

Order from Poshtik Campus

file:///C:/Users/student/Desktop/fswd-practice/class-06/order-form-start.html

SAMPLE OUTPUT — YOUR FINISHED FILE MUST RENDER EXACTLY THIS

Order from Poshtik Campus

Your name: College email:

Two labelled boxes under one heading — they LOOK identical, but the email box quietly rejects a non-address on submit, and pressing submit sends the answers privately (no ?name=… tail in the address bar). Those two invisible behaviours are exactly what your three missing lines must switch on.

DRAFT YOUR THREE LINES IN YOUR NOTEBOOK FIRST — PEN BEFORE KEYBOARD

STUCK? TWO HINTS, SPEND THEM SLOWLY

Hint 1: "travelling privately" is one of the two values of method — the one that doesn't show answers in the address bar.

Hint 2: both missing inputs differ by exactly one word: the value of type. Everything else — id matching the label's for, plus a name — is the same discipline both times.

Answer sheet

The order form, complete.

Type your three guesses into the real file first — a wrong type that renders teaches more than a right answer that's read.

SOLUTION SHEET · ORDER-FORM-START.HTML

order-form-start.html — COMPLETE · the whole fileONE LINE PER PRESS
1<!DOCTYPE html>
2<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Order from Poshtik Campus</title>
</head>
<body>
  <h1>Order from Poshtik Campus</h1>
  <form action="/place-order" method="post">
    <label for="student-name">Your name:</label>
    <input type="text" id="student-name" name="student-name">
    <br><label for="student-email">College email:</label>
    <input type="email" id="student-email" name="student-email">
  </form>
</body>
16</html>

Order from Poshtik Campus

file:///C:/Users/student/Desktop/fswd-practice/class-06/order-form-start.html

Order from Poshtik Campus

Your name: College email:

Test with exactly these answers: type P. Ananya into the name box and ananya@vce.ac.in into the email box — then try ananya alone in the email box and watch the browser refuse it.

SAVE THIS AS

FOLDERC:\Users\student\Desktop\fswd-practice\class-06\

FILENAMEorder-form-start.html — the historic file: it walks out of Class 7 complete and becomes the model for Lab 2's real form in poshtik-campus\.

VIEW ITLive Server — run the exact tests from the preview note: P. Ananya, then ananya@vce.ac.in, then ananya alone to watch the refusal.

GIT?No commit yet. It's still sandbox practice. The moment this form's ideas move into poshtik-campus\ (Lab 2), that version gets git add + git commit — real project, real history.

Grade your own attempt — three checks:

Line 9: did you write both action="/place-order" and method="post"? "Travelling privately" was the clue for post — get would print the answers into the address bar.
Lines 11 and 13: does each input's id exactly match its label's for? Click each label in your own render — if the cursor doesn't jump into the box, the pair is broken somewhere.
Both inputs carry a name: without it the answer never leaves the page. Say the rule aloud once: label's for finds the input's id; the server reads the input's name.

Idea six

placeholder & required — hints and guard rails.

Two attributes finish today's vocabulary. placeholder shows grey ghost-text inside an empty box — a hint that vanishes on typing. required is a guard rail: the browser refuses to submit the form while that field is empty. No JavaScript, no server — the browser polices it alone.

MINI PROBLEM · HINTS-AND-RAILS.HTML

PROBLEM

Give one input both a hint and a guard rail: ghost-text that coaches the visitor, and a refusal to submit while the box is empty — all without a single line of JavaScript.

REQUIREMENTS

Save as hints-and-rails.html inside class-06 · title text: Hints and rails
One labelled text input carrying placeholder="e.g. P. Ananya" AND required, on top of the usual type/id/name

EXPECTED OUTPUT

Grey e.g. P. Ananya sits inside the empty box and vanishes at the first keystroke; submitting while empty is refused by the browser itself.

class-06/hints-and-rails.html · the whole fileBUILDS ONE LINE PER PRESS
1<!DOCTYPE html>
2<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Hints and rails</title>
</head>
<body>
  <form action="/place-order" method="post">
    <label for="student-name">Your name:</label>
    <input type="text" id="student-name" name="student-name"
           placeholder="e.g. P. Ananya"
           required>
  </form>
</body>
15</html>

Hints and rails

file:///C:/Users/student/Desktop/fswd-practice/class-06/hints-and-rails.html

Your name: ↑ grey ghost-text e.g. P. Ananya — really there: click in, type one letter, watch it vanish ↑ and with required, submitting while empty is refused — next block shows exactly what that looks like

One input, four attributes, each earning its place: type picks the keyboard and checks, id bonds the label, name ships the answer, placeholder/required guide and guard.

SAVE THIS AS

FOLDERC:\Users\student\Desktop\fswd-practice\class-06\

FILENAMEhints-and-rails.html

VIEW ITLive Server — see the grey ghost-text; click into the box and type one letter — the hint vanishes, exactly the point.

GIT?No commit — sandbox demo.

Forward flag, stated honestly: required is native HTML5 validation — shape-level checks the browser does free. Real validation logic ("is this roll number actually in our college?") needs JavaScript — that's Unit 2 — and server-side re-checking in Unit 4. Guard rails now, brains later.

DIAGNOSIS ACTIVITY · 4 MINUTES · READ THE EVIDENCE

The submit that refused.

A classmate types the file below, opens it, clicks Place order without typing anything — and the form doesn't submit. Instead a small message balloons out of the name box. Your job: from the code and the render, answer three questions before the solution:

What blocked the submit?
Is this an error the Console would show?
Which single word in the code caused it?

class-06/blocked-submit.html · the whole file — the evidenceBUILDS ONE LINE PER PRESS
1<!DOCTYPE html>
2<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Blocked submit</title>
</head>
<body>
  <form action="/place-order" method="post">
    <label for="student-name">Your name:</label>
    <input type="text" id="student-name" name="student-name" required>
    <button type="submit">Place order</button>
  </form>
</body>
14</html>

Blocked submit

file:///C:/Users/student/Desktop/fswd-practice/class-06/blocked-submit.html

This bubble is the browser's own voice — Chrome draws it, words and all. This preview is live: click Place order with the box empty and the browser refuses right here, exactly as drawn. The page never leaves, nothing is sent, and the DevTools Console shows nothing at all.

SAVE THIS AS

FOLDERC:\Users\student\Desktop\fswd-practice\class-06\

FILENAMEblocked-submit.html — type it exactly as shown, including the required attribute; the "bug" is the lesson.

VIEW ITLive Server — click Place order with the box empty and watch the browser refuse. Then open DevTools (F12), Console tab: zero red lines.

GIT?No commit — diagnosis drills stay in the sandbox.

MY DIAGNOSIS — WRITE THE THREE ANSWERS IN YOUR NOTEBOOK BEFORE PEEKING

Answer sheet

Reading the refusal correctly.

Write your three answers down first — especially the Console one. It's the trap.

The three answers, and why the third one matters most:

What blocked the submit? The browser's native HTML5 validation. Before sending any form, the browser checks every required field; the empty name box failed, so the browser cancelled the send and drew the bubble itself.
Would the Console show an error? No — and this distinction is the whole lesson. Open DevTools and look: zero red lines. A validation bubble is not a JavaScript error; nothing crashed, nothing ran wrong. The Console reports code failures; this was the browser working exactly as designed. When JS arrives in Unit 2, you'll meet real Console errors — knowing which voice is speaking is a debugging superpower.
The single word responsible: required on line 3. Delete it and the empty form submits happily — straight to a server that doesn't exist yet, but that's Unit 4's problem.

DEPTH FOR THE CURIOUS · TRY ALL THREE REFUSALS

In your own file, collect the full set — three different bubbles, all free, all before a single line of JavaScript:

Submit empty — "Please fill out this field."
Change the input to type="email", type ananya, submit — "Please include an '@' in the email address."
Add required to an email input and submit empty — the required message wins.

SELF-STUDY · TEN QUIET MINUTES AT HOME

The input-type quick reference.

You met five types today. HTML5 ships more — none needs a lesson, all appear in real codebases and quiz options. Read once at home; recognition is the goal, not memorisation.

TYPE	WHAT THE BROWSER GIVES YOU	USE IT FOR
text	Plain single-line box	Names, roll numbers, anything short and free-form
email	Address-shape check on submit; @ key on phone keyboards	Email addresses
password	Typed characters masked as dots	Passwords — masking only; real security is server-side (Unit 4)
date	Calendar picker; value always YYYY-MM-DD	DOB, delivery dates
time	Clock picker	Pickup-time slots
tel	Number keypad on phones; no format check (world phone formats vary too much)	Phone numbers
number	Digits only, step arrows, min/max attributes	Quantities — "3 wraps"
range	A slider	Ratings, volume-style values
color	A colour-picker swatch	Theme choices
file	A Browse… button	Uploads — needs server support (Unit 4)
url	URL-shape check on submit	Website addresses
search	Text box with a clear-✕ on most browsers	Search bars
hidden	Renders nothing; still submits its name=value	Data the page knows but the user shouldn't edit
checkbox / radio	Tick square / choice dot	Class 7's whole story — tomorrow's class
submit / button	Clickable buttons	Sending — also properly told in Class 7

ONE PATTERN TO NOTICE ACROSS THE WHOLE TABLE

Every row is the same trade: tell the browser your intent (this is a date, this is a number) and the browser pays you back with a picker, a keypad, a check — for free. That is the semantics-over-styling principle from Class 3, now running your forms. The wrong habit — type="text" for everything — works, renders, and silently throws all those gifts away.

Wrap

What you can do now that you couldn't at 9 am.

Wrap questions in a <form> and explain where its answers go, and how

Pick the honest input type — text, email, date, tel, number — per question

Bond every label to its input and prove it with a click

Read a validation bubble for what it is — the browser's voice, not a code error

YOUR FOLDERS AFTER TODAY — CHECK BEFORE YOU LEAVE

Desktop\fswd-practice\ <- sandbox · NOT a git repo · never committed

│ class-02\ … class-05\ <- earlier classes, untouched

└─ class-06\ <- created today · 7 files

├─ first-form.html

├─ two-inputs.html

├─ labelled.html

├─ pyq-input-types.html

├─ order-form-start.html <- grows again in Class 7

├─ hints-and-rails.html

└─ blocked-submit.html

Desktop\poshtik-campus\ <- real project · IS a git repo · still 3 files, unchanged today

├─ index.html

├─ menu.html

└─ about.html

The git rule, said once for the whole class: fswd-practice\ is scratch paper — no repo, no commits, throw files away freely. poshtik-campus\ is the real project you put under git in Lab 1 — every meaningful change there ends with git add . then git commit -m "…". Today we never opened it, so today needs zero commits. Lab 2 will change it — and that day, committing is not optional.

Homework — in your sandbox.

Finish the file: extend order-form-start.html with two more labelled fields — Phone: as type="tel" (id and name student-phone) and Delivery date: as type="date" (id and name delivery-date). Make all four fields required.
Collect the refusals: trigger all three validation bubbles from today's depth note and write each message down word-for-word.
Exam rep: write the P2·Q2 answer once from memory on paper — eight lines, three types, timed at three minutes.

Next class the form learns to offer choices: radio buttons (and the name-collision bug that breaks them — a past exam question fixes it), checkboxes for protein add-ons, dropdowns, and the real submit button. The order form you started today walks out of Class 7 complete.

Class 7 · Forms part 2 — choices & buttons Back · Class 5 · Tables Unit 1 overview