Hacker News

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

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.

> Now, do autocompletes

This is kind of ready, see datalist element.

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

> 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.

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

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

I agree that this is a huge improvement, but it's also over a decade late IMO. This should've been accomplished well before now, especially given that the issue has been there since the beginning.

This is true, and I try not to get eager about new browser improvements for this reason. But look at the porgress over time in browser abilities, it's astounding.

The days are long but the years are short.

The perpetual 5 year problem of web development. I wish there was a way to do forward standards

> But such is always a good practice anyway.

One more reminder to develop for people who may not perceive color and shape as you do. If you're hiding critical information in your menu styles, that information is presumably inaccessible to people who are using a screen reader.

This might be a bad take, but I think developers should also consider exactly which users are using their app. If it’s the entire internet, then absolutely you need to consider backwards compatibility. If it’s an internal app, then consider not caring and using new APIs.

You'll probably still keep a <div>-based control in your page, and selectively hide the <select> based one or this one, or generate different HTML for different browsers if you can do that.

This is only if you opt in to base-select, so if you don't use that, everything should continue to work the same, as far as I can tell.

Chrome already uses plenty of non-native components. Firefox is similar. Moreover while I can understand the concern about poorly implemented components from random web developers, Google is probably the best positioned to implement a widget that faithfully replicates the native equivalent, at least on Android.

This ship sailed in 2000. We've been hacking custom select boxes since then, so we may as well pave the cowpath. And besides, as a user, I want stylable select elements. Seeing an ugly old select box in the middle of a site where everything is styled consistently is jarring.

And it doesn't get the job done. You can't put stuff like SVGs or complex DOM elements in them, which is a valid use case. Most of the time, when people create custom select boxes, they ignore accessibility. This will fix that issue.

This is more about rich HTML for the select options. Being able to select images, rows with two columns of information, extra information in a contrasting font weight, etc. This will be extremely helpful.

managed even to remove scrollbars altogether from their website

What's worse are the custom JS ones that only appear on hover, obscuring the contents partially where they happen to be, and then when you try to drag them and accidentally move the pointer just a tiny bit off their skinny width, they disappear and you end up accidentally activating whatever element happens to be underneath.

Unfortunately those unusably small or invisible scrollbars are the default in many browsers. Such as Firefox on Linux, which I'm using right now.

I disagree. On my website I have a sidebar and a main content area. You are able to scroll through posts on the sidebar and through the content on the main content area. The sidebar is a dark color. Being able to use a thin sidebar and make the color of the sidebar dark to match the background makes the website look a lot better than having a clunky white sidebar on a dark background.

The user can still obviously see the sidebar and knows its a sidebar, it just works better with the design.

I may not agree with your ugly scrollbars, but I will defend your right to style them.

(If you want to annoy your users, that's your prerogative)

I just tried it in the Codepen and it reverts to a regular old UI element when it has the multiple attribute.

Also just tried it with multiple="multiple" just in case. Same behavior.

> This looks like what web developers have been waiting literally decades for.

Count me in. Most times it didn't matter to me but there were some cases when I wanted or needed them to have a specific style matching other elements and, yes, I could only do it -to the best I knew- with JS.

Let's see if it becomes widely supported.

It’s the web equivalent of the Twitter account that added “in mice” to medical headlines. Nice in theory, but it’ll take years before it’s usable and in all likelihood it’s just another experiment that’ll never go anywhere.

So at least 5 more years until in can actually be used.

Can't wait to use it in 2030 when my work stops supporting IE11

> priority: Not set

Last update to the issue is a pointer to test results:

https://wpt.fyi/results/html/semantics/forms/the-select-elem...

At least Safari is failing as well, currently, so the FF team has a bit of time.

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

>Yeah so this is scary, but how is layouting done then?

Via HTML in-website, not via opening the android wheel picker or anything like that.

This is badly needed. Until we have combobox, the <select> is best implemented as a readonly combobox, because you need to implement combobox in any case.

This is also very much how the page looks for me in Firefox. If it can't fail without issues it's not an option I'd select.

what's to love about this?

Hey! Actually that is possible using the <datalist> element.

If you're interested, I wrote a bit more about it here: https://harrisonbroadbent.com/blog/cool-native-html-elements...

Backwards compatibility. Older browsers will still be able to render the <select> and submit it as part of a form, just with its options unstyled.

`attr()` has had terrible support which is a shame because it's been around for ages and could have let us do a lot of things without having to implement stuff manually.

There's another way to try it though...

I'd try putting two separate <span>s inside each option, one for the short description and one for the long description.

I'd hide one span with css if it was inside an <option> tag.

I'd hide the other span if it was inside a <selectedoption> tag.

That would probably work.

The papercut would be that when gracefully degrading back to an ordinary select element, it might show both the short and the long selections which depending on how you write the content may or may not be an issue.

I don't see how it would create a loop? It seems like the parser change only impacts <select>'s descendant elements (to stop "cleaning" them of illegal elements), not <select> itself.

As I remember the arguments from 20 years ago, there was strong pushback against changing any form inputs, which the people who did such work said should appear as the operating system itself styled them (so users would recognize them as form inputs).

Should be able to style more than just selects, after all. Why the fuck can't I change the mask character in a password field to be something other than bullets? Hah. I had better examples too, but it looks like in the past 10 years or so, they've slowly been CSS-ized. Nice. Now if I could just style half the first line (first-line does the entirety of the line or nothing).

There is no one truly in charge, it's a distributed standard

Because HTML historically was designed for marking up text articles by hand rather than building UI with tools.

Priorities? Profit incentives?

I'm sitting here for a few years already, happily using Safari as my main driver. Recently switched to Orion to get Safari + Chrome/FF plugins. Best combination.

Easy on the battery, freaking fast, low ram usage, and plugin support (ALSO on iOS, yes, uBlock on iOS). Screw firefox, screw chrome.

Yes, I also dev on Orion. The dev tools are fine.

I'd love to know the opportunity cost - billions?

On the contrary. It's CSS, you can change all of this in your browser's CSS overrides if you want.

> and firefox will become even less relevant

No; Firefox can easily afford financially to add this feature. Firefox is already irrelevant; no developer will shed a tear about just blocking Firefox if they refuse to implement. Boycotting won't work either, because boycotts almost never work.