Skip to main content

πŸ—‚οΈ Data Representation Best Practices

Tables are powerful, but they're not the only way β€” or often the best way β€” to present information. This lesson gives you a decision framework for matching each kind of data to the HTML element that describes it most honestly, from lists and definition lists to semantic elements like <meter> and <details>.

🎯 Learning Objectives

By the end of this lesson, you will be able to:

  • Apply a decision process to pick the right structure for a given dataset
  • Use definition lists (<dl>) for key-value data instead of forcing a table
  • Choose ordered vs. unordered lists for sequential and categorical data
  • Employ semantic elements β€” <figure>, <details>, <meter>, <progress> β€” appropriately
  • Keep every representation accessible and responsive

Estimated Time: 30–40 minutes  β€’  Difficulty: Intermediate

Hands-on: Design a product-spec page that uses three different data structures correctly.

In This Lesson

Data as a Meal

Presenting data on the web is a choice, not a default. The same underlying facts can be served many ways, and the structure you pick is itself information β€” it tells browsers, search engines, and assistive technology what the data is.

πŸ’‘ A useful analogy: The same ingredients can be a formal plated dinner (a table), a help-yourself buffet (a list), or a tray of labelled samples (definition list). The food is identical; the presentation changes how it's experienced β€” and how easy it is to find what you want.

πŸ“– Four principles of good data representation

Clarity β€” the meaning should be immediate.

Accessibility β€” every user can perceive and navigate it.

Responsiveness β€” it holds up from phone to desktop.

Context β€” related facts are grouped, not scattered.

Choosing the Right Structure

Before writing any markup, ask what shape the data has. This single question routes you to the correct element:

flowchart TD A[Data to present] --> B{What shape is it?} B -->|Rows AND columns relate| C[Table] B -->|A sequence of items| D{Order matters?} D -->|Yes| E[Ordered list ol] D -->|No| F[Unordered list ul] B -->|Name β†’ value pairs| G[Definition list dl] B -->|A value within a range| H[meter / progress] B -->|Optional detail| I[details / summary]
Data shape β†’ HTML structure
The data Best structure
Product specs compared across models Table
Steps in a recipe Ordered list (<ol>)
Tags on a blog post Unordered list (<ul>)
A single machine's specifications Definition list (<dl>)
Disk usage at 72% <meter>

Tables, Used Well

Reach for a table only when values genuinely relate across both rows and columns β€” a comparison, a schedule, a statistical grid. Here a table is exactly right, because each cell answers a "which feature Γ— which model" question:

<table>
  <caption>Smartphone Model Comparison β€” July 2026</caption>
  <thead>
    <tr>
      <th scope="col">Feature</th>
      <th scope="col">Model X</th>
      <th scope="col">Model Y</th>
      <th scope="col">Model Z</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Display Size</th>
      <td>6.1"</td>
      <td>6.7"</td>
      <td>6.9"</td>
    </tr>
    <tr>
      <th scope="row">Battery Life</th>
      <td>12 hours</td>
      <td>18 hours</td>
      <td>24 hours</td>
    </tr>
    <tr>
      <th scope="row">Price</th>
      <td>$699</td>
      <td>$899</td>
      <td>$1,099</td>
    </tr>
  </tbody>
</table>

πŸ’‘ Always leave room to scroll

Wrap wide tables so they never blow out the page on mobile. A one-line container does the job:

<div class="table-wrap">
  <table> ... </table>
</div>
.table-wrap { width: 100%; overflow-x: auto; }

Lists & Definition Lists

A huge share of "table-shaped" content is really one-dimensional. Forcing it into a table adds noise and hurts accessibility. Lists are cleaner.

Definition list for key-value pairs

When you're describing one thing as a set of name β†’ value pairs (a spec sheet, a glossary, metadata), the definition list is the semantically correct element β€” not a two-column table.

<dl>
  <dt>CPU</dt>
  <dd>8-core, 5.0 GHz</dd>

  <dt>RAM</dt>
  <dd>64 GB DDR5-6000</dd>

  <dt>Storage</dt>
  <dd>2 TB NVMe SSD</dd>
</dl>

πŸ“– <dt> and <dd>

<dt> is the term (the name/key). <dd> is the description (the value). One term may have several descriptions, and vice versa.

Ordered vs. unordered lists

The choice is about whether sequence carries meaning.

Which list?
Use When order… Example
<ol> matters Recipe steps, rankings, instructions
<ul> doesn't matter Feature bullets, tags, ingredients
<h3>Top 3 languages to learn in 2026</h3>
<ol>
  <li>Python</li>
  <li>JavaScript</li>
  <li>Rust</li>
</ol>

Semantic Data Elements

HTML ships several elements built specifically to represent data meaningfully. Using them gives you accessibility and native browser behaviour for free.

<figure> + <figcaption>

Wrap a self-contained chunk β€” a table, chart, or code sample β€” with its caption so the two travel together:

<figure>
  <table> ... </table>
  <figcaption>First-quarter savings by month</figcaption>
</figure>

<details> + <summary>

Progressive disclosure with zero JavaScript β€” perfect for secondary data the user can expand on demand:

<details>
  <summary>User activity (Q1 2026)</summary>
  <p>New users: 2,345</p>
  <p>Active users: 15,678</p>
</details>

<meter> and <progress>

Two often-forgotten elements. <meter> shows a value within a known range (a gauge); <progress> shows completion toward a goal.

<!-- A measurement inside a range -->
<label>Disk used:
  <meter value="0.72" min="0" max="1">72%</meter>
</label>

<!-- Progress toward completion -->
<label>Upload:
  <progress value="45" max="100">45%</progress>
</label>

⚠️ <meter> is not <progress>

Use <meter> for a static reading within a scale (disk space, a rating, a temperature). Use <progress> only for a task advancing toward done (a file upload, a form wizard). Always include fallback text between the tags for browsers and readers that need it.

Worked Example: A Weather Dashboard

A single UI often mixes data shapes. A weather panel is a great illustration: current conditions are key-value pairs (a definition list), while the 5-day forecast is genuinely tabular (a table). Matching each to its structure keeps both clear and accessible.

<section aria-labelledby="current">
  <h2 id="current">Current Conditions</h2>
  <dl>
    <dt>Temperature</dt><dd>22°C</dd>
    <dt>Humidity</dt><dd>45%</dd>
    <dt>Wind</dt><dd>8 mph NW</dd>
  </dl>
</section>

<section aria-labelledby="forecast">
  <h2 id="forecast">5-Day Forecast</h2>
  <div class="table-wrap">
    <table>
      <caption>Forecast for Henderson, NV</caption>
      <thead>
        <tr>
          <th scope="col">Day</th>
          <th scope="col">Conditions</th>
          <th scope="col">High</th>
          <th scope="col">Low</th>
        </tr>
      </thead>
      <tbody>
        <tr>
          <th scope="row">Thursday</th>
          <td>Sunny</td>
          <td>26°C</td>
          <td>18°C</td>
        </tr>
      </tbody>
    </table>
  </div>
</section>

βœ… Why this works

Each <section> is labelled by its heading via aria-labelledby, the current conditions use the semantically correct <dl>, and the forecast uses a scoped, captioned table. Nothing is forced into the wrong shape.

Hands-on Exercise

πŸ‹οΈ Build a Product Specifications Page

Objective: Present one product using three different data structures, each chosen correctly.

Requirements:

  1. Overview β€” the product's spec sheet as a definition list.
  2. Comparison β€” this product vs. two competitors as a table.
  3. Highlights β€” a bulleted feature list, plus a <meter> for one rated attribute (e.g. battery health).
πŸ’‘ Hint

Ask "is this one thing described by many attributes?" β†’ <dl>. "Am I comparing several things across the same attributes?" β†’ table. "Is this an unordered set of perks?" β†’ <ul>.

βœ… Sample solution
<article>
  <h1>NovaBook Pro 14</h1>

  <section>
    <h2>Specifications</h2>
    <dl>
      <dt>CPU</dt><dd>10-core, 3.8 GHz</dd>
      <dt>RAM</dt><dd>32 GB</dd>
      <dt>Weight</dt><dd>1.4 kg</dd>
    </dl>
  </section>

  <section>
    <h2>How it compares</h2>
    <div class="table-wrap">
      <table>
        <caption>14-inch laptop comparison</caption>
        <thead>
          <tr>
            <th scope="col">Feature</th>
            <th scope="col">NovaBook</th>
            <th scope="col">Rival A</th>
            <th scope="col">Rival B</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <th scope="row">Price</th>
            <td>$1,299</td><td>$1,399</td><td>$1,199</td>
          </tr>
        </tbody>
      </table>
    </div>
  </section>

  <section>
    <h2>Highlights</h2>
    <ul>
      <li>All-day battery</li>
      <li>Fanless, silent design</li>
    </ul>
    <p>Battery health:
      <meter value="0.92" min="0" max="1">92%</meter>
    </p>
  </section>
</article>

🎯 Quick Quiz

Question 1: You need to show one laptop's spec sheet β€” a set of name β†’ value pairs. What's the most semantically correct element?

Question 2: Which element best represents "disk usage: 72% of capacity"?

Question 3: When should you genuinely reach for a table?

Best Practices

βœ… Do

  • Let the data's shape pick the element, not habit or convenience.
  • Use <dl> for key-value pairs and lists for sequences.
  • Wrap tables in a scroll container for mobile.
  • Provide fallback text inside <meter> and <progress>.
  • Keep sufficient colour contrast for every data element.

❌ Don't

  • Don't force key-value data into a table just because it has two columns.
  • Don't use tables for layout.
  • Don't convey meaning with colour alone.
  • Don't rebuild a native element (a gauge, an accordion) in JavaScript when HTML already provides it.
πŸ’‘ Accessibility is universal design. A wheelchair ramp helps parents with strollers and travellers with luggage too. Data structured for a screen reader is also clearer for search engines, easier to style, and simpler to maintain β€” everyone wins.

Summary & Quiz

πŸŽ‰ Key Takeaways

  • The structure you choose is information β€” pick it deliberately from the data's shape.
  • Tables are for two-dimensional data only; key-value pairs belong in a <dl>.
  • Ordered lists for sequences, unordered lists for sets.
  • Semantic elements β€” <figure>, <details>, <meter>, <progress> β€” give accessibility and behaviour for free.
  • Accessibility and responsiveness apply to every representation, not just tables.

πŸ“š Further Reading

πŸš€ What's Next?

You've mastered how to structure data. Next, Semantic HTML5 Elements zooms out to the whole page β€” <header>, <nav>, <main>, <article>, and friends β€” so your entire document reads as clearly as your data does.

πŸŽ‰ Right tool, right job

Choosing the correct element is a habit that pays off in clarity, accessibility, and SEO on every page you build from here on.