[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

[wruza]

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

[tadfisher]

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

[cush]

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

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

[jraph]

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)

[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)

[qiqitori]

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

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

[caesil]

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.

[immibis]

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.

[afiori]

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

[dbbk]

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

[cush]

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

[eurleif]

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';
    }

[cush]

Yeah, it only works in Chrome

[afiori]

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.

[maccard]

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