HTML Can Do That
TL;DR
Chris Burnell lists interactive features that plain HTML now handles without JavaScript, including popovers, modal dialogs, exclusive accordions, invoker buttons, lazy images and find-in-page reveals. He adds that several native form controls are still too buggy or inaccessible to rely on.
The article
- The popover and popovertarget attributes give light dismiss, Esc to close and top-layer stacking for free. There is no z-index to manage and no script to write.
- The dialog element pairs with the new command and commandfor attributes. These let separate buttons open and close a dialog or popover without script. So far only the actions that open and close dialogs and popovers have landed in stable browsers.
- Giving several details elements the same name attribute turns them into an accordion where opening one closes the others.
- loading="lazy" defers an image until it nears the viewport. hidden="until-found" keeps content hidden until find-in-page or a fragment link reveals it. Burnell notes that until-found works with browser search but poorly with screen reader search.
- Burnell warns that the color, date and range inputs look different in every browser and are often poorly accessible. He suggests skipping datalist for now, because support across input types is spotty and buggy.
- Burnell built the page in one hour for HTML Day 2026. An update dated August 20 says he has since edited it to stress where browser support and accessibility fall short.
Why it matters
Front-end developers looking to drop JavaScript for overlays and accordions should open the original. Each feature has a live demo, its markup and a browser support link, so you can test it in your own browser before committing.
The discussion
The thread liked the page and used it as a starting point for complaints. People who ship popover and dialog in production praised them. The longest arguments were about native form controls that still fall short, and whether HTML should take over work that JavaScript libraries already do.
Native form controls still fall short
Most agreed datalist can't replace a real combobox: users can type anything, filtering isn't fuzzy, Firefox support is weak and nothing forces the list open. When others noted that backend validation is needed anyway, yurishimo answered that the complaint was about UX, not security. The native date picker drew the same verdict, with no ranges, no highlights, and no way to use the page's locale over the OS's. A smaller group disliked the exclusive accordion itself, citing Nielsen Norman Group advice against closing content a reader opened.
HTML can NOT, in fact, replace a good combobox with search input. Datalist has significant shortcomings.
I do still think the date picker API is a disaster. Everyone actually needs something much richer than the system date picker. Travel websites want ranges.
Should HTML take over JavaScript's job?
A request for native sortable tables became a fight over scope, with krapp arguing that a small JS file you control solved sorting long ago. Others said browser vendors can sort better than any single site, and blocked or abusive JavaScript makes native features worth having. jwr and dansalvato raised harder problems: sort keys that differ from display values, rowspans, and HTML describing an order the DOM doesn't follow. Some suggested server-side sorting via header links, and others objected to the round trip and the sort state in shared URLs.
You can edit a JS file to your specific needs, but you're stuck with whatever the browser decides.
JS is better suited to only handle non-standard cases where no native functionality exist as browser vendors can afford to spend infinitely more time to make sorting better than you can spend on doing it for one website.
Popover and dialog in production, and anchor positioning
Several developers said they had replaced custom overlay managers with popover and dialog, and they praised top-layer stacking and cascading close. The one gap they kept hitting was placing a popover next to the button that opened it. CSS anchor positioning fixes this, but people found it hard to learn and argued over whether browser support is wide enough. A rich-text editor developer gave a limit from the other side: contenteditable produces different HTML in each browser, so complex editors still need JavaScript.
The top-layer + cascading-close behavior is exactly why we finally dropped a bunch of custom overlay managers.
I found it difficult to wrap my head around too, but once it clicks it's pretty simple.
Coding models don't know the new standards
dajonker said coding models rarely use these features, often believe they aren't baseline yet, and have far more old JS and CSS to learn from. Commenters worried that coding models could freeze front-end practice at whatever was common in their training data. Others pointed to skills such as Google's Modern Web Guidance that tell models to use modern CSS. That started a side argument over whether a skill is anything more than a text file in the context.
I really wonder if AI coding is just going to lock us into 2024-ish era languages and libraries forever.
But I guess "my LLM can use skills" sounds a lot cooler than "my LLM can read text files", so we'd rather keep pretending really hard.
NoScript users and the case against SPAs
A NoScript user hoped features like these would make single-page apps less necessary. Others complained that SPAs break bookmarks and the back button. SPA builders replied that routers handle URLs and history, and critics answered that the reimplementation usually works worse than the browser's own. A few commenters build sites that work without JavaScript, and others said JS-based bot protection has made browsing without scripts harder lately.
It's the norm to try to re-implement browser functionality in JS but it is very far from the norm for the re-implementation to work as well and as reliably as the native browser functionality.
Consensus
Popover, dialog and named details are worth using now and remove a lot of custom JavaScript. Datalist and the date picker are not ready to replace a library.
Dissent
A minority said interactivity belongs in JavaScript. They argued that each new declarative attribute bloats browsers, appears only in one API, and leaves developers stuck with how the vendor implemented it.