Post by Chris on Nov 16, 2024 7:32:48 GMT -8
Background<svg viewBox="0 0 16 16" height="24" version="1.1" width="24"
The <select> element does not provide enough customization for web developers, which leads them to implement their own. These implementations can lead to reduced performance, reliability, and accessibility compared to the native form control elements. More on that is in Custom Control UI.
The 2020 MDN browser compatibility report had feedback that form controls are neither interoperable nor customizable. Customizable <select> will be fully interoperable and customizable.
Opting in to the new behavior<svg viewBox="0 0 16 16" height="24" version="1.1" width="24"
The <select> element will continue to behave as it currently does unless it has the appearance:base-select CSS property. Based on standardization discussions, appearance:base-select must also be applied to the select::picker(select) pseudo-element in order to opt in the picker popup element. Previously proposed opt-ins included a new tag name, an additional HTML attribute, and the presence of a child <button> or <datalist>.
Here is a basic <select> element with the appropriate CSS to opt in to customizable <select>
Testing out the customizable select element<swidth="24" xlmns="http://www.w3.org/2000/svg"><path d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2
Customizable <select> is currently implemented behind a flag in Chromium. To use it, enable the Experimental Web Platform features flag in about:flags. Using chrome canary is recommended to get the latest state of the API.
If you encounter bugs or limitations with the design of the control, please send your feedback by creating issues on the open-ui GitHub repository. Here is a list of open select bugs in open-ui.
Read More...
There may apparently be a bug where Chrome Mobile on Android automatically opts in for page author (Mobile Issue)
