Goal
Before writing any HTML for a real page, you’ll practice identifying the correct semantic structure first, the deliberate planning step that ties together every element choice from Parts 1-2 of this course.
Learn
A genuinely well-structured page starts with a plain-language structural plan, before any actual tags get written. For a typical page, this means identifying: what’s the single main heading and topic (Part 1.3)? What’s genuine standalone content versus supplementary content (Part 2.3’s article/aside distinction)? Which regions are navigation, main content, and footer? Are there any forms, and if so, what data are they genuinely collecting (Part 3)?
This planning step directly determines which semantic elements you’ll actually use, before getting into the details of writing correct markup for each one. Skipping this step is exactly how pages end up with div-heavy, non-semantic structure — not because a developer doesn’t know semantic elements exist, but because they started writing tags before deciding what the page’s actual structural regions and content types really are.
For example, planning a simple blog homepage might identify: one <header> (site title, <nav> for main menu), one <main> containing several <article> elements (blog post previews, each genuinely standalone content), possibly one <aside> (a sidebar with recent comments, tangentially related but not essential), and one <footer> (copyright, secondary links). This plan, decided before writing any tags, directly and confidently determines the actual markup that follows.
Decision Task
You’re planning a recipe page: a title, ingredient list, step-by-step instructions, and a comments section at the bottom. Before reading on: which parts of this page are genuinely standalone content (article), and which is more clearly a distinct, separate region?
Show Answer
The recipe itself (title, ingredients, instructions) is genuinely standalone content that could be shared or syndicated independently — a strong <article> candidate. The comments section is a distinct, separate region, not part of the recipe’s own standalone content — it would typically sit as its own section, outside (or as a sibling to, not nested inside) the article representing the recipe itself.
Common Mistake
Starting to write actual HTML tags before deciding on the page’s structural plan in plain language first. This is exactly how div-heavy, non-semantic markup happens in practice — not from ignorance of semantic elements, but from skipping the planning step that would have clearly indicated which elements actually fit each region.
Practice Questions
1. Plan (in plain language, no tags needed) the structural regions of a simple “About Us” company page with a header, company history text, a team member list, and a footer.
Show Answer
Reasonable plan: header (logo/nav), main containing the history as one article or section, team member list as another section (or list of articles if each member bio is genuinely standalone), footer (contact info, copyright).
2. Why does planning structure in plain language before writing tags help prevent div-heavy markup?
Show Answer
It forces identifying the genuine semantic role of each region first, making the correct element choice obvious and deliberate, rather than defaulting to generic divs out of not having thought through the actual structure yet.
3. In the recipe page example, why is the comments section not nested inside the article representing the recipe?
Show Answer
Comments are a distinct, separate region from the recipe’s own standalone content — nesting them inside the article would misrepresent them as part of the recipe’s core content, when they’re really a separate related feature.
4. True or False: planning structure before writing tags is only useful for genuinely complex pages, not simple ones.
Show Answer
False — even simple pages benefit from this deliberate planning step, since it’s exactly what prevents defaulting to non-semantic divs out of habit, regardless of page complexity.
5. What four planning questions does this lesson suggest asking before writing any HTML?
Show Answer
What’s the main heading/topic? What’s standalone vs. supplementary content? Which regions are nav/main/footer? Are there forms, and what do they collect?
Try It Yourself
Before moving to the next lesson, plan out (in plain language) the semantic structure of a portfolio website homepage of your own choosing — what regions would it have, and which semantic elements would each likely use? This isn’t graded, but skipping it will make the next lesson’s build harder to follow concretely.
This is an open, ungraded reflection exercise — there is no single correct answer to reveal.
Quick Check
1. What should happen before writing any actual HTML tags for a new page, according to this lesson?
Show Answer
A plain-language structural plan identifying the page’s genuine regions and content types.
2. Why does skipping this planning step commonly lead to div-heavy markup?
Show Answer
Because the developer hasn’t yet identified the genuine semantic role of each region, making generic divs the easy default rather than a deliberate semantic choice.
3. In the recipe example, what specific content is the strongest candidate for <article>?
Show Answer
The recipe itself (title, ingredients, instructions) — genuinely standalone, shareable content.
4. Does planning structure only matter for complex pages?
Show Answer
No — even simple pages benefit, since the planning step is what prevents defaulting to non-semantic markup regardless of complexity.
5. What determines which semantic elements you’ll actually use for a page?
Show Answer
The structural plan identified during this planning step, based on the page’s genuine content types and regions.