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.
[deleted]
HTML Can Do That
51–60 of 249 posts
Re: HTML Can Do That
#52I'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…
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.
This is possible and, in my experience building them, the norm. SPAs have routers and update navigation state, including history for browser Back/Forward
Re: HTML Can Do That
#53Re: HTML Can Do That
#54What 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.
Do I understand that first one correctly as datalist without allowing the user to submit a value not on the list?
Re: HTML Can Do That
#55[flagged]
Exactly. Why reïmplement features in JS just because you can? Waste of effort and usually a worse user experience!
Wait, that wasn't what you meant?
Re: HTML Can Do That
#56See also: http://youmightnotneedjs.com/>
Re: HTML Can Do That
#57This 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…
I mildly disagree. You still have to validate what the browser gives you. The user could have edited the "strong contract" using browser dev tools.
So, let the user type, then validate in javascript if you want instant feedback (by changing colors, say, to red / orange), but ideally don't fully block it from being seen by the server. And do the real validation on the server side. This is what I found to be fairly robust, while allowing mitigations if a bad rollout breaks something (delivering to clients is slower than updating something on the server side, most often).
Re: HTML Can Do That
#58Earlier quoted context omitted.
You want client side table sorting? 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.
I used to do this in the early 2000s! Some folks back then would ask whether i was afraid that clicking a link (which loads a "new" web page) would slow things down and create an awful experience for users...but, my team and I would really focus on keeping web pages slim/lightweight to begin with...so it rarely was a problem. I don't think we were geniuses or anything like that, but keeping things light (always and f…
It still works exceptionally well in 2026 and generally creates better and faster experiences than an SPA with far, far less code.
Re: HTML Can Do That
#59Earlier quoted context omitted.
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.
Input fields are dynamic elements. Textareas can be resized. Pages can be scrolled. Why implement everything anew in custom code if it can be implemented once per browser engine in native code, native UI, and expected/homogenous UX?
Re: HTML Can Do That
#60What 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.
Do I understand that first one correctly as datalist without allowing the user to submit a value not on the list?
That, and how it's rendered needs to be separate from the value the the input gets. Just like `John Doe` or ideally even rich html like `123 John Doe`.
I guess the best way to render it would be exactly like `` when closed, but when opened there should be a search box where it'd normally show the first option.
Clicking search would call a javascript function, which could then adjust the set of available options via the standard DOM APIs.
Alternatively they could add support for a special element `` which can contain whatever you want, which would render fixed at the when the drop down is opened and can be interacted with like normal html elements. Then you could place your own search fields inside.