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
> it's annoying to get it right, and this kinda can't be fixed, because HTML is under a lot of backwards-compatibility constraints
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 with autocomplete=off is some morons think they should use it on their login form for "security" or whatever, cause forcing users to type in passwords is "secure". So browsers wound up having to ignore it for actual security.
Browsers could have instead allowed me to right click and say "insert password because I know what I'm doing". But browsers are in the business of training users to be stupid, rather than acting as a user's loyal agent, so I guess we were mercifully spared this future.
This creates band-aid after band-aid. Like every user-agent is mozilla now.
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.
I am one of those morons who had to build a page for someone to go to the nurse's office and input all their information without it being saved for the next person who goes there to fill their information.
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.
> 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.
Yes, disabling autocomplete can be annoying, but it is possible. Usually it amounts to being more descriptive in the value of the `autocomplete` attribute, rather than simply applying `autocomplete=off`.
> 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.
> Usually it amounts to being more descriptive in the value of the `autocomplete` attribute
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.
Believe it or not, I have observed autocomplete behavior for an input change based on its label text.
> 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.
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.
> Autocomplete "bugs" abound aplenty
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.
You sound like you are not ready to face reality. I put it to you that I have observed _numerous_ deviations from the autocomplete spec that defy all logic.
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.
> 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.
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)
> 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.
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...
> and act on them with JavaScript
I thought the whole point was to avoid JavaScript, by having rich UI components built right into the browser
Sure, but what kind of image manipulation do you think would actually belong in the HTML spec? That just seems way out of scope to me.
Why not something similar to what iOS has? Or Windows?
They all have functional built in image editors. They're very light weight, and are not meant to replace a dedicated tool, but if all you want to do is crop an image or other relatively simple tasks, there's ample evidence on other platforms that providing these minimal tools is big value to users.
> 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.
This is probably the reason why someone invented the <canvas> element?