HTML Features That Can Save You Some JavaScript
HTML has gained enough useful behaviour that my first question is often not “Which component do I need?” but “Does the browser already do this?”
Native HTML will not replace every custom interface. It can, however, remove a surprising amount of script and give you semantics and keyboard behaviour as a starting point.
Disclosures, dialogs, and popovers
A basic expandable section needs two elements:
<details>
<summary>Do I need JavaScript?</summary>
<p>No. The browser handles this disclosure.</p>
</details>
The open state is styleable with details[open]. A modal can begin with <dialog> and one small call:
<dialog id="contact">
<h2>Contact me</h2>
<form method="dialog"><button>Close</button></form>
</dialog>
contact.showModal();
For a lightweight overlay, the Popover API can avoid JavaScript entirely:
<button popovertarget="menu">Menu</button>
<div id="menu" popover>
<a href="/">Home</a>
<a href="/blogs/">Blog</a>
</div>
Disable or reveal a whole subtree
inert makes a section temporarily unavailable instead of disabling every descendant:
<section inert>
<button>Save</button>
<a href="/settings/">Settings</a>
</section>
The inert attribute affects interaction and accessibility, but it does not visually explain why the area is unavailable.
For collapsible reference content that should remain discoverable by Find in Page, hidden="until-found" is an option:
<section hidden="until-found">
Hidden content that browser search can reveal.
</section>
Support and behaviour are described in MDN’s hidden attribute reference. I would keep it as an enhancement rather than making critical content depend on it.
Small elements that carry useful meaning
<search> identifies search or filtering controls without implementing search. <datalist> suggests values while still allowing free input. <output> identifies a calculated result, and <meter> represents a value in a known range; task completion belongs in <progress> instead.
These elements are not exciting. That is part of their appeal: they describe the job without inventing a custom component vocabulary.
Images and forms already have useful controls
Below-the-fold images can use loading="lazy", while srcset and sizes let the browser choose an appropriate source without screen-width detection in JavaScript.
Forms know about required, min, max, minlength, maxlength, pattern, and step. inputmode="numeric" can request a better mobile keyboard for a text value such as a verification code, and autocomplete="one-time-code" can reduce typing further.
My order is simple:
Does HTML already describe it?
↓
Can CSS handle the presentation?
↓
What behaviour still needs JavaScript?
Native HTML is a baseline, not a purity test. Starting there makes the remaining custom code describe the genuinely custom part.
Enjoyed reading this?
If you found this article helpful, consider supporting my writing. Every little bit helps keep this blog going.
Related articles
- The HTML Details That Make Forms More Accessible
Build clearer forms with visible labels, autocomplete, connected help and errors, fieldsets, and visible focus.
- When a Control Needs aria-label
Use aria-label for genuinely unlabelled controls while keeping visible text and native elements as the first choice.
- When CSS Layout Order Stops Matching the HTML
Keep Grid and Flexbox layouts aligned with the HTML order so keyboard focus and screen reader reading do not jump around the page.