ποΈ 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:
| 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.
| 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:
- Overview β the product's spec sheet as a definition list.
- Comparison β this product vs. two competitors as a table.
- 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.