HTML Can Do That

Popover, dialog, invoker commands, our entire production app uses these everywhere and it works really well! The fact that dialogs and popovers are rendered on the "top layer" and that nested popovers are also automatically stacked on top of each other and have 'cascading close' shows how well these standards were designed.

The only hard thing is still to position a popover near the element that triggers it, such as when you want to create a context menu that has to render above/below the button that triggered it. There is anchor positioning in CSS now but support is still limited and I find it hard to wrap my head around.

LLMs are also terrible at these new standards. If they even know about them, they often think they're not baseline yet and they have almost zero training data compared to the giant mountain of weird JS and CSS that people had to use before the introduction of these standards.

This comment by yurishimo should not be [dead], imo

>Just a heads up but datalist is not really a great solution if you need a strong contract. The user can still type whatever they want into the field and there is no fuzzy filtering or typo mitigation. Once you add those requirements, a library that gives you a more fully featured combobox is likely going to make a lot of sense in your project.

It is true! HTML can do a lot of cool stuff, it might get you 100% of the way depending on what you're doing. But if you have a lot of forms where users pick from a value set, and want to enforce no other strings and get a good search experience, datalist does not get you there.

I'm that minutia in your statistics that is still rocking NoScript in 2026, enabling JavaScript on a site-by-site basis, but this is increasingly difficult with the modern web.

Hopefully these and others modern HTML features gain adoption, along with realizing perhaps a Single Page Application isn't necessary in most instances.

I don't often have to write frontend code, but when I do, there is very little in terms of interactivity you cannot do with HTML these days, worst case a little sprinkle of something like HTMX.

I'd really wish I could force ISO format for the date input as the current "platform native" is confusing for some users when the OS use a different language than the web page that is shown.

For some multi-country companies it makes sense to have all admin pages in English no matter the underlying OS language. Imagine sending a screenshot where the OS date format is different from what everybody else expects from an English page.

HTML did <select> since inception but that didn't stop people from trying to reinvent it using <div> and a bunch of JS.

All these great built in features, especially typeahead, wont be mainstream until they can be excessively styled.

Related to this, I’d love that HTML natively support sortable tables. This is a common need but every single time I have to reimplement it.

The color input looks different depending on your browser and OS. https://master.dev/blog/the-color-input-the-color-picker/

Firefox uses the native OS color picker, which in Windows 11 still looks unchanged from Windows 95.

Saw Grouped <details>, ctrl+F'd the hidden content and it opened and highlighted the text in Firefox. Was waiting for this fix ever since I learned about details.

I started textlog.cc as an experiment to see how far I can go without introducing JS. It turns out, pretty far! If you exclude the Web Push notifications which required a Service Worker script, all the rest is server-side rendered React. As a visitor, with all the hover cards and popovers you would think there is some JS going on, but it’s all HTML-only. I am enjoying very much the constraint and it hasn’t hindered any progress. It’s a proof a lot can be achieved by just HTML.

Yeah, I'm a great fan of both HTML and CSS "can do that". I find more useful things on the CSS side like :has, keyframes and container queries. Why duplicate code when you have it for free :)

I’m a big fan of simple things but I always go back to using a library or framework because it’s much easier to create a good, consistent UX

The “hidden until found” feature surprised me. What’s the use case for something like that?

<img> also supports "srcset" which can make the image component responsive. Hope they add a placeholder to it which can account for loading state.

The only one not mentioned I think should be utilized more is properly names in html forms. Everyone has gotten used to just doing things in javascript when a lot of times if you name the fields in a correct way, you can do a simple form post and let the backend validate it with little to no modifications (hopefully none if you did it correctly).

I think the big issue with some of items listed is not all the browsers either implement it or they implement it differently. I'm sure your first instinct will be Safari but Chrome, while it may implement a lot, tends to do it quite different than the others. The date picker in browsers is one feature that comes to mind.

I think it’s neat but at the same time I’m cautious about implementing an “almost feature” in what’s supposed to be a declarative language.

Now everybody needs to support it and nobody can really use it.

I’m talking about the features in work like media controls on dialog buttons.

JS has been in front-line for these functionalty, and HTML has been dog-slow to catch up with slow standardization (not based on usage more academical) and recommendations.

HTML can do that. yes. but adoption? welp, I don't really care nor will I use it unless I have to. I will use whatever was available in practice and continue to use them.

Grouped Details example really needs a hand cursor. An "I" cursor for selecting text doesn't tell you that an element is interactible.

I eagerly await the day we can fully style the date & time component so that we can put all those JS libraries to (a well deserved) rest.

I use most of these but the one that somehow slipped past me was the name attribute for details. That's going to be incredibly useful. I want to go rip out all of the js accordions now.

Most people use divs for everything now. This is a breath of fresh air.

my personal favorite, although css not html, is “field-sizing: content”. Finally with iOS 26 we can have input fields that expand to fit the content

I don’t understand why the group invented these new attributes and methods of action for dialogs that don’t seem relevant to anything else. Was there some silly patent to work around?

What I'd like to see are searchable drop-downs (not to be confused with text input with suggestions).

And the date/time picker controls are too limited for many applications.

It's weird that the pure html dialog still doesn't handle inertness yet

Here we all are in 2026, talking about HTML, like madmen.

Loved the Zelda reference.

once again, i will ask: why do people care so much about only having one <details> element open at a time? let me see what i want to see!

<details> is still not animatable?

js is web remote code execution. we need to return to an html only browser world.

theres no reason for a browser to be an OS/compiler/abi, for remote code.

this is the dumbest shit in the history of computers. why didnt everyone have they torches and pitchforks, when web2.0 became a thing?

See also: <http://youmightnotneedjs.com/>

Just because you can, it doesn't mean you should

What on Earth is hidden-until-found for?

I've been tooling with site for years now and I'm always shocked at what can be done with raw HTML. These are some really neat examples, some work a bit funny when it comes to mouse vs. arrow key functionality though (in particular the dropdown/autocomplete), I'm wondering if that's an Edge specific issue or Chromium.

>popover

Why are we cool with popups again? Anything that interrupts and blocks content is annoying, and is nearly guaranteed to make me leave immediately. It can be used responsibly, but it almost never is.

The older I get, the less I want to use new browser features that have already been somehow possible with existing ones that typically have been around for literal decades.

Adopting them makes a future with multiple browser engines more labor intensive and unlikely as the number of standards targets one is required to support grows and it becomes a game of asking yourself what sites you want your browser to support.

If you don't have a lot of experience in web software, you might think, that's a silly thing to think about, but I think it's that level of maybe exceptional thoughtfulness that has really profound ramifications. If you do have a lot of experience in web software and you think it's silly to think about, you suck.

ngl i was surprised for the modal dialogs i always thought we needed javascript as i have been doing so forever with jquery

a bit off topic but wish we could bring back <frames> and <tables>. just good old fashioned stuff from the late 90s

Just a heads up but datalist is not really a great solution if you need a strong contract. The user can still type whatever they want into the field and there is no fuzzy filtering or typo mitigation. Once you add those requirements, a library that gives you a more fully featured combobox is likely going to make a lot of sense in your project.

[dead]

[flagged]

[dead]

This page loads so slow it did not evenwork for me. guess html was not enough

An "HTML Can't Do That" would be hundreds pages long, and at the pace of getting features like dialogs every decade we're limiting ourselfs on any further development and creating serious apps. It wasn't created for apps, it was created for light document formatting. When we will pretend a drawing api we can call directly from webassembly? Outside of web ui frameworks are doing just fine and way better and more performantly than html and dom