Interoperability and Compatibility
The interop risk of this feature is low due to the merged spec, positive standards position from mozilla, and sufficient quantity of discussions and resolutions in WHATWG and CSSWG. This feature also builds a relatively small amount of code on top of the previous customizable select popup feature, which already has positive standards reviews from both apple and mozilla.
Gecko: Positive (
https://github.com/mozilla/standards-positions/issues/1304)
WebKit: No signal (
https://github.com/WebKit/standards-positions/issues/559)
Web developers: No signals
Other signals:
Ergonomics
I expect that this feature will be used in tandem with other new features we have recently been adding to HTML, including popovers and command invokers. The default usage of this API will not make it hard for chrome to maintain good performance.
Activation
I'm not sure if this feature would benefit from polyfills due to the HTML parser changes required in order to use customizable select (listbox or popup). In a non-supporting browser, the "rich" HTML needed to render interesting things in a select element is deleted by the parser, so a polyfill would either have to build all of the DOM contents via script or use an alternative HTML structure which would be transformed into either a select element or a custom element which looks like a customizable select.
Security
I don't believe this feature poses any security risks. It is an improved rendering of the existing select element's listbox rendering.
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
This feature has an opt in for new behavior, so there should not be any WebView risks.