dan...@microsoft.com, meri...@microsoft.com, iopo...@microsoft.com, pc...@microsoft.com
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
No Review Yet
This feature introduces a customizable select HTMLElement, with the working name of
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
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
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 https://open-ui.org/, 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
built-in dropdown's listbox can expand outside the containing browser window and outside of
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
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.