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!)
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 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.
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.
This is part of how I judge how well made or how shitty a website is. If it requires scripts from a dozen third parties, then it usually sucks and one can easily recognize when not much effort has been put into making it.
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.
Once backend and frontend became two separate teams frontend people didn't want to keep asking backend to make logic changes for state, so frontend took things into their own hands. The mistake was making it two separate teams.
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 :)
It won't be an intended use case, but it might be a convenient place to put poisoned content for the “benefit” of scrapers…
Though humans will accidentally find it too, so using a details tag with appropriate summary as a warning would be more friendly than just hidden content. It'll still get opened, but the user at least has a way of closing it again afterwards.
Also before using it I'd want to check what old UAs including accessibility tools tend to do when they hit a value that they don't recognise for the hidden="" attribute - would what they don't recognise as a valid value result in defaulting to the content being hidden or visible/read/other?
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.
Though that wouldn't have a method of closing the full image afterwards, if you have a few thumbnails and want one full to be open at a time (closing when the next is selected).
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 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?
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.
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.
>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 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.
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.
https://noscript.net/
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.
It's really easy to do this with server rendered HTML. Put a link with the sort param in the column headers and be done.
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.
Though humans will accidentally find it too, so using a details tag with appropriate summary as a warning would be more friendly than just hidden content. It'll still get opened, but the user at least has a way of closing it again afterwards.
Also before using it I'd want to check what old UAs including accessibility tools tend to do when they hit a value that they don't recognise for the hidden="" attribute - would what they don't recognise as a valid value result in defaulting to the content being hidden or visible/read/other?
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.
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.
Hopefully, never. There's enough ad-blocking arms race as it is.
And the date/time picker controls are too limited for many applications.
It’s all binding. This is what JavaScript is for: dynamic content.
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.
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.