Intent to Prototype: Customizable <select> Element

1070 views
Skip to first unread message

Daniel Clark

unread,
Aug 26, 2020, 7:11:35 PM8/26/20
to blin...@chromium.org

Contact emails

dan...@microsoft.commeri...@microsoft.comiopo...@microsoft.compc...@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.

 

Dan Clark

unread,
Aug 27, 2020, 11:37:08 AM8/27/20
to blink-dev, Daniel Clark
One correction: the Open-UI link should be this one: https://open-ui.org/components/select 
Reply all
Reply to author
Forward
0 new messages