So after decades of developer pain, all we're getting is a better select?<p>Where is the native HTML datagrid (that supports sorting, filtering, paging, downloading, row/column freezing, column resizing and re-ordering)?<p>Where are the native HTML Tabs control? Image selector, resizer/cropper, and uploader? Toggle button? etc.<p>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.<p>HTML is really holding us back right now.
I've been doing front-end since the days of IE5 and I'd be rich if I had a penny for every time I've had to do a custom "select". It's a pain to use third-party libraries for this, but it _is_ a solved problem and doesn't require that much extra code.
I spent days building this little perfect dropdown select thing, that is a hundreds lines of code and even more docs explaining what the hell is going on. Someone wasted the same amount of time before me. Someone else spent a lot of time before them. And so on.<p>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.<p>---<p>Eventually, this would be same as border-radius. It will get implemented and we'll forget about that forever.
Yes please, like everybody else I had to make a custom one <a href="https://radogado.github.io/n-select/" rel="nofollow">https://radogado.github.io/n-select/</a> and will be happy to move to a rich standard
- Why is picker a function like `::picker(select)`, and not a CSS pseudo class like `::before` to select the `select`'s `picker` component? I.e., `select::picker` makes a lot more sense to me.<p>- What about multi-choice (`multiple` attribute) `select`s?
I don’t really see if there’s now an option to further improve the select with JavaScript to add, for example, a search textbox for filtering.<p>And what about the nearly unusable (on desktop) <select multiple>?
They been talking about this for a long time.<p>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.<p>From the looks of it, didn't work out that way though.<p>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
This is a very good start, I don't think it'll replace a lot of the custom code/comboboxes that are seen in react-land without search (unless I missed it).
I've been griping about html's select for some tome - <a href="https://paulhammant.com/2013/01/31/appdev-glass-ceiling-revisited/" rel="nofollow">https://paulhammant.com/2013/01/31/appdev-glass-ceiling-revi...</a> - great news
I worry this will lead to a bad user experience if android et al does not support it natively.<p>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'm hoping that the documentation around this will be good, I've recently tried out CSS anchor positioning and it's riddled with examples that no longer work as the specification has been changed various times
this is a huge win for accessability.<p>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.
Yeah now if they can go ahead and make ThreeJS line thickness be more than 1 that'd be greeattttt....<p>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