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.
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
Sorry, but this seems like a wild mischaracterisation, at least in regards to the problems I've had with users on Chrome. In our experience, Chrome aggressively shows an autofill prompt on almost every input it can. It also ignores the specced autocomplete=off attribute. We have observed Chrome showing a password prompt on an <input type=number> which is just bonkers. It is not hard NOT to do this.
The Chrome team thinks whatever heuristic they're using is better than allowing developers, or even end users, to control filling behaviour.
https://issues.chromium.org/issues/41163264 https://issues.chromium.org/issues/41239842
(By "autofill" I don't necessarily mean the input is automatically filled without user interaction, but sometimes a promotions shown with e.g. account login details or an address.)
The argument has been that developers are naughty and turn off autocomplete inappropriately, which worsenes accessibility. But I've never seen e.g. a tooltip option in a browser to let me, the user, fill in details when I know they're appropriate? I am merely at the whim of the Chrome algorithm.
Problem is we (my development team) didn't own the tablets, some other team did so we couldn't force the tablets to have in private browsing.
Well, too bad, because that's exactly what the solution should be.
Repeat after me: never fuck with spec implementation. If you don't like writing to a spec, write other types of software.
Let the ecosystem (website owners) face consequences of their own actions. It is better to blacklist bad actors then filling your software with bugs.
> We have observed Chrome showing a password prompt on an <input type=number> which is just bonkers.
"We have observed" it, but not filed a bug? Neither of the bugs you linked to exhibit that bug.
No, there are many inputs where there is no sensible autocomplete value. For example, "create a new CRM customer record". This is a new customer who I have not seen before. By definition it is impossible to autocomplete.
In the past, the Chrome team advised to "make up an autocomplete value and we won't do anything with it". This advice is a) dumb and b) no longer works anyway.
> but not filed a bug?
It's clear the Chrome team has no interest in fixing this behaviour so I'm not going to waste my time. Yes, that's bad of me, but I have bills to pay.
This just selects the image. 99 times out 100, you want to do the same things with the image data: adjust it in some way, and save it to object storage or something. The file input is too primitive for this. And this is the theme all over, HTML control remain too primitive to do any real world rih UI with, which leads to the proliferation of JS UI libraries.
> 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
Autocomplete "bugs" abound aplenty, some of which will make your jaw drop. I've been testing with Chrome and Firefox. The length to which browsers will go in a misguided attempt to be clever with auto-complete is frankly absurd. So I'm not sure they are "bugs" so much as they are a wilful refusal by browser vendors to follow the spec.
No, there's just the one "bug": browsers ignore autocomplete=off.
And, as you say, the browsers regard that not to be a bug, because when they honor developers request to prevent autocomplete, users keep filing bugs on the browsers, saying "why won't you autocomplete this??"
Put something descriptive in the autocomplete, instead of "off", and you're usually fine.
Consider the "State of HTML" survey of form pain points. https://2024.stateofhtml.com/en-US/features/forms/#forms_pai...
See also the "missing elements" section. https://2024.stateofhtml.com/en-US/usage/#html_missing_eleme...
An image cropper didn't make the list. Data table did! But it's pretty complicated, and, as I said, progress is slow. Partly that's for backwards compatibility reasons, and partly it's because you have to get Apple, Google, Microsoft, and Mozilla to all agree on anything, and that's really hard.
Autocomplete is on the list of pain points. But it's wayyy further down the list than having a customizable `<select>`. Styling & customization, validation, and `<input type=date>` are all bigger pain points than autocomplete.
If you want a laundry list of them, I'm ready to list them all in their gory details here, but I suspect you have made up your mind irrespective of the facts.
That's kind of a bonkers expectation for the browser to fill. It's like expecting that <input type="audio" /> should let me crop the audio and add reverb to it. That's two specific manipulations out of untold thousands, and squarely within the purview of a different app. https://editor.audio/ (never used this, just an example)
That's not true at all. Obviously there's no `adjustinsomeway` or `savetoobjectstorage` attribute on the <input> element, but you can trivially grab the selected files, read them, and act on them with JavaScript: https://developer.mozilla.org/en-US/docs/Web/API/File_API/Us...
I thought the whole point was to avoid JavaScript, by having rich UI components built right into the browser
This is probably the reason why someone invented the <canvas> element?
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.
https://www.w3.org/WAI/ARIA/apg/patterns/grid/examples/data-...
Pagination could be argued as well, but at least that's simple-ish to implement (but still, it's such a common UI pattern that it ought to be handled in a unified way by browsers IMO)
If it has to take decades to agree on a design for a stylable select box, then there is something fundamentally broken with the approach.
It's an arms race of stupidity.
(I say "for now" because who knows when the Chrome team will change their heuristic?)
Not all inputs are form-submission data.
For example a datalist-backed input to scroll to a specific page/chapter/section/subsection in a long document. You might populate the datalist with hundreds of entries so you don't have a long list of links that the user will have to scroll through in the sidebar. You can perform the scroll on the change event of the input.
That's a good UI for the user, instead of presenting a long list of links for the user to browse/search through, they simply have the input auto-suggest based on the populated datalist.
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.
https://schepp.dev/posts/today-the-trident-era-ends/#data-gr...
The best we'll get is little improvements like this which everyone will ignore because ChatGPT will recommend some react component instead.
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.
The W3C and WHATWG have their priorities mixed up.
And they prohibit different browsers from the app store, so users don't even have a choice.
Nothing with customizable built-ins would give you what the original commenter asked for
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)
That's called <table>.
https://old.reddit.com/r/PleX/comments/mr1k8m/just_discovere...
21% the size of the code of the Apollo Lander to configure/style a select dropdown.
This is something I actually look forward to being able to use when Firefox gets it.
(And yes, I'm still bitter about you all wrecking my scroll bars.)
I wish we have had more browser native implementations including some notion of virtual lists so the browser would not choke when rendering a lot of content.
---
Eventually, this would be same as border-radius. It will get implemented and we'll forget about that forever.
I wonder why is this not happening widely.
1. You get HTML attributes to pass data in, or JavaScript properties. If you're in React, you'd just use a React component and skip web components. If you're in vanilla HTML, you can't just write HTML, you have to build the component with the DOM.
2. There's no real standard to making web components look the way you want them to. You can't just use CSS (you have to have the shadow root "adopt" the styles). Your point of "make it styleable" is actually one of web components' biggest weaknesses (IMO).
3. Web components are globally registered. React/Vue/Svelte/etc. components are objects that you use. You end up with a mess of making sure you registered all of the components you want before you use them (and not registering the ones you don't use) and hope no two packages you like use the same name.
Not exactly. There’s the ::part() pseudo-element selector, which allows you to target an element in the shadow tree that has a matching part attribute.
<some-element>
<input type="text">
</some-element>
Now take this:
<some-element>
<textarea>…</textarea>
</some-element>
Now take this:
<some-element>
<select>
<option>…</option>
</select>
</some-element>
Web components are full of all of these random footguns.
This isn’t true at all. You’re doing something incorrect when creating your shadow root or adding your styles. (“Web components” aren’t really a thing - it’s a marketing term for a set of technologies - so I assume that you’re talking about custom elements with shadow roots here.)
> It will not select #three (no slot attribute) nor #four (only direct children of a shadow host can be assigned to a slot).
— https://drafts.csswg.org/css-scoping/#example-7cc70c2d
I’m talking about the #four case.
Alternatively, refer to the issue that was opened in the web components issue tracker here:
> > you can only select a direct item within the slot
> That is by design. See #331 for details.
> We don't have a plan to support an arbitrary selector for ::slotted.
— https://github.com/WICG/webcomponents/issues/594#issuecommen...
> “Web components” aren’t really a thing
This is an empty nitpick. The people writing the specs call them web components, the people implementing them call them web components, the people writing them call them web components. There is nothing wrong with calling them web components.
> I assume that you’re talking about custom elements with shadow roots here.
You don’t have to assume anything. I explicitly said that it constructed a shadow DOM.
- What about multi-choice (`multiple` attribute) `select`s?
I am genuinely afraid for the future of CSS as it is becoming increasingly more complex, meanwhile most people haven't been able to properly utilize or understand it for the last decade even without all of that additional complexity.
And what about the nearly unusable (on desktop) <select multiple>?
select multiple: both the enhanced select and combobox plan to support this
Combobox: https://open-ui.org/components/combobox.explainer/
Enhanced Select: https://open-ui.org/components/customizableselect/
For better or worse, this element is not obvious for those who didn't grow up using desktop computers 10+ years ago.
The real issue I have with the web is everyone has broken user interface consistency across the platform with custom web controls where the default controls would be fine.
I agree that the feature/appearance/accessibility inconsistency you get from reimplementing the controls is a problem, but I think the right way to fix it is to raise that common floor of what the web platform provides. People want, e.g., comboboxes, they've been around forever in UI toolkits, but the web's standard answer for them is still pretty terrible, so it's no surprise that people reach for the libraries that replace the whole thing.
In fact, I remember at some point, they were trying to sell the idea of exposing all the form inputs to use the `::part` API, since under the hood form inputs share the same general logic of custom elements, If I recall correctly.
From the looks of it, didn't work out that way though.
And I think its for the best. I like this proposal more, even though delivering the `::part` API to everyone (not just web component users) would have likely been faster
But this article isn't an example of Chrome-only CSS, this is about a change to the standard select element to make it customizeable in a standard way. It's not fully frozen yet, so they're seeking feedback and still working on it, so if you have input to give about this feature I think they'd welcome it. This blog post was about Chrome introducing experimental support for it, likely so developers can experiment with it and provide more valuable feedback towards its standardization!
> A customizable version of the select element is officially in Stage 2 in the WHATWG, with strong cross-browser interest and a prototype for you to test out from Chrome Canary 130.
Don't do something - OMG, Chrome is dragging their feet. Why can't they do it? It is standards track after all
Do something - umm, it'll be only on Chrome for a really long time.
At least be a bit consistent with your qualms.
As far as accessibility, the native browser select is almost always going to be more accessible than someone making a custom input using JavaScript so they can add some styling control. Having the native version support basic styling is a big accessibility win IMO, because it disincentives developers from making a less accessible alternative for the sake of matching some design file.
> A customizable version of the select element is officially in Stage 2 in the WHATWG, with strong cross-browser interest and a prototype for you to test out from Chrome Canary 130.
How will input-inside-select be better than a datalist?
(Genuinely curious, not being facetious)
The select also differentiates between the value and the presentation text. With an input you would have to use the text to find the value in your db or put the value in a hidden input in the front end.
You'll have people saying "select the green option in the drop-down list to do <foo>" and people on mobile will just get the native-ui list with no styling.
i've re-implemented select in worse and less-accessible ways many times to satisfy some business demand. i'm very excited if this means i don't have to keep doing that.
https://caniuse.com/selectlist
The blog post says that "we're excited to see this feature progress through working groups and standards bodies" but doesn't link to anything that would help figure out which standard this ostensibly implements.
edit: this is a joke about "OpenGL Core Profile with the WebGL renderer" which I'm not sure if Chrome (browser) would be responsible for
const material = new THREE.LineBasicMaterial( { color: 0xffffff, linewidth: 1, linecap: 'round', //ignored by WebGLRenderer linejoin: 'round' //ignored by WebGLRenderer } );