alt Hacker NewsSo after decades of developer pain, all we're getting is a better select?
Where is the native HTML datagrid (that supports sorting, filtering, paging, downloading, row/column freezing, column resizing and re-ordering)?
Where are the native HTML Tabs control? Image selector, resizer/cropper, and uploader? Toggle button? etc.
We can't even get text input to respect autocomplete directives properly. On the major browsers, giving your user id and password inputs nonsensical names seems to be required, along with numerous other hacks, to ensure that when a user is registering, the form is not auto-completed with saved passwords.
HTML is really holding us back right now.
Replies
Datagrid is mysteriously missing on several newer desktop UI frameworks too, which effectively makes those frameworks ill-suited for a whole range of desktop applications. The only place reasonably batteries-included versions of those widgets can be found are in the old guard toolkits like AppKit, win32, MFC, Qt, GTK, etc.
> Where is the native HTML datagrid
Which parts of a datagrid should a browser provide? I'm familiar with AG Grid [1] and the API surface is enormous. Aligning browsers on a feature set would be challenging.
Maybe there's a core set of functionality, like Flutter's GridView or QML https://doc.qt.io/qt-6/qml-qtquick-gridview.html.
Imo it’s not html, it’s browser vendors. There’s a decent specification for the `autocomplete` attribute: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...
RE autocomplete in Chrome. The only thing we've found to work reliably is ensuring that all inputs are in form elements. Any inputs outside forms are going to have inappropriate autocomplete prompts. It's extremely annoying but at least this works for now.
(I say "for now" because who knows when the Chrome team will change their heuristic?)
I'm just glad I don't have to support IE6 anymore.
> Where is the native HTML datagrid
Imagine a world where instead of letting IE die, microsoft decided to add a <XLS> tag in the early 2000. The most used nocode database in the world directly in the browser. In 2000.
Internet Explorer had a native Data Grid with two-way data binding and much more.
https://schepp.dev/posts/today-the-trident-era-ends/#data-gr...
HTML can never be meaningfully improved, that fact is at the heart of the current attitudes by the browsers. We are 20 years into the takeover from the W3C and still can't even do a PUT request without JS, nevermind anything approaching even one tenth of the capability of XForms.
The best we'll get is little improvements like this which everyone will ignore because ChatGPT will recommend some react component instead.
I think some of this stuff isn't the responsibility of HTML. If HTML already has a full autocomplete spec, isn't it the fault of browsers/extensions/OS if the implementation is broken? Or are you saying the spec is too ambiguous?
A lot of stuff becomes redundant under the framing that HTML is designed to provide semantics, not a user interface. How is a toggle button different from a checkbox? How are tabs different from <details>, where you can give multiple <details> tags the same name to ensure only one can be expanded at a time?
Image manipulation is totally out of scope for HTML. <input type="file"> has an attribute to limit the available choices by MIME type. Should there be special attributes for the "image" MIME type to enforce a specific resolution/aspect ratio? Can we expect every user agent to help you resize/crop to the restrictions? Surely, some of them will simply forbid the user from selecting the file. So of course, devs would favor the better user experience of accepting any image, and then providing a crop tool after the fact.
Data grid does seem like a weak spot for HTML, because there are no attributes to tell the user agent if a <table> should be possible to sort, filter, paginate, etc. It's definitely feasible for a user agent to support those operations without having to modify the DOM. (And yes, I think those attributes are the job of HTML, because not every table makes sense to sort/filter, such as tables where the context of the data is dependent on it being displayed in order.)
Generalized rant below:
Yes, there are pain points based on the user interfaces people want to build. But if we remember that a) HTML is a semantic language, not a UI language; and b) not every user agent is a visual Web browser with point-and-click controls, then the solution to some of these headaches becomes a lot less obvious. HTML is not built for the common denominator of UI; it's built to make the Web possible to navigate with nothing but a screen reader, a next/previous button, and a select/confirm button. If the baseline spec for the Web deviates from that goal, then we no longer have a Web that's as free and open as we like to think it is.
That may be incredibly obvious to the many Web devs (who are much more qualified than me) reading this, but it's not something any end user understands, unless they're forced to understand it through their use of assistive technology. But how about aspiring Web devs? Do they learn these important principles when looking up React tutorials to build some application? Probably not—they're going to hate "dealing with" HTML because it's not streamlined for their specific purpose. I'm not saying the commenter I'm replying to is part of that group (again, they're probably way more experienced than me), but it reminded me that I want to make these points to those who aren't educated on the subject matter.
I'm not finding any of those proposals on the whatwg html repo, mind linking them?
Right? There are already dozens of deprecated elements, just deprecate these too and give us new ones that actually do what they're supposed to do and don't require us to know the entire history of HTML just to do a dang <select> that isn't ugly.
Safari already has toggle buttons and autocomplete directives.
you forgot the most important one, where s the browser native virtual list, grid and table?
Apple’s webkit team killed customised built-in elements by refusing to implement them on ideological grounds, so you get a dripfeed of piecemeal solutions instead.
> Where is the native HTML
14 years have been wasted on making web components happen, and they still offer... nothing really, and people already advise to skip large portions of their specs (Shadow DOM) even if you adopt them.
Imagine if the literally millions of dollars spent of them were spent on something like https://open-ui.org/ (started by Microsoft of all companies and now also completely overrun by Googlers)
Please forgive my tangential rant on the DOM. You have an input field where type=number and when you read it with .value() you get a string. Cmon man.
> Where is the native HTML datagrid (that supports sorting, filtering, paging, downloading, row/column freezing, column resizing and re-ordering)?
That's called <table>.
Progress is very gradual in this space, but browser vendors are working on a lot of this stuff in the Open UI W3C community group. https://open-ui.org/
https://open-ui.org/components/combobox.explainer/ https://open-ui.org/components/switch.explainer/
> Where are the native HTML Tabs control?
You implement tabs today (aka accordions) with `<details name="tab">`. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de... "This attribute enables multiple `<details>` elements to be connected, with only one open at a time. This allows developers to easily create UI features such as accordions without scripting."
You do have to write some CSS to align tabs horizontally, but it's fine.
> Image selector?
Use `<input type="file" id="avatar" name="avatar" accept="image/png, image/jpeg" />`. Opens the OS photo picker on mobile. You can style it however you like.
> We can't even get text input to respect autocomplete directives properly.
"Properly" seems to be doing a lot of work there. "autocomplete" works fine, but it's annoying to get it right, and this kinda can't be fixed, because HTML is under a lot of backwards-compatibility constraints.
If you have autocomplete bugs to file, file them, and maybe convince the Interop group to focus on this issue. Their priorities for 2025 were just announced, but there's always next year. https://web.dev/blog/interop-2025