Contact [email protected] Explainerhttps://github.com/whatwg/html/issues/8189#issuecomment-2877242732
Specificationhttps://github.com/whatwg/html/pull/11460 Summary By using the size and multiple attributes, the select element can be rendered as an in-page listbox or a button with a popup. However, these modes are not consistently available across mobile and desktop chrome. Currently, in-page listbox rendering is not available on mobile, and button with popup is not available on desktop when the multiple attribute is present. This feature adds the listbox to mobile and adds a multi-select popup to desktop, and makes the opt-ins with the size and multiple attributes result in the same rendering mode across mobile and desktop. Here is a summary of the changes: - When the size attribute has a value greater than 1, in-page rendering will always be used. Previously, this was ignored on mobile and always resulted in a popup. - When the multiple attribute is set with no size attribute, in-page rendering will be used. Previously, this was a popup instead of an in-page listbox on mobile. - When the multiple attribute is set with size=1, a popup will be used. Previously, this was an in-page listbox on desktop. By making this change, we are providing a foundation to bring customizable select to in-page rendering and multi-select. Customizable select currently only works for single-selects with a popup. Here is a screenshot of the new multi-select popup for desktop, which you'll get with <select multiple size=1>. This was created to reach parity with the previously existing multi-select popup on android. [image: 479732188-e42f4512-1059-4bae-85ed-00e2dee2a967.png] Blink componentBlink>Forms>Select <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EForms%3ESelect%22> TAG reviewNone TAG review statusNot applicable Risks Interoperability and Compatibility Interop risk is low because of the positive standards position from Mozilla and the lack of blocking feedback from Apple in many standards discussions. There is a compat risk of breaking existing usage of select multiple on mobile which currently always uses a picker but will be changed to use the in-page listbox to match desktop. If there are any mobile sites relying on this particular rendering mode, they will have to add the size=1 attribute to their select element. I added a UseCounter to see how often users open a select multiple picker on mobile, and the usage is quite low: https://chromestatus.com/metrics/feature/timeline/popularity/5549 *Gecko*: Positive ( https://github.com/mozilla/standards-positions/issues/1274) *WebKit*: No signal ( https://github.com/WebKit/standards-positions/issues/532) *Web developers*: No signals *Other signals*: Ergonomics I expect the in-page rendering mode to be used in tandem with customizable select in the future when customizable select is expanded to include the in-page listbox rendering mode. The default usage of this API will not make it hard for chrome to maintain good performance. Activation It will not be challenging for developers to take advantage of this feature immediately. Security I don't believe there are any security risks for this feature. 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? None Debuggability DevTools shows the attributes on the select element in the elements panel, but doesn't explain the logic for how the size and multiple attributes result in the different rendering modes. I expect this to be documented on MDN so developers can learn how to control this. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?Yes Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?No There is not a good way to test the native appearance of the select element, and there is no way to test whether the select element is in a mode which supports a picker or not. Flag name on about://flagsNone Finch feature nameSelectMobileDesktopParity Rollout plan(RARE) Experiment users ramp up over time Requires code in //chrome?False Tracking bughttps://issues.chromium.org/issues/439964654 Estimated milestones Finch in 141, enable by default in 142 Anticipated spec changes Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way). None Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5412736871825408?gate=6327273552740352 This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwLEPi_ObWz9KhGJwsH2088%2BrDVJfUDFSin2SUBwNNkznw%40mail.gmail.com.
