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 definitely remember seeing a post by a Chromium maintainer talking about starting development on a proof of concept implementation and surveying for semantics.
(iirc if you have [showdead] on you can click on the timestamp to the comment and will get a [vouch] option as a reverse-flag, fwiw. i see it and don't have showdead enabled, so enough people have re-vouched it!)
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
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.
Single page applications are one of the most anoying web patterns i know of. Please just let me have one page for each ting to do so i actually can bookmark it properly.
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.
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.
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 :)
Looks like it's basically like a one way show-hidden mechanism, but the browser's built-in search will pop it open on matches.
So you could use it for additional notes, things like "view pricing terms" or "show exclusions" on product listings — stuff people need to read only when they need to read it — without it being hidden from them if they search for it.
Pretty cool! I’ve been using <details> for this. One example would be a collapsible tree hierarchy of our organization that you can CTRL+F and still find collapsed teams and people. Or an accordion, or anything collapsible, really.
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?
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.
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.
Very true, and ran into this one specifically myself when going down the "HTML can do this!" road. HTML can NOT, in fact, replace a good combobox with search input. Datalist has significant shortcomings. I wound up using a React island for this single input inside otherwise normal HTML, despite my own objections, because it really it just that much better than the native options.
That's the whole sanitize vs. validate argument debate that keeps coming up.
How you handle it is project-dependent. But if you're doing a real web site, not an SPA, you can show an error/help page, or re-load the current page with the error/help message.
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 seem to recall there was a proposal to add such thing to <select>s
I definitely remember seeing a post by a Chromium maintainer talking about starting development on a proof of concept implementation and surveying for semantics.
(iirc if you have [showdead] on you can click on the timestamp to the comment and will get a [vouch] option as a reverse-flag, fwiw. i see it and don't have showdead enabled, so enough people have re-vouched it!)
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
> When we will pretend a drawing api we can call directly from webassembly?
Hopefully, never. There's enough ad-blocking arms race as it is.
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.
Single page applications are one of the most anoying web patterns i know of. Please just let me have one page for each ting to do so i actually can bookmark it properly.
Thank goodness you exist, the fingerprinters will be confused as to which one of the two of us went to their website!
How? There are dozens of us! DOZENS!
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.
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.
That's what javascript is supposed to be for. All of this is what javascript is supposed to be for.
HTML describes layout, CSS describes style, JS adds interactivity.
Want sortable tables? Get a jquery plugin and spend five minutes, done.
This was all solved a decade or more ago.
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.
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 :)
Yeah I've seen a page that described a whole bunch of things you can do with CSS. So many animation options!
The “hidden until found” feature surprised me. What’s the use case for something like that?
Looks like it's basically like a one way show-hidden mechanism, but the browser's built-in search will pop it open on matches.
So you could use it for additional notes, things like "view pricing terms" or "show exclusions" on product listings — stuff people need to read only when they need to read it — without it being hidden from them if they search for it.
Pretty cool! I’ve been using <details> for this. One example would be a collapsible tree hierarchy of our organization that you can CTRL+F and still find collapsed teams and people. Or an accordion, or anything collapsible, really.
One thing that comes to mind is JS-less image preview, clicking on an image thumbnail reveals the full preview.
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.
<img> also supports "srcset" which can make the image component responsive. Hope they add a placeholder to it which can account for loading state.
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?
As opposed to what? Not sure what the alternative you're picturing is.
popovertarget="example-dialog" popovertargetaction="hide"
It’s all binding. This is what JavaScript is for: dynamic content.
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.
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.
Very true, and ran into this one specifically myself when going down the "HTML can do this!" road. HTML can NOT, in fact, replace a good combobox with search input. Datalist has significant shortcomings. I wound up using a React island for this single input inside otherwise normal HTML, despite my own objections, because it really it just that much better than the native options.
There’s still browser/OS typo mitigation.
That's the whole sanitize vs. validate argument debate that keeps coming up.
How you handle it is project-dependent. But if you're doing a real web site, not an SPA, you can show an error/help page, or re-load the current page with the error/help message.