Will the stylable <select> element be able to break outside the browser window?

[guillaumebrunerie]

I remember that an earlier version of the explainer (when it was still called <selectlist>) explicitly pointed out the fact that unlike the <select> element, <selectlist> would not be allowed to break outside the browser window.
But I can't see any mention of that anymore in the current version, is the plan now to allow it?

I understand that there might be security concerns with allowing a webapp to draw arbitrary content outside of its own window, but there are definitely situations where I wish I could customize the contents of a <select> better, while still allowing it to break out of the browser window, so I hope it will be allowed in some form.

[lukewarlow]

If you opt-in to the base styling for select then you won't be able to paint outside the frame.

I'd be curious to know what kind of styling you want and why you think you'd still want to paint outside the frame.

[guillaumebrunerie]

The app I am working on currently (internal tool at a company) allows you to replay user sessions (more or less).
It works with two separate windows:

• the main window (typically maximized) containing the replay itself
• a secondary window containing the controls: play/pause and the ability to scrub back and forth, it is typically a rather small window (at least in height), in order not to obscure the main window and because it is mostly used to scrub left and right.

However, the secondary window also has a <select> to be able to choose which user session you want to replay. There can be quite a few to choose from, so when I first had a purely custom HTML/CSS select menu, it was pretty much unusable, as the secondary window is usually way smaller than the list of options, so I had to revert to a native <select> to be able to see the whole list from a small window.

As for the styling, I was trying for instance to change the color of some of the options (to mark in red the user sessions with errors), which isn’t possible. I guess I could use emojis instead as a workaround, but it feels like it should be possible to at least give a different color to an option without giving up features of the native <select>.

In a different app, I have a custom select menu used to choose an easing function between different options. Each easing function has a dynamically generated icon made with a small 2D canvas embedded next to each option:

It is not super crucial for this one to be able to go outside the window, but again it would be nice to have the best of both worlds and not have to choose between customization and all features of the native <select>.

[lukewarlow]

"but it feels like it should be possible to at least give a different color to an option without giving up features of the native " Honouring the color property on an option inside of select with auto appearance is something that could be possible to do (I'm not sure about macOS' select?). Unfortunately we can't really spec that because auto appearance is by definition browser defined. cc @mfreed7 do you happen to know why this isn't already a feature given it requires 0 parser changes? "Each easing function has a dynamically generated icon made with a small 2D canvas embedded next to each option" Images (or canvas in this case) get slightly tricky from a security perspective. With the html parser changes it would at least become possible. Again not sure how much we can do spec wise for appearance: auto. It gets tricky because if you can resize them and get arbitrary rendering outside of your window then that feels like a no go? I suspect in this case your choice will be native select and no image, or stylable select and no frame escaping. Okay github is screwing the formatting here sorry

[mfreed7]

On non-Mac platforms, with Chromium and Gecko browsers (not WebKit), you can already style the options to a fairly large degree. E.g. you can set the color and font properties for the options, and they will be respected. E.g. this is a native <select> in appearance:auto mode, on Chrome for Windows:

As you point out, images are more tricky, due to security issues.

We have been discussing trying to standardize more of the stylability of <select> even in appearance:auto mode (i.e. adding more stylability to Mac/WebKit platforms), but that'll likely need to be a property-by-property effort. @annevk

[annevk]

I would actually rather restrict the amount of things that can be styled for appearance: auto to not make that a web compatibility hazard. Probably best discussed in the various appearance: auto issues in the CSS WG repository.

(The use case here also strikes me as something that needs more thought as adding a bunch of colors won't make it accessible to everyone.)

[guillaumebrunerie]

In any case, I think it would make sense to mention in the explainer that appearance: base-select removes the possibility for the drop-down to go out of the browser window, as it is a pretty significant difference compared to the default behavior.