003: Text and Content Elements

Learning outcomes

By the end of this lesson, you can mark up an article with meaningful headings, paragraphs, emphasis, importance, lists, thematic breaks, and line breaks; explain the limited block/inline mental model; and build a logical heading hierarchy independent of visual size.

Prerequisites and retrieval

Begin with the valid index.html from lesson 002. Before adding anything, explain the difference between title and h1, then sketch the document's DOM tree. Keep the central idea from the previous lesson in view: HTML describes meaning, not the font size you happen to want.

Terminology

Heading: Headings h1–h6 title their sections and communicate hierarchy. — Source: WHATWG: Sections and headings
Hierarchy: The nested parent/child relationship of topics expressed by descending heading ranks. — Source: WHATWG: Sections and headings
Paragraph: “The p element represents a paragraph.” — Source: WHATWG: The p element
Emphasis: “The em element represents stress emphasis of its contents.” — Source: WHATWG: The em element
Strong importance: “The strong element represents strong importance, seriousness, or urgency for its contents.” — Source: WHATWG: The strong element
Ordered list: “The ol element represents a list of items, where the items have been intentionally ordered.” — Source: WHATWG: The ol element
Unordered list: “The ul element represents a list of items, where the order of the items is not important.” — Source: WHATWG: The ul element
Thematic break: “The hr element represents a paragraph-level thematic break.” — Source: WHATWG: The hr element
Phrasing content: Text-level content that forms paragraphs; the category governing what may occur inside p. — Source: WHATWG: Content models
Line break (br): "The br element represents a line break." — Source: WHATWG: The br element
List item (li): "The li element represents a list item." — Source: WHATWG: The li element
Content model: "Content categories (flow, phrasing, heading) define what an element may contain." — Source: WHATWG: Content models
Bold (b) / Italic (i): "b — bring attention to text without extra importance; i — text in an alternate voice." — Source: WHATWG: Text-level semantics and MDN: b element

Mental model: outline first, sentences second

Start with the shape of the document. A textbook's table of contents is a useful comparison: the book title is level 1, chapters are level 2, and topics inside a chapter are level 3. Heading levels communicate that organization. They are not controls for “large, medium, and small text”; CSS owns visual sizing.

For a beginner project, use one clear h1 for the page's main topic. HTML permits multiple h1 elements, and some valid structures can justify them, but browsers and assistive technology do not reliably create an automatic outline that repairs careless heading levels. Pick explicit ranks that produce a sensible flat outline. Multiple h1s should never be chosen just to make several labels look large.

Once the outline is clear, paragraphs can state ideas and lists can show relationships. Text-level elements then annotate particular words within that flow.

Elements and intended meaning

There are six heading ranks, h1 through h6. Use h2 for a subsection of the page's h1, and h3 for a subsection of that h2. Going back from h3 to h2 begins a peer section. A jump from h1 straight to h4 is not a syntax error, but it normally indicates that the hierarchy has lost a level.

The p element marks a paragraph. Empty paragraphs are not a spacing system; CSS will provide spacing later. A p cannot contain a heading, list, or another paragraph. If such content begins inside one, the browser may close the paragraph automatically, which can make the DOM differ from the indentation you wrote.

em adds stress emphasis. Compare “I asked you” with “I asked you.” strong communicates importance, seriousness, or urgency: “Applications close today.” The two can be combined when both meanings apply. Do not select either element solely for its default italic or bold appearance. b and i have their own semantic uses, discussed below, and visual styling should remain a CSS concern.

Use ul when changing the order would not change the meaning, as with a list of skills. Use ol for steps, rankings, or chronology. Each list's direct children are li elements. An li can contain paragraphs and nested lists, which is how a sub-list stays attached to the item it describes.

Use br when a line boundary belongs to the content, such as an address or poem. It is not a way to create vertical space. hr marks a thematic break between paragraph-level topics; it is not merely a decorative horizontal rule.

“Block versus inline” is only a starter concept

By default, browsers usually place headings, paragraphs, and lists on new lines, so they are often called “block-like.” em and strong normally flow within text and are often called “inline-like.” That model helps predict the first rendering, but modern HTML does not classify every element into semantic “block” and “inline” buckets. HTML uses content models, while CSS can change display. Meaning must not be inferred from whether an element starts on a new line.

Richer text-level semantics

strong and em are only part of HTML's text vocabulary. When another element matches the content's meaning, use it. Never choose a semantic element simply because a browser happens to give it the visual style you want.

`strong` versus `b`, and `em` versus `i`

<p><strong>Deadline:</strong> submit before 5 PM.</p>
<p>The product name is <b>Orbit</b>.</p>
<p>I <em>really</em> need the original file.</p>
<p>The term <i>Homo sapiens</i> is a scientific name.</p>

strong represents strong importance, seriousness, or urgency.
b draws attention without adding that importance, such as a keyword or product name in running prose.
em represents stress emphasis that can change the meaning of a sentence.
i represents text conventionally set apart from surrounding prose, such as an alternate voice, idiomatic phrase, taxonomic designation, or technical term when another semantic element is not more appropriate.

Abbreviations, definitions, quotations, and citations

<p><abbr title="HyperText Markup Language">HTML</abbr> structures web documents.</p>
<p><dfn id="semantic-html">Semantic HTML</dfn> uses elements according to their meaning.</p>

<blockquote cite="https://example.com/source">
  <p>Good structure makes content easier to understand.</p>
</blockquote>
<p>— <cite>Example Web Handbook</cite></p>

<p>Rina said, <q>Start with the content, not the colors.</q></p>

abbr marks an abbreviation or acronym. A title may provide its expansion, but unfamiliar abbreviations should not depend on hover text as their only explanation.
dfn marks the occurrence where a term is being defined.
blockquote represents a block quotation from another source. Its cite attribute can hold a source URL, but the URL is not displayed automatically.
q represents a short inline quotation, and browsers normally add quotation marks.
cite represents the title of a cited creative work, not a person's name merely because that person is its author.

Editorial and reference text

<p>Water boils at 100<sup>°</sup>C at standard pressure.</p>
<p>H<sub>2</sub>O is water.</p>
<p>The launch date changed from <del>12 June</del> to <ins>19 June</ins>.</p>
<p><s>₹999</s> ₹749</p>
<p><mark>Bring photo identification.</mark></p>

sup and sub represent superscript and subscript content when its position contributes to the meaning.
del and ins represent deleted and inserted content, which is useful when showing editorial changes.
s marks content that is no longer accurate or relevant, such as an old price. It does not replace del when the intent is to document an edit.
mark highlights content because it is relevant in the current context, such as a search match or a passage under discussion.

Technical text, keyboard input, program output, variables, and time

Some content is technical rather than ordinary prose. HTML provides elements that let readers, assistive technology, search tools, and later CSS distinguish what each fragment represents.

`code`

Use code for a fragment of computer code:

<p>Use <code>npm run dev</code> to start the local server.</p>
<p>The <code>fetch()</code> function returns a Promise.</p>

code supplies semantic meaning; it does not provide syntax highlighting. A browser may use a monospace font by default, but presentation still belongs to CSS.

For a code block, combine pre and code:

<pre><code>const total = price * quantity;
console.log(total);</code></pre>

pre preserves whitespace and line breaks, while code identifies the content as code. Together they communicate both facts.

When showing executable markup as text, consider parsing carefully. Characters such as < and > need character references so the browser treats the sample as text:

<p>Write <code>&lt;main&gt;</code> for the page's primary content.</p>

`kbd`, `samp`, and `var`

Use kbd for input supplied by the user, most commonly keyboard input:

<p>Press <kbd>Ctrl</kbd> + <kbd>S</kbd> to save.</p>

Use samp for sample output produced by a program or system:

<p>The terminal prints <samp>Build completed successfully</samp>.</p>

Use var for a variable or placeholder in a mathematical or programming explanation:

<p>The area is <var>width</var> × <var>height</var>.</p>

These distinctions matter in documentation: they separate what the reader types, what the machine returns, and what the author is naming abstractly.

A compact documentation example puts the roles together:

<section aria-labelledby="install-heading">
  <h2 id="install-heading">Install the project</h2>

  <p>
    Run <kbd>Ctrl</kbd> + <kbd>Alt</kbd> + <kbd>T</kbd>
    to open a terminal, then enter:
  </p>

  <pre><code>npm install
npm run dev</code></pre>

  <p>Expected output:</p>
  <p><samp>Local: http://localhost:5173/</samp></p>
</section>

Do not use kbd, samp, or var just to obtain monospace text. Their purpose is to carry meaning.

`time`

Use time when text represents a machine-readable date, time, duration, or date-time:

<p>
  Published
  <time datetime="2026-08-27">27 August 2026</time>.
</p>

The reader sees a friendly value; datetime supplies a standardized value for software.

<p>
  The workshop begins at
  <time datetime="2026-09-02T10:30:00+05:30">10:30 AM IST</time>.
</p>

For a duration:

<p>
  Estimated reading time:
  <time datetime="PT18M">18 minutes</time>.
</p>

A practical rule is:

If software may need to understand the date/time value later, make the machine-readable value explicit.

The datetime value must agree with the visible text. Do not invent metadata that tells software something different from what the user is told.

Preformatted and contact information

Use pre when whitespace and line breaks are part of the content:

<pre>Line one
    indented line
Line three</pre>

Do not use pre as a substitute for CSS. It fits preformatted text such as code samples, ASCII diagrams, or any content whose spacing carries meaning.

address represents contact information for the nearest article, or for the document as a whole:

<address>
  Rina's Kitchen<br>
  18 Baker Street<br>
  <a href="mailto:hello@example.com">hello@example.com</a>
</address>

It is not a generic wrapper for every postal address that happens to be mentioned in an article.

Description lists

Use dl when the content is made of name/value or term/description groups, rather than a collection of ordinary bullet points:

<dl>
  <dt>HTML</dt>
  <dd>Structures and describes document content.</dd>

  <dt>CSS</dt>
  <dd>Controls presentation.</dd>
</dl>

dt introduces a term or name, and one or more following dd elements provide its description or value. This pattern suits glossaries, metadata, key/value facts, and question/answer-style definitions when that relationship is genuinely present.

Guided example: a learning journal article

Replace 002's body while keeping the document skeleton:

<body>
  <article>
    <h1>My first week learning HTML</h1>
    <p>I am learning how structure gives web content meaning.</p>

    <h2>What I learned</h2>
    <p>
      HTML describes content; it does <strong>not</strong> exist merely
      to make text look different.
    </p>
    <ul>
      <li>A browser parses markup into a document tree.</li>
      <li>Headings describe hierarchy.</li>
      <li>Elements must be nested intentionally.</li>
    </ul>

    <h2>My study process</h2>
    <ol>
      <li>Read the lesson objective.</li>
      <li>Type the example without pasting.</li>
      <li>Explain each semantic choice.</li>
      <li>Validate the finished document.</li>
    </ol>

    <h2>Next goal</h2>
    <p>I want to build a site that is <em>understandable</em>, not merely visible.</p>
  </article>
</body>

Trace the outline: the article topic is the h1, followed by three peer sections at h2. The skills do not have an inherent sequence, so they belong in ul. The study process is sequential, so it belongs in ol. strong marks the important correction to a misconception, while em stresses “understandable.”

article is covered fully in lesson 006. Here it signals content that could stand on its own as a journal entry. If that idea distracts from today's goal, the article could later sit directly in main; for now, keep attention on text structure.

Open the page without CSS and read only its headings. They should summarize the page. Then read the lists out of order: only the unordered list should keep its meaning when its items are rearranged.

Intermediate example: profile article with nested hierarchy

The next example moves toward a personal website:

<main>
  <article>
    <h1>About Asha Rao</h1>
    <p>I build small web projects while studying frontend development.</p>

    <h2>Current skills</h2>
    <ul>
      <li>
        HTML
        <ul>
          <li>Document structure</li>
          <li>Text semantics</li>
        </ul>
      </li>
      <li>Version control basics</li>
    </ul>

    <h2>Learning journal</h2>
    <h3>Week one</h3>
    <p>I learned to separate meaning from appearance.</p>
    <h3>Week two</h3>
    <p>I will connect several pages with meaningful links.</p>

    <hr>

    <h2>Contact availability</h2>
    <p>
      Monday to Friday<br>
      09:00 to 17:00
    </p>
  </article>
</main>

The nested list belongs inside its parent li, not alongside it. Both weeks sit under “Learning journal,” so each is an h3. The hr marks the thematic shift to availability. The line break is meaningful in this compact schedule; separate paragraphs would also be reasonable if each line expressed an independent thought.

The heading sequence is h1, h2, h2, h3, h3, h2. Heading numbers do not need to increase every time. They describe nesting depth. An h3 should not be added merely because its default size looks convenient.

Advanced optional extension: test the outline as data

Turn the page into a plain-text outline:

About Asha Rao
  Current skills
  Learning journal
    Week one
    Week two
  Contact availability

Next, hide all non-heading text using the browser's accessibility tree or a headings extension, if one is available. Can you predict the page from its headings? Screen reader users often navigate by headings, but headings also help everyone scan a page and search indexing systems understand it. That does not make every visual label a heading. A heading begins a section of content; a short field name will later be a label.

Rewrite “Click here to read more” so the link's purpose remains clear when the text is taken out of context; links arrive tomorrow. The exercise is small, but it shows how good content and good semantics support each other.

Common mistakes and debugging

Heading chosen for size: choose rank from hierarchy, then style later.
Skipping levels: inspect the text outline and correct parent-child depth.
One giant paragraph: split when the topic changes.
br repeated for spacing: use paragraphs and later CSS margins.
hr used as decoration: include it only when a thematic break exists.
Manual bullets (- item): use ul/ol so the relationship and item count are programmatic.
List children that are not li: text and nested lists belong inside an li.
Bold/italic meaning assumed: default visual treatment may change; select strong and em for their meanings.
Paragraph wrapping a list or heading: inspect the DOM; the parser may have closed p earlier than expected.

Accessibility, security, and performance

WCAG requires information and relationships conveyed visually to be determinable programmatically. Real headings and lists do this more reliably than enlarged text and typed bullets. A logical order supports keyboard users, screen-reader users, reading modes, and small screens. Do not give directions that depend only on location, such as “see the list on the right.”

Text elements add very little performance cost. Good HTML can still help by avoiding unnecessary wrappers and scripts. Content itself can cause security or privacy harm: do not publish a personal address, private schedule, or contact details without consent. Treat copied article text as potentially copyrighted, and cite sources instead of presenting someone else's work as your own.

Tiered exercises

Level 1: classify

Choose elements for a page title, two peer topics, an urgent deadline, a sequence of setup steps, a set of hobbies, and a line break in a postal address. Justify every choice.

Level 2: build

Create a complete article page with one h1, at least three h2 sections, one h3, two paragraphs, both list types, meaningful strong and em, and a justified hr or br.

Level 3: audit

Turn your headings into a plain-text outline. Explain any level jump, remove spacing-only breaks, and inspect the parsed DOM for a paragraph that was closed accidentally.

Level 1: h1; two h2s; strong; ol with li; ul with li; br. Use em only where spoken stress changes meaning.

Level 2:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Learning Journal | Asha Rao</title>
  </head>
  <body>
    <main>
      <article>
        <h1>Learning journal</h1>
        <p>I record what I build and what I still need to practise.</p>
        <h2>Topics completed</h2>
        <ul><li>Document structure</li><li>Text semantics</li></ul>
        <h2>Practice routine</h2>
        <ol><li>Plan the outline.</li><li>Write HTML.</li><li>Validate it.</li></ol>
        <h3>Most important check</h3>
        <p><strong>Explain every choice.</strong> I want to learn <em>deliberately</em>.</p>
        <hr>
        <h2>Availability</h2>
        <p>Monday-Friday<br>09:00-17:00</p>
      </article>
    </main>
  </body>
</html>

Level 3: expected outline: Learning journal; Topics completed; Practice routine; Most important check nested under Practice routine; Availability. The br is retained because the schedule lines are intentionally broken, and hr marks the transition from study content to availability.

Recap and exit questions

Structure text by meaning: headings create hierarchy, paragraphs group thoughts, lists express item relationships, and text-level semantics express emphasis or importance. Default display is not semantic meaning.

Why should heading rank not be chosen by size?
When is ol better than ul?
How do strong and em differ?
Give one valid and one invalid reason to use br.
Why is “block versus inline” only a starter model?

Try it with your own example

Build the habit now, while the consequences are small: before writing text markup for your own project, sketch its heading outline on paper first, just as you did for Asha's journal entry.

Suppose Rina wants an "Our Story" page. She sends these sentences in a text message, in this order: her grandmother's original recipe; how the shop opened three years ago; the two ovens they now use; the three people who work there. Do not open the editor yet. First write only the outline:

Our Story
  A recipe passed down
  Opening the shop
  How we bake today
  The people behind the counter

Only then turn it into markup. Choose strong or em only where Rina's words carry real emphasis, such as “we bake every loaf by hand,” not as decorative formatting:

<article>
  <h1>Our Story</h1>
  <h2>A recipe passed down</h2>
  <p>My grandmother taught me this sourdough starter in 1994, and I have kept it alive ever since.</p>
  <h2>Opening the shop</h2>
  <p>Rina's Kitchen opened its doors in 2023, three streets from where she grew up.</p>
  <h2>How we bake today</h2>
  <p>We bake <em>every</em> loaf by hand, in two wood-fired ovens, starting before sunrise.</p>
  <h2>The people behind the counter</h2>
  <ul>
    <li>Rina, head baker</li>
    <li>Marcus, pastry chef</li>
    <li>Dee, front of house</li>
  </ul>
</article>

The “people” section is a ul, not a fourth paragraph, because the order of those people does not genuinely matter. The story above it is chronological, so its sections preserve that sequence. That is the lesson applied to a client's actual words rather than a textbook-only example.

Further reading: MDN — Emphasis and importance has more before/after audio examples of how em genuinely changes spoken meaning.