Intent to Prototype: Customizable <select> Element

Skip to first unread message

Daniel Clark

Aug 26, 2020, 7:11:35 PM8/26/20

Contact emails


Note: The explainer document describes a process for implementing customizability in all form controls, but at this stage the plan is to scope prototyping to only the <select> element.


TAG review

No Review Yet


This feature introduces a customizable select HTMLElement, with the working name of <selectmenu>. The element will offer authors full control over its appearance without requiring them to rewrite the model and controller logic underpinning its function.


A common frustration for developers who try to work with the browser's built-in form controls, particularly <select>, is that they cannot customize the appearance of these controls to fit their site's design or user experience. Since the browser platform has limited ability for customization of <select>, developers often end up rolling their own implementations. When developers reimplement form controls from scratch, they're not able to leverage the work done on the Web Platform to optimize performance, reliability, and accessibility of the native controls. Providing a fully customizable <select> allows web developers to change it fit their site while leaning on investments in the web platform, saving time for developers and improving experience of the end users who interact with the controls.


Interoperability and Compatibility

It is a goal that all major browsers implement this feature once standardized. It should, however, be polyfillable in the event that support is not universal.

Gecko: No signal

WebKit: No signal

Web developers: Positive


Clear documentation will be required to help developers understand the parts and slot positions of the customizable select, and explain how the platform controller code will interact with these parts. This information will all be available at, but we should ensure that it is available in an easily digestible format. The feature will be polyfillable, and polyfills like likely be useful for handling gradual rollout of implementations.


Some built-in controls have privileged behavior that could be dangerous if opened up to third-party code. A <select>'s built-in dropdown's listbox can expand outside the containing browser window and outside of <iframe>s. Allowing arbitrary content in a <select> that can escape its window bounds could open up possibilities for spoofing OS UI outside of the browser frame, or spoofing content of an outer site from within an <iframe>. Therefore, the customizable <select> will likely not have the capability to exceed window bounds, and we'll need to be mindful of any other areas where author content could take advantage of capabilities formerly only available to web platform internals.


No special debugging support planned. It may turn out to be useful to expose debug information about the native controller code and how it is being hooked up to author-provided parts, but experimentation is necessary to require whether this will be useful in practice, and if so, what exactly should be exposed.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?


Is this feature fully tested by web-platform-tests?


Link to entry on the Chrome Platform Status

This intent message was generated by Chrome Platform Status.


Dan Clark

Aug 27, 2020, 11:37:08 AM8/27/20
to blink-dev, Daniel Clark
One correction: the Open-UI link should be this one: 
Reply all
Reply to author
0 new messages