Class 3 · 60 minutes
Core HTML tags: structure, text, and the skeleton every page wears.
Last class you wrote six lines and the browser obeyed. Today you learn what those six lines actually were — and then you go far past them: headings, paragraphs, emphasis, comments, lists, images. By the end of this hour the page on your screen stops being "the hello file" and starts being a real menu for a real project.
Every tag you meet today you will meet twice: once as code on the left, once as what the browser renders on the right. Nothing stays abstract. And one of today's pages belongs to a project you'll be building for the rest of this course — its first appearance is a humble list, and that's exactly how real products start.
Idea one
The skeleton: six lines every page you'll ever write begins with.
Last class you typed hello.html and it worked. But four of its lines you typed on faith. Today the faith ends — here is the whole skeleton, and what each line is actually doing for you.
- Save as
skeleton.htmlinsideclass-03in yourfswd-practicefolder - Full skeleton: doctype,
<html lang="en">, head with<meta charset="UTF-8">and a title, then the body - Title text: My Page · body text: one sentence of your choice
<!DOCTYPE html><html lang="en"> <head> <meta charset="UTF-8"> <title>My Page</title> </head> <body> Everything you SEE goes here. </body></html>Everything you SEE goes here.
C:\Users\student\Desktop\fswd-practice\class-03\skeleton.html — the first file of your sandbox; every later file today starts from this skeletonFrom this page until the last page of this course, every HTML example ships the whole skeleton. Never a floating <h1> with no home, never a snippet you can't actually save and open. What you see in a code panel is always a complete, valid file — copy it, save it, double-click it, and it works.
The only exceptions: a tag named mid-sentence in prose (like this <p> just now), and short reference-table rows. Anything presented as runnable is complete — that's the deal.
Here's a strange fact: if you delete the doctype, the head, even the <html> tag itself — most pages still sort of render. Browsers are heroically forgiving, because the web is full of broken pages and browsers compete on never showing a blank screen. So why bother with the skeleton at all?
Because "sort of renders" is where bugs breed. Without <meta charset="UTF-8"> your page works until the first non-English character. Without lang a screen reader mispronounces everything. Without the doctype, CSS measurements behave differently in ways that will cost you an afternoon in Unit 1's CSS classes. Professionals ship the full skeleton not because pages die without it — but because pages misbehave subtly without it, and subtle is expensive.
Idea two
Headings: a chain of command, not a font menu.
HTML gives you six heading tags, <h1> down to <h6>. Yes, they get smaller as the number grows — but size is the least important thing about them. They declare rank: the page's one main title, its sections, its sub-sections.
- Save as
headings.htmlinsideclass-03 - Full skeleton · title text: Heading Ranks
- One of each:
<h1>through<h6>, each with text describing its own rank
<h1> to <h6>; the tab reads Heading Ranks.<!DOCTYPE html><html lang="en"> <head> <meta charset="UTF-8"> <title>Heading Ranks</title> </head> <body> <h1>Page title — one per page</h1> <h2>A major section</h2> <h3>A sub-section of that</h3> <h4>Rarely needed</h4> <h5>Almost never</h5> <h6>You may retire without using this</h6> </body></html>C:\Users\student\Desktop\fswd-practice\class-03\headings.html"I want smaller text, so I'll use <h4>" — that's the wrong instinct, and Unit 1's CSS classes will show you the right one (any tag can be any size once CSS arrives). Choose the heading number by asking one question only: what rank does this title hold on this page? One <h1> per page, <h2> for its major sections, <h3> inside those. Screen readers let users jump heading-to-heading like a table of contents — a page with honest ranks is navigable; a page that picked tags for their looks is a maze.
Save headings.html, then deliberately mix it up: swap the <h1> and the <h5>. The page still renders — no error, no warning. That silence is the lesson: HTML never complains about bad structure, it just quietly becomes worse HTML. The browser doesn't care. Screen-reader users, search engines, and the teammate who inherits your code care enormously.
While you're in there: put your own name in the <h1> and your branch and section in an <h2>. Every file you personalise is one you'll remember.
Idea three
Paragraphs, emphasis, and the line-break question.
Headings are the signposts; paragraphs are the road. Three small tags handle almost all running text — and two of them carry meaning, not just styling.
<strong> and <em> add meaning (not just looks), and only <p> and <br> control line breaks — your Enter key controls nothing.- Save as
text-tags.htmlinsideclass-03· title text: Text Tags - Paragraph 1: contains a
<strong>phrase, and is deliberately typed across several source lines - Paragraph 2: stresses one word with
<em> - Paragraph 3: a two-line address using a single
<br>
<strong> phrase bold; paragraph 2 shows one italic word; the address breaks exactly once — at the <br>.<!DOCTYPE html><html lang="en"> <head> <meta charset="UTF-8"> <title>Text Tags</title> </head> <body> <p>Order in a lecture break and your food reaches your hostel block <strong>before the break ends</strong>.</p> <p>Eating well should be the <em>fast</em> option, not the slow one.</p> <p>Hostel Block C<br>Room 214</p> </body></html>Order in a lecture break and your food reaches your hostel block before the break ends.
Eating well should be the fast option, not the slow one.
Hostel Block C
Room 214
C:\Users\student\Desktop\fswd-practice\class-03\text-tags.html — type paragraph one across several source lines on purpose; watching those Enter keys vanish is the lesson<strong> says "this matters — don't miss it." <em> says "stress this word when reading aloud." A screen reader genuinely changes its voice for them. They happen to render bold and italic — but you're marking importance, not decorating. When you only want the look with no meaning, CSS will give you that properly in a few classes.
Ask: is this a new thought or the same thought continuing on a new line? A new thought earns a new <p>. The same thought with a forced break — an address, lines of a poem — takes <br>. If you find yourself typing <br><br> to fake paragraph spacing, stop: that's a paragraph asking to exist.
HTML treats any run of spaces, tabs, and newlines as one single space — the rule is called whitespace collapsing. It's why you can format your code beautifully across many lines and the paragraph still renders as one flowing sentence. Your Enter key formats the code; <p> and <br> format the page. Two different worlds, and today you learned which key belongs to which.
Also worth noticing: <br> has no closing tag — like <meta>, it's a void tag: it doesn't wrap content, it just is. You'll meet one more void tag today: <img>.
Idea four
Comments: notes the browser never shows.
Anything between <!-- and --> is invisible on the page. It exists only in the code — a note from you, to future-you, or to a teammate. It looks like a small feature. It's actually a debugging superpower.
- Save as
comments.htmlinsideclass-03· title text: Comments - An author-note comment with your name and roll number at the top of the body
- An
<h1>, then a whole<p>wrapped inside<!-- -->, then one normal visible<p>
<!DOCTYPE html><html lang="en"> <head> <meta charset="UTF-8"> <title>Comments</title> </head> <body> <!-- Written by K Student, Roll 733001 --> <h1>Today's Specials</h1> <!-- <p>Out of stock till Monday.</p> --> <p>Fresh millet bowls at the counter.</p> </body></html>Fresh millet bowls at the counter.
C:\Users\student\Desktop\fswd-practice\class-03\comments.html — put YOUR name and roll number in line 8's author noteLabel who wrote a file, mark where a section starts, leave a warning for the next reader. Code is read far more often than it's written — a one-line note today saves a teammate (or October-you) twenty minutes of head-scratching.
Here's the habit worth building from today: when a page misbehaves, don't delete suspect lines — comment them out. Wrap the suspect in <!-- -->, reload, observe. Problem gone? You found your culprit — and the code is still right there to fix rather than retype. It's an undo button you control.
The rule: comments don't nest. The first --> the browser meets ends the comment, so you can't wrap a comment inside another comment.
The warning: comments are invisible on the page, not in the file. Anyone can press Ctrl+U in Chrome and read your page's full source, comments included. Never leave passwords, keys, or anything private in a comment — later in this course you'll learn where secrets actually belong, and it is never in HTML.
Idea five · a project begins
Lists — and the first real page of something bigger.
Quietly, this course has a destination. Over the coming Labs you'll build a real food-ordering site for a campus problem you know personally: by the time you reach the mess counter, the healthy options are gone. The project is called Poshtik Campus — and every product like it begins exactly the way yours does today: with a menu, typed as a list.
- Save as
menu.htmlinsideclass-03· title text: Poshtik Campus Menu <h1>page title, then<h2>Today's Healthy Ten followed by a<ul>of ten dishes<h2>How Ordering Works followed by an<ol>of the three steps: browse, then order, then collect- Do NOT type any bullet symbols or numbers yourself
<!DOCTYPE html><html lang="en"> <head> <meta charset="UTF-8"> <title>Poshtik Campus Menu</title> </head> <body> <h1>Poshtik Campus Menu</h1> <h2>Today's Healthy Ten</h2> <ul> <li>Jonna Rotte Wrap</li> <li>Sajja Roti Wrap</li> <li>Ragi Sangati Bowl</li> <li>Ragi Idli Bowl</li> <li>Pesarattu with Sprouts</li> <li>Ulava Charu Protein Bowl</li> <li>Gongura Sprouts Salad</li> <li>Sprouts Moong Chilla</li> <li>Paneer Protein Bowl</li> <li>Millet Protein Shake</li> </ul> <h2>How Ordering Works</h2> <ol> <li>Browse the menu in your break</li> <li>Place your order</li> <li>Collect at your hostel block</li> </ol> </body></html>- Jonna Rotte Wrap
- Sajja Roti Wrap
- Ragi Sangati Bowl
- Ragi Idli Bowl
- Pesarattu with Sprouts
- Ulava Charu Protein Bowl
- Gongura Sprouts Salad
- Sprouts Moong Chilla
- Paneer Protein Bowl
- Millet Protein Shake
- Browse the menu in your break
- Place your order
- Collect at your hostel block
Bullets. Use when the items are equals and sequence carries no meaning — a menu, ingredients, features. Reshuffle the dishes and the menu means exactly the same thing.
Numbers, generated by the browser — you never type "1." yourself. Use when sequence is the meaning: steps, rankings, instructions. Add a step later and the browser renumbers everything for free.
<li>
An <li> lives only as a direct child of a <ul> or an <ol> — never loose on its own. And notice the nesting shape in the code: open list, items inside, close list — everything opened gets closed, inside-out, like stacked tiffin boxes.
C:\Users\student\Desktop\fswd-practice\class-03\menu.htmlCreate class-03 inside your fswd-practice folder before saving — from now on, each class's files live in that class's own subfolder, so October-you can find anything in seconds. Missed last class and don't have fswd-practice yet? Make it on your Desktop first — five seconds — then carry on. And to be clear: this menu page is sandbox practice. The real Poshtik Campus site starts life in its own folder at Lab 1 — today you're rehearsing the moves.
The menu isn't random. Jonna (sorghum), sajja (pearl millet), ragi, ulavalu (horse gram), pesarattu, gongura — that's genuine Telangana–Andhra home food, the kind the mess runs out of first. The chilla, paneer bowl, and protein shake round it out for everyone. These exact ten items will follow you through this whole course: they'll get prices in a table (Class 5), an order form (Classes 6–7), styling (Class 9), and eventually live in a real database (Unit 4). Learn the list once — it pays rent for five units.
Your turn · no peeking
Call the render.
Below is a complete file. Before anyone opens it in a browser, write down — on paper or in the box — exactly what the browser window will show, top to bottom. Not roughly: exactly. How many visible lines? Which are big, which are bulleted, which are numbered? Does anything in the file not appear at all?
<!DOCTYPE html><html lang="en"> <head> <meta charset="UTF-8"> <title>Snack Counter</title> </head> <body> <h1>Evening Snacks</h1> <!-- <h2>Fried Corner</h2> --> <p>Only <strong>healthy</strong> options after 4 pm.</p> <ol> <li>Sprouts Moong Chilla</li> <li>Millet Protein Shake</li> </ol> </body></html>1) What does the browser tab say? 2) How many elements render in the window? 3) Bullets or numbers — and why? 4) What happens to line 9 and to the words "Snack Counter"? Write your answers down — a prediction you didn't write down is a guess you can quietly revise after seeing the answer, and that teaches you nothing.
The reveal
What the browser actually shows.
Commit to your prediction first — then check.
<title>Snack Counter</title> <h1>Evening Snacks</h1> <!-- <h2>Fried Corner</h2> --> <p>Only <strong>healthy</strong> options… <ol> …two items… </ol>Only healthy options after 4 pm.
- Sprouts Moong Chilla
- Millet Protein Shake
C:\Users\student\Desktop\fswd-practice\class-03\predict.html — type the full 17-line file from the activity above, exactly as printed- The tab reads Snack Counter — the <title> renders in the tab bar, never in the window. If you predicted "Snack Counter" as a visible heading, that's the head/body boundary asking for one more look.
- Three elements render: one big heading, one paragraph with a single bold word, one list.
- Numbers, not bullets — line 12 opens an <ol>, so the browser numbers the items itself. Nobody typed "1." anywhere in the file.
- Line 9 renders nothing. A whole <h2> sits commented out — present in the file, absent from the page. The counter clearly stopped selling fried snacks and simply switched the section off. If you caught all four: you didn't just read code, you executed it in your head. That skill is the whole point of today.
Idea six
Images — and the attribute that speaks when pictures can't.
One tag puts a picture on a page: <img>. It's a void tag — nothing to wrap, nothing to close — and it depends completely on two attributes: src, which says where the picture is, and alt, which says what the picture means.
- Save as
dish.htmlinsideclass-03· title text: Dish of the Day <h1>, then an<img>withsrc="assets/ragi-sangati.jpg"(a relative path — it starts from where dish.html lives)- An
altthat genuinely describes the dish — notalt="image" - One caption paragraph under the image
<!DOCTYPE html><html lang="en"> <head> <meta charset="UTF-8"> <title>Dish of the Day</title> </head> <body> <h1>Dish of the Day</h1> <img src="assets/ragi-sangati.jpg" alt="Ragi sangati bowl served hot with ulava charu"> <p>Ragi Sangati Bowl — today's special.</p> </body></html>Ragi Sangati Bowl — today's special.
C:\Users\student\Desktop\fswd-practice\class-03\dish.htmlalt text renders in its place. That's the safety net working, not a bug.Who reads your alt text? More people than you think.
Hears your alt text read aloud in place of the image. With it, they order lunch like everyone else. Without it, the reader says "image" — a menu of ten dishes becomes "image, image, image" ten times.
When the image fails to load — slow network, broken path, renamed file — the browser renders the alt text in its place. Your page degrades to something still usable instead of a broken-picture icon.
A crawler cannot see your photo. Your alt text is what tells it this page shows a ragi sangati bowl — which is how a hungry student searching for one finds your site at all.
Writing alt that earns its place
alt="image" — says nothing a broken-picture icon doesn't already say.
alt="photo of food" — which food? A fried snack? The entire point is lost.
alt="Ragi sangati bowl served hot with ulava charu" — a person who can't see the photo now knows exactly what's on offer.
alt="" — empty, on purpose, for purely decorative images: it tells a screen reader "skip this, it carries no meaning." Deliberate silence is also a choice.
Notice what just happened: a page that looks identical either includes or excludes people, depending on one attribute you can't even see in the render. Building for people who browse differently than you do is a thread that runs through this entire course — it starts here, on your very first image, on the very first day you could make the choice.
Want to watch the safety net catch a fall? In dish.html, change line 9's src to a filename that doesn't exist — assets/wrong-name.jpg — and reload. The photo vanishes; your alt text appears in its place. Fix the path, reload, and the photo returns. You've just debugged the single most common image bug on the web: the path that points at nothing.
A quiet detail worth noticing: lines 9–11 are one tag spread across three lines. HTML allows that — the tag ends at the >, not at the end of a line. When attributes get long, wrapping them keeps code readable.
Your turn · a real repair job
The case of the swallowed menu.
The canteen's weekend-specials page shipped last night, and this morning it looks wrong — everything below the title has ballooned to heading size. Here is the exact file and the exact render. The bug is one missing thing on one line. Your job: work out what's missing using only what the render is telling you — then type the file, reproduce the damage, and repair it yourself.
<!DOCTYPE html><html lang="en"> <head> <meta charset="UTF-8"> <title>Weekend Specials</title> </head> <body> <h1>Weekend Specials <p>Saturday and Sunday only — order by 11 am.</p> <ul> <li>Ragi Idli Bowl</li> <li>Gongura Sprouts Salad</li> </ul> </body></html>Saturday and Sunday only — order by 11 am.
- Ragi Idli Bowl
- Gongura Sprouts Salad
Don't stare at the code first — interrogate the symptom. Three questions crack it: 1) What property went wrong? Everything is huge and bold — that's heading styling. 2) Where does the damage start? The title itself looks right; the wrongness begins immediately after it and never stops. 3) What kind of bug behaves like that? Something that opened and never closed — because everything that follows falls inside it and inherits its look. Now read line 8 again, character by character, against line 8 of menu.html.
C:\Users\student\Desktop\fswd-practice\class-03\specials.htmlIn most programming languages, a missing closer is a hard stop: the program refuses to run and points at the guilty line. HTML made the opposite bet. The web's founding rule was never show a blank page — a browser that refused to render every imperfect file would have refused half the early web. So when Chrome hit the unclosed <h1>, it didn't stop; it guessed. It decided the paragraph and the whole list must belong inside the heading, adopted them as its children, and rendered that guess with a straight face.
That bet is why HTML debugging is a skill of the eyes, not of error messages. Your compiler is the render itself — and today's three questions (what property went wrong, where does the change start, what opens-but-never-closes behaves this way) are the same three you'll use on real projects for years. One more tool from earlier today: if reading doesn't find it, comment out line 8, reload, and watch the problem vanish — you've found your line.
The repair
One line, five characters, whole page restored.
Write your diagnosis down first — the render gave you everything you need.
<body> <h1>Weekend Specials <p>Saturday and Sunday only…</p> <ul> <li>Ragi Idli Bowl</li> <li>Gongura Sprouts Salad</li> </ul> </body> <body> <h1>Weekend Specials</h1> <p>Saturday and Sunday only…</p> <ul> <li>Ragi Idli Bowl</li> <li>Gongura Sprouts Salad</li> </ul> </body>Saturday and Sunday only — order by 11 am.
- Ragi Idli Bowl
- Gongura Sprouts Salad
With no </h1>, the browser had to decide where the heading ends — and its rule is "keep swallowing until something forces me to stop." The paragraph didn't force it. The list didn't force it. So they became the heading's children, and children inherit their parent's presentation: heading-sized, heading-bold. The moment you type the five characters </h1>, the heading's territory ends on line 8, and everything after it stands on its own again. Every opened tag claims a territory — the closer is what says where that territory stops.
- Could you name the symptom family? "Everything after point X inherits a look it shouldn't have" almost always means an unclosed tag at point X. File that pattern away — it pays for itself many times this semester.
- Did you catch it from the render alone? If you needed the code side, that's fine today — but re-run the three questions until the render alone is enough. That's the skill being built.
- Did you reproduce it in your own sandbox? Typing the bug, watching it break, and fixing it teaches your fingers what your eyes just learned. Ten minutes, and unclosed-tag bugs lose their power over you permanently.
Three small tags worth meeting before they meet you.
None of these need a full lesson — but all three appear in real pages and in exam papers, so ten quiet minutes of self-study buys you recognition forever. Each row shows the tag, its job, and exactly what it renders as.
<blockquote>Best millet bowl on campus.</blockquote>H<sub>2</sub>O and x<sup>2</sup><br> and <img>: nothing to close. Just <hr> on its own line.Lunch menu
Open a new file, small-tags.html, in your class-03 folder — full skeleton first, as always. Give it one blockquote (a real review a friend might write about your canteen), one line of chemistry, one squared number, and an <hr> between two menu sections. You now know eleven tags — enough to mark up most of a real page's text.
Idea seven · a habit, declared once
Indentation: the house style we keep from here forward.
Look back at every code panel today — none of it was flat against the left margin. That shape wasn't decoration. The browser ignores indentation completely (whitespace collapsing, remember) — it exists purely for human readers. And you just spent a whole debugging drill being one.
Not a tab, not four — two, every time. VS Code's default matches. What matters most isn't the number, it's that the whole file (and this whole course) agrees on one.
<head> and <body> sit inside <html>, so they indent one step. An <li> lives inside a <ul>, so it steps in once more. Depth on the screen equals depth in the structure.
All ten menu <li>s in menu.html start at the same column — your eye reads them as one family at a glance, before reading a single word.
</ul> directly below its <ul>, </body> below <body>. Scan straight down from any opener and its closer is waiting on the same vertical line — or it's missing, and now you can see that.
Well-indented HTML is a picture of its own structure — parents, children, and siblings visible as pure shape. Flat HTML is a wall where every relationship must be worked out tag by tag. Same file, same render; wildly different cost to every human who touches it after you.
Today's swallowed-menu bug is visible as a shape in well-indented code: an opener whose column never gets its closer back. Indent honestly and half your future unclosed-tag bugs get caught by your eyes before the browser ever sees them. Sloppy indentation doesn't break pages — it hides the things that do.
Every snippet in this course follows these four rules from here to the final class — and so does every file you submit. Not because tidy code scores marks by itself, but because in a few weeks your pages will be fifty lines deep in nested tags, and the habit you build on ten-line files is the only thing that makes fifty-line files readable. Start now, while it's cheap.
VS Code will indent as you type, and it can repair a messy file in one stroke: right-click anywhere in the editor and choose Format Document (or Shift+Alt+F). Try it: paste your menu.html with all the indentation deliberately mangled, format, and watch the structure snap back. The editor automates the habit — but it can only format a file whose tags are correctly opened and closed, which is one more quiet reason the closers matter.
Wrapping up
Sixty minutes ago, tags were mysterious. Now you read them like a menu.
fswd-practice\class-03\ now holds eight files: skeleton.html · headings.html · text-tags.html · comments.html · menu.html · predict.html · dish.html · specials.html — plus small-tags.html if you did the self-study drill. Don't delete any of them; Class 4 builds directly on this folder, and menu.html in particular has a long life ahead of it.
fswd-practice\ is scratch paper: no repo, no commits, delete freely. poshtik-campus\ is the real project that goes under git in Lab 1. Today every file landed in the sandbox, so today needs zero commits.
Make about-me.html in class-03\:
- Full skeleton.
- Your name in the
<h1>. - An
<h2>per section (branch, hobbies, favourite canteen order). - One paragraph with a
<strong>and an<em>used for their meaning. - One list of each type.
Sabotage a copy of menu.html: remove one closing tag — your choice which — and study the render before fixing it. Do this three times with three different tags. You're building a private catalogue of what each breakage looks like.
On any real site you visit after class, press Ctrl+U and spend two minutes in the source. Count how many of today's eleven tags you can spot in the first screen. Real pages are longer — but they are made of exactly what you learned today.
A friend's page shows their whole footer in giant bold text, and there's no error anywhere. In one sentence: what family of bug do you suspect, and what's the first thing you'd look for in their code?