The <select> element can now be customized with CSS

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

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.

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

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

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

also drag and drop rearrange

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.

I don't think browsers will ever let web code affect things outside the viewport because scammers would cook up some truly zany things with that power.

I have, and failed.

See https://news.ycombinator.com/item?id=40265782

Definitely not. Why would they let web devs render outside of the browser window? That's a recipe for disaster.

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

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

Safari is the "new" IE. I put "new" in quotes because it's been this way for like a decade.

> Now, do autocompletes

This is kind of ready, see datalist element.

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

> 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

There needs to be some middle ground. I'd trade off just being able to set just the background color and font and keep these native-like features

It may not be present in Apple’s official documentation but it has been supported since Safari 12.2.

See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da... compatibility. The demo on that page works for me in current Safari on both iOS and Mac.

I'm not sure about this. It could break the positioning / sizing / box CSS properties.

That would require rendering arbitrary HTML in the native widget, outside the browser. And I think that would require putting WebKit in the native widget. Or, to maintain a "copy" of the widget that looks like the native one but uses WebKit to render things. Seems annoying to maintain.

(And there are the security concerns mentioned by the other comments)

If anything chrome is the engine with odd quirks you are forced to work around.

--- start quote ---

Back fifteen years ago IE held back the web because web developers had to cater to its outdated technology stack. “Best viewed with IE” and all that. But do you ever see a “Best viewed with Safari” notice? No, you don’t. Another browser takes that special place in web developers’ hearts and minds.

--- end quote ---

https://www.quirksmode.org/blog/archives/2021/08/breaking_th...

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

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

Yes, Safari is not exactly like IE because IE had a dominant user share once upon a time.

We don't see "best viewed in Safari", but we do see plenty of sites that can be viewed in Safari, despite the extra effort used to get them there. And I'm not even a regular chrome user.

I haven't found this to be the case in my experience.

Maybe it's just iframes that are the issue but they were a devil and a half to get working in chrome (or blink ig) without relying on third party cookies.

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.

If that's all your changing, then why can't you make do with the system default?

Thanks to humanity, supporting this is a surefire ticket to someone figuring out how to phish credentials through a <select> element.

Interested in what you are doing with the iframes. Something with complex authentication? I've been forced to use iframes a few times for 3rd party resources that should have been first-party (mostly with banks and credit unions), and have only had some styling issues on mobile (which have been overcome by using JavaScript and window.matchMedia to check for media queries).

For this case, I will often ask for the timezone, since that data is often updated on the operating system, but I don't believe it's often for someone to be in the same location and have their timezone change. The software that I've maintained the most over the years (since 2009 up to deploying an update today) requires a login, so I have a client account that includes choosing their timezone. I then use that to convert everything to UTC in the database, and when I retrieve the data, I use it to convert UTC back to their local date/time. I felt that it was the best option, since a user moving to a different timezone should still be able to get dates/times back relative to where they have their current timezone set.

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?

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)

Even rendering arbitrary pixels inside the viewport is bad enough. Something that went out of fashion but is apparently now back in fashion is detecting the user's operating system and browser, then displaying a pixel-perfect replica of a second browser window open to Paypal and asking you to log in... displayed within the bounds of the first browser window.

Chrome's quirks become the standard and other browsers have to implement them.

The following works for me in Chrome, and doesn't prevent the menu from going outside of the viewport:

    select, option {
        background: red;
        font-family: 'comic sans ms';
    }

Some examples seem to work better than others though. I’m on latest iOS and sometimes it will invoke the native date picker like you’d expect to see, sometimes it won’t, and the type ahead doesn’t seem to work consistently

I think this totally depends on the site in question. Seriously researching something is hell on mobile browsers. As is doing productive stuff. Who wants to work on a tiny screen and no keyboard? On the desktop you can open dozens or hundreds of tabs on a single topic. Therefore I'm not surprised to see that on my site (technical articles) I can see the number of requests from mobile devices is just 17%.

Windows is 52%, Linux (without Android) is 18%, Macintosh is 13%, Android 11%, iOS 6%, Chrome OS 0.5%, others <0.5%. (Android and iOS may include tablets, but the overall traffic from tablets is just a few percent.) (Note that I've excluded crawlers and unknown user agents (bots and crawlers) from these results.)

FWIW, some bots lie about what they are, which typically inflates the Windows results. I have another source of data, I can see what types of devices saw my site in Google results, and it's 69% desktops, 30% mobile, 1% tablets. (I can also see how many clicked, and it's similar numbers.)

Right. The offset is not enough without a reference recorded time. You need the time and the time zone in order know the true time. This is a big problem is systems that don't have an intrinsic time type that deploy and have a database full of ambiguous times. Once it happens, backfilling that is a real slog.

With these features scammers will create all sorts of "you have to log into your password manager" popups again.

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.

This works for things in the past but not things in the future.

If I say I want something to happen at 8pm New York City time on January 7, 2028 and then the DST rules for NYC change, I likely still want it to happen at 8pm. Converting to UTC and back to local time loses that information and it will happen at the wrong time.

Yeah, it only works in Chrome

The absolute vast majority of web sites require no effort to "get there".

The absolute vast majority of those which don't work in Safari use Chrome-only non-standards.

And there is a tiny minority of sites that run into some Safari-specific quirks

Certainly, there exists a middle ground between having no options for styling and some options where we don't compromise users

That demo shows the problems splendidly. It “only kinda” works on iOS.

I think that you can compose arbitrary images that way using an image-like font (using various Unicode chars and assigning to each a small tile of the full image)

Actually I am now curious of how much detail/size/colours/animations you can fit in a single letter.

This is why the new login prompt of 1Password is worse than the old one, it appears at the center of the screen where the website could easily put a replica. The old one opened at the height of the extension icon, a bit above where the browser opens the alert dialog

I 100% agree with you, and don't set cron jobs/scheduled tasks this way. I only use this for displaying date/time to users.

With that said, I do appreciate the comment, and would have to make sure that if I run scheduled tasks in the future, they are run when the user wishes them to be completed based on when that user sets it to be completed (so would most likely not convert to UTC, and save the timezone with the date/time).

I'd much rather have it just use the system time, which is already available over a javascript API. I wish it just were included in your html form datetime-local request.

https://caniuse.com/mdn-javascript_builtins_intl_datetimefor...

or appending the `Date().getTimezoneOffset();` to receive a ISO8601 timezone offset