Organize Content with Semantic HTML

HTML is not only a way to place words on a page. A semantic element describes the purpose of its content.

Ask: “What is this content?” rather than “How do I want it to look?” CSS can later change appearance, but it does not change what the HTML element means.

A <div> is useful when you need a generic grouping and no more specific purpose applies. It does not identify the kind of content inside it.

These snippets can occupy a similar block in an unstyled page. The first is a generic group; the second identifies a paragraph. Choose based on the content’s purpose, not on a default visual effect.

Semantic HTML can identify the broad parts of a page before styling is added. For the garden page:

• A page-level <header> contains introductory content.
• A <nav> contains a major navigation block.
• A <main> contains the page’s dominant content.
• A page-level <footer> contains closing information.

These native elements create recognizable page landmarks that browsers can expose to assistive technologies. This ordinary page has one visible <main> element.

Create or replace your local garden.html with this page-region skeleton. Save it and refresh the browser. Later steps add the detailed main content, but this source order already identifies the page’s broad regions.

Heading elements describe a topic relationship, not a preferred text size. <h1> is the page title; <h2> introduces a major topic; <h3> introduces a subtopic within that major topic.

For this page, use one descriptive <h1>: Maple Community Garden. The major topics are Visit the Garden and Garden News, so they are siblings at the same <h2> level. Their related subtopics use <h3>.

Use explicit heading levels in the markup. Putting a heading inside another container does not change its level.

Do not skip from an <h2> to an <h4> when opening a subtopic. After an <h3> subtopic, another <h3> is a sibling subtopic. Returning to <h2> starts the next major topic.

This heading order describes the garden page from its overall subject to its subtopics.

A <section> groups one thematic part of a larger document. It normally begins with a heading that names that topic.

An <article> is a self-contained composition: its content should still make sense if it is encountered independently. A news announcement is a common example.

For the garden page, Garden News is a topic within the main content, so it is a <section>. Seed Swap is one complete announcement within that topic, so it is an <article>.

Add this structure inside the existing <main> in your local garden.html. The broader topic and the announcement keep the heading levels already established for the page.

A list is structure, not decoration. Choose the element from the relationship between the items:

• An unordered list is a collection: moving an item does not change what the collection means.
• An ordered list is a sequence: moving an item changes the instructions.

For the garden page, supplies are a collection, while work-session instructions are a sequence. Browser bullets and numbers are only one possible visual result; native list structure communicates the meaning.

In these simple lists, each item is marked with an <li> element nested directly inside its list container. Do not type bullet characters or step numbers into separate paragraphs: paragraphs do not provide native list structure.

Inside the existing <main> in your local garden.html, add the complete Visit the Garden section below. It includes its id, heading hierarchy, and both lists.

Add this complete section inside <main> in garden.html.

Source order is the sequence in which content appears in the HTML markup. Before any styling is added, that sequence should read like a clear document: introductory content, navigation, primary content, then closing information.

A heading hierarchy describes which topics belong under other topics. Source order describes when each topic and its content are encountered. Put a heading before the material it introduces, and keep instructions in their intended sequence.

This body content reads coherently from top to bottom. The markup—not its unstyled appearance—communicates the page regions, topic relationships, and list meaning.

You have now chosen each structure for its meaning. The final task is to assemble those choices in one local document and check two things:

1. The unstyled browser view has a coherent reading sequence.
2. The source markup communicates why each part exists.

A readable page is useful evidence, but it is not enough by itself. Inspect the source as well: page regions identify major areas, heading levels show topic relationships, section and article express different kinds of grouping, and list types show whether order matters.

In your local editor, replace the contents of garden.html with this complete document. Save the file, then refresh it in your browser. The page should be understandable in its plain browser-default view, with no CSS, JavaScript, or external assets.

Save this as garden.html, then refresh your local browser tab. Use the expected result to check the reading sequence, then use the checklist below to verify the markup itself.

Compare your source and browser result with this checklist:

• The page-level regions are siblings inside <body> and occur in source order from introductory content through closing information.
• There is one visible <main> containing the dominant page content.
• Heading levels express the topic relationships without a skipped level.
• Each thematic grouping has the appropriate section structure, while the announcement is a self-contained article.
• The supplies are an unordered list, and the work-session instructions are an ordered list.
• In the unstyled browser view, every heading appears before the content it introduces and the instructions remain in their intended sequence.

If something looks readable but fails a source check, revise the markup rather than relying on appearance.