Login - Jit4All

What does <details> with <summary> do, and what JavaScript would you have had to write to achieve the same result before it existed?

<details> and <summary> create an expand/collapse accordion — the summary text is always visible; everything else inside <details> is hidden until the user clicks. Before these elements existed, achieving this required JavaScript event listeners, CSS class toggling, and ARIA attributes for accessibility — dozens of lines of code. Today it is two HTML elements and zero JavaScript.

HTML is a living standard — it continues to gain new elements as browser vendors and the specification community identify patterns that developers keep rebuilding from scratch with JavaScript. The elements in this lecture were added to HTML because they solve real, recurring problems. Learning them means reaching for native HTML first, which is always faster, more accessible out of the box, and easier to maintain than a custom JavaScript solution.

The modern elements covered here are all well-supported in current browsers. Each one solves a pattern you have seen on the web: expand/collapse sections ( <details> / <summary>), text input with suggestions ( <datalist>), modal dialogs ( <dialog>), progress bars ( <progress>), and meter gauges ( <meter>). All are keyboard-accessible and screen-reader-compatible by default — which custom JavaScript solutions rarely are without significant extra effort.

The <template> element holds HTML that is parsed by the browser but not rendered — it is a blueprint for creating repeated content with JavaScript. The <slot> element is used inside Web Components. Both are advanced topics, but understanding they exist helps you recognise them when you encounter them in modern codebases.

The key mindset shift this lecture teaches is: before writing JavaScript to build an interactive UI component, ask "does HTML already have an element for this?" The answer is increasingly often yes. Native HTML elements are faster (no JavaScript to parse), more accessible (behaviour is built into the browser's accessibility tree), and more resilient (they work even when JavaScript fails to load).

<!-- 1. Expand / collapse accordion — zero JavaScript -->
<details>
  <summary>What is your return policy?</summary>
  <p>We accept returns within 30 days of purchase.
     Items must be unused and in original packaging.</p>
</details>

<details open>
  <summary>How long does shipping take?</summary>
  <p>Standard shipping takes 5–7 business days.
     Express shipping is 1–2 business days.</p>
</details>

<!-- 2. Text input with autocomplete suggestions -->
<label for="city">City</label>
<input type="text"
       id="city"
       name="city"
       list="city-options">
<datalist id="city-options">
  <option value="Calgary">
  <option value="Edmonton">
  <option value="Vancouver">
  <option value="Toronto">
  <option value="Montreal">
</datalist>

<!-- 3. Native modal dialog -->
<dialog id="confirm-dialog">
  <h2>Confirm your order</h2>
  <p>Are you sure you want to place this order?</p>
  <button onclick="document.getElementById(
    'confirm-dialog').close()">Cancel</button>
  <button type="submit">Confirm</button>
</dialog>
<button onclick="document.getElementById(
  'confirm-dialog').showModal()">Place order</button>

<!-- 4. Progress bar -->
<label for="upload">Upload progress</label>
<progress id="upload" value="65" max="100">
  65%
</progress>

<!-- 5. Meter gauge -->
<label for="disk">Disk usage</label>
<meter id="disk"
       value="7.5"
       min="0"
       max="10"
       low="3"
       high="8"
       optimum="2">
  7.5 GB of 10 GB used
</meter>

<details> and <summary> — The <summary> is the clickable visible header. Everything else inside <details> is hidden by default and revealed on click — no JavaScript, no CSS class toggling. Adding the open attribute to <details> starts it in the expanded state. The browser handles the toggle, adds the correct ARIA expanded/collapsed state automatically, and makes the summary keyboard-focusable and activatable with Enter or Space. An FAQ section built with these two elements has zero JavaScript and is fully accessible by default.

<datalist> — This provides autocomplete suggestions for a text input. The input and the datalist are linked by matching the input's list attribute to the datalist's id. Unlike a <select>, the user is not restricted to the suggestions — they can type anything. The datalist options appear as they type, filtered by their current input. This is ideal for city names, product categories, or any field where suggestions help but free text is also valid.

<dialog> — A native modal dialog, opened with element.showModal() (which traps keyboard focus inside the dialog until it is closed) or element.show() (which opens it without trapping focus). Closed with element.close(). The browser handles focus trapping, Escape key to close, and the correct ARIA dialog role — three things that custom modal dialogs built from <div> elements consistently get wrong. Browser support is now excellent (all major browsers since 2022).

<progress> vs <meter> — These look similar but mean different things. <progress> shows completion of a task: a file upload, a form wizard, a course completion percentage — value moves from 0 toward max as the task progresses. <meter> shows a measurement within a known range: disk space used, battery level, a score — it has low, high, and optimum attributes that make the bar change colour automatically when the value enters a warning or danger zone. Both elements have accessible roles built in — screen readers announce them correctly without any ARIA needed.

Fallback content inside modern elements — Content placed between the opening and closing tags of <progress> and <meter> is the fallback for browsers that do not support them (now very rare). Write the current value as text: "65%" or "7.5 GB of 10 GB used." This text is also used by some screen readers to announce the element's value, making it doubly useful.

A native <details> accordion requires two HTML elements and zero JavaScript. A custom accordion built with <div> requires dozens of lines of JavaScript, CSS class management, event listeners, and manual ARIA attributes — and still frequently has keyboard and accessibility bugs.

Native elements like <details> function even when JavaScript fails to load — a blocked script, a slow connection, or a corporate firewall. Interactive features built entirely in JavaScript become non-functional in the same conditions.

Paste a component you have built into ChatGPT and ask: "Is there a native HTML element that could replace this JavaScript-based component?" It is good at identifying opportunities to use <details>, <dialog>, and <datalist>. Be cautious if it suggests using <dialog> without explaining that keyboard focus trapping requires the showModal() method specifically — using show() does not trap focus, which is an accessibility problem for modal dialogs.

Build a FAQ section with at least four questions using <details> and <summary>. Set the first question to start open using the open attribute. Test keyboard navigation: Tab to a summary, press Enter to toggle it, press Space to toggle it again.

Add a city search field to a form using <input list="..."> and <datalist> with at least six city options. Test that the suggestions appear as you type, that selecting one fills the field, and that typing a city not in the list is still accepted.

Add a <dialog> element with a heading, a message, Cancel and Confirm buttons. Add a regular button outside the dialog that calls showModal() to open it. Wire the Cancel button to call close(). Test that pressing Escape also closes it and that Tab cycles only through elements inside the open dialog.

Add a <progress> bar with value="40" max="100" and a <meter> with value="8" min="0" max="10" low="4" high="7" optimum="2". Observe how the meter bar changes colour when the value is above the high threshold.

Putting a block element like <div> or <p> inside <summary>. The <summary> element should contain only inline content — text, code, spans, images. Block elements inside <summary> cause rendering inconsistencies across browsers.

Using <dialog> with show() instead of showModal() for modal dialogs. show() opens the dialog but does not trap keyboard focus inside it — users can Tab out of the dialog and interact with the blocked background content. Always use showModal() for dialogs that should block the rest of the page.

Forgetting to link <input list="..."> to its <datalist id="...">. The list value and the id must match exactly. A mismatch means no suggestions appear and no error is shown.

Using <progress> when the value is a measurement (like battery level or disk space) and <meter> when the value is a task completion percentage. The distinction matters for accessibility — screen readers announce them differently and the semantic meaning is conveyed to assistive technologies.

Reaching for a JavaScript library for accordion, modal, or autocomplete functionality without first checking whether the native HTML elements cover the use case. Libraries add weight, dependencies, and potential security vulnerabilities. <details>, <dialog>, and <datalist> cover a large proportion of common interactive UI patterns with zero JavaScript required.

Build an accessible expand/collapse FAQ with <details> and <summary>, an autocomplete field with <datalist>, a native modal dialog with <dialog>, and progress and meter indicators — all with zero JavaScript beyond the two lines needed to open and close the dialog.