Intent to Prototype: Customizable <select> Element
Daniel Clark
Contact emails
dan...@microsoft.com, meri...@microsoft.com, iopo...@microsoft.com, pc...@microsoft.com
Explainer
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ControlUICustomization/explainer.md
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.
Specification
https://open-ui.org/components/select.research
TAG review
No Review Yet
Summary
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.
Motivation
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.
Risks
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
Activation
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.
Security
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.
Debuggability
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)?
Yes
Is this feature fully tested by web-platform-tests?
No
Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/5737365999976448
This intent message was generated by Chrome Platform Status.