> Interesting. How would this specification look, in context of browser standards?

I don't know how browser standards work. As an end-user, our feedback doesn't seem to be considered (see the recent XSLT discussion), never went through the trouble of finding out.

In terms of implementation, sure we don't need it to be backend aware (was just throwing that out there as a common pattern for which one reaches to components in frontend frameworks). What they could do is build upon datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... . There are two things they could do with that element to make it usable in this context.

1. A loading indicator, which could be enabled with a bool element property while the Javascript code fetches from the server the data and updates the datalist options. 2. Decouples presentation from value. In a standard select field the option's value can be (and often is) different from the label. In the case of datalist it's not possible. It basically autocompletes on the values that also act as labels.

> Not possible for the majority of use cases. Too much variation in what the date is used for and how the display must be constrained.

On almost all of my personal projects, I just use the built-in date and time pickers available in browsers. I very rarely can do so for client projects, because the inconsistent rendering and patterns across browsers. Having a fixed way of rendering and interacting with those input fields would go a really long way.

You're right on all those things related to constraints, and UX. But for most CRUD experiences you really need only a consistent cross-browser picker, instead of reaching for a component library. Some of what you're talking about can be handled with the browser based Javascript validation, while a couple tailored interfaces makes sense for essential flows where you want to improve user experience.

I've built my fair share of custom forms and controls for the critical flow, but for the common case, accessible (most component libraries weren't in the past) built-in components are better and generally good enough.