[skgough]

Another selfish reason: web pages just work a lot better when you use the actual HTML elements, especially when you compose them together. React projects often mix several component libraries together to make a comprehensive UI. All of these libraries behave differently in subtle ways. When you compose them together, the differences compound: focus is not restored to the button that opened a dialog when it is dismissed, there are 4 different blues used on the page, the date input doesn't use your country's date format.

When you use HTML primitives like inputs with associated labels, the new popover API, dialogs, details + summary elements, their behaviors are all made by the browser vendor and are designed to compose with each other. It really is a difference of night and day, and for free. We don't take advantage of the amazingly powerful tools we have been given.

[Flimm]

I wish I could agree with you, but in my experience the built-in controls have many flaws and have remained stagnant for years or decades.

[dgb23]

Btw that's largely our (web devs) fault.

https://extensiblewebmanifesto.org/

Good intentions and some good ideas. But ultimately lead to a fractured, overly complicated and bloated web.

I say yes to lower level, more general capabilities. But why does that have to mean we get bad APIs (web components, indexeddb, service workers...) and lack fundamental and well established UI components (combobox, toggles, tabs, tooltips, data grids...) and incomplete implementations (lacking HTTP verbs for forms)?

(Also why we're at it, I'm going to sneak in a complaint about half baked and broken language features like `const` and `import`. Also we shouldn't have abandoned Do-Not-Track...)

[flomo]

Just some blatantly obvious examples: Select Multiple was some Windows 3 garbage, and HTML didn't have a 'combobox', much less a 'multi-combobox'. (MDN says datalist is not supported on Firefox, so maybe it still doesn't.) So write it yourself, or use a library. The form validation stuff is still bad, and idk if modern desktop browsers have a good date control.

[ozim]

Second that and from my experience they are just not feasible for any modern web app.

Those controls work fine maybe for a static form on a website as parent wrote - but web applications are not websites...

[naavis]

What kind of flaws did you have in mind?

[Toritori12]

I dont remember last time (if ever?) I saw a native date input in the wild.

[bob1029]

Last product I worked on I made this a thing. Every modern browser now renders a very competent date picker for input type="date".

I find a lot of the arguments for building inaccessible UIs seem to conflate historical web issues with modern times. Virtually everything that sucked in the core web toolkit circa 2010 has essentially been solved in 2025, even on ultra-restrictive platforms like iOS Safari.

[cardanome]

I have recently used plain old html date input in a internal tool and it works great.

Not the prettiest but I have seen much worse custom ones that were super buggy.

[dgb23]

Native date inputs have their problems, but I default to them usually because they typically have the best behavior on mobile and are localized by default.

[pelagicAustral]

textbox is the warriors way of date input. Anything else is cruft. /s

[PaulHoule]

Quite a few 3rd party controls have had attention paid to accessibility and have all the right aria- and other accessibility markup.