[wolframhempel]

The fact that I'm disproportionally excited about this probably dates me as an early 2000s web developer. But since selects can do things that you simply cannot recreate in HTML, e.g. have options drop downs that extend outside the viewport boundaries, makes this a really helpful feature.

Now, do autocompletes and tag selectors next...

[asddubs]

I doubt it'll still be able to do those things. From the article:

>Using base-select loses a number of features and behaviors:

> The <select> doesn't render outside the browser pane.

> It doesn't trigger built-in mobile operating system components.

I have mixed feelings about it. Mobile users, get ready for poorly optimized select elements. On the other hand it reduces the need for javascript for styling forms, which is good

[cush]

> The <select> doesn't render outside the browser pane. ... It doesn't trigger built-in mobile operating system components.

To me, this is intrinsically what makes a <select> a <select>. Styling is great, but without these features, this doesn't really bring anything new to the table

[kmeisthax]

For the record, there's already a bunch of custom select-a-like replacement elements out there; I'm partial to select2. The main reason for this is that selects don't come with what we used to call "combobox" features; there's no type-ahead completion, and you can't lazy-load options from a larger data source because of that.

My main gripe is the loss of rendering outside the browser pane. To be clear, we already don't have that on mobile at all; if you've ever used an iPad with Stage Manager you'll note how popovers - all of them, including native apps - are neatly conformed to the bounds of the containing window. Pop-over menus are supposed to break the window pane, but they don't, for reasons I don't quite understand but can guess rhyme with the word "security".

[Eric_WVGG]

"It doesn't trigger built-in mobile operating system components." Is that part of the spec? I can see Apple deviating from that implementation.

[immibis]

Mobile users are the majority of users by far. Do web designers really make their sites hostile to most of their users? (I suspect the answer is yes)

[wolframhempel]

That's fair, but I assume that is the initial implementation. Surely, over time, browser vendors will want to make the full spectrum of select functionality available consistently.

[majora2007]

It's actually crazy that we don't have a basic typeahead component or tag selector in this day and age with HTML. Every web page I've ever built has needed these components and while there are libraries out there, they all have an annoying bug here or there.

But considering we are just now getting Select tags with styling, signals how long it might take for a typeahead which is vastly more complex.

[cosmic_cheese]

Why implement broadly useful HTML widgets when you can instead put those engineering resources to work on a new WebBeer API that fetches the number of beers in the user’s fridge or something else similarly niche?

[jhardy54]

> basic typeahead

It isn’t perfect, but have you tried <datalist>?

Totally agree about tag pickers, I was bummed to see that Bootstrap didn’t have a tag selector component either.

[asddubs]

also drag and drop rearrange

[renerick]

> have options drop downs that extend outside the viewport boundaries

Unless this is about something different from what you mean, unfortunately, it's not the case, as stated in the article:

> Using base-select loses a number of features and behaviors:

> The <select> doesn't render outside the browser pane.

[kkarpkkarp]

> Now, do autocompletes

This is kind of ready, see datalist element.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...

[porridgeraisin]

I know about datalist, but it's the saddest autocomplete experience you can offer. If something is not fully styleable, it's automatically garbage. If it's styleable, it may be decent.

Now, I understand why datalist is not styleable the way it is implemented right now. On Android, the suggestions come on the top bar of the native keyboard, so it doesn't make sense to be able to put arbitrary divs there. But in that case, there should be an alternative styleable autocomplete element.

Another element that is unstyleable crap is <input type=file>, <audio> too.

[preisschild]

<input type="datetime-local"> with automatic ISO8601 timezone offsets would be awesome too!

[sublinear]

ISO-8601 is not the correct format for serializing local time unless it's in the past.

In my experience, a local datetime picker is going to be used almost exclusively for a future date and time. What you want instead of a timezone offset is a zone ID. That way date and tzdata can handle it properly on the backend.

[blatantly]

Ooh I can render arbitrary pixels outside the viewpoint. Like a system dialog asking for a password.