alt Hacker NewsProgress 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
Replies
> 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.
> 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.