Intent to Ship: Mobile and desktop parity for select element rendering modes

[Joey Arhar]

Contact emails

jar...@chromium.org

Explainer

https://github.com/whatwg/html/issues/8189#issuecomment-2877242732

Specification

https://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.

Blink component

Blink>Forms>Select

TAG review

None

TAG review status

Not 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?

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://flags

None

Finch feature name

SelectMobileDesktopParity

Rollout plan

(RARE) Experiment users ramp up over time

Requires code in //chrome?

False

Tracking bug

https://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.

[PhistucK]

Sounds nice. Any plans to add a built-in search/type-to-filter field into the rendered widget (either popup or in-page) when there are more than one "page"/scroll of options?

☆PhistucK

--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwLEPi_ObWz9KhGJwsH2088%2BrDVJfUDFSin2SUBwNNkznw%40mail.gmail.com.

[Joey Arhar]

> Any plans to add a built-in search/type-to-filter field into the rendered widget (either popup or in-page) when there are more than one "page"/scroll of options?

I've been discussing this capability here: https://github.com/openui/open-ui/issues/847

[TAMURA, Kent]

LGTM1.  The consistent behavior is reasonable, and the compatibility risk looks very small.

--

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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwLEPi_ObWz9KhGJwsH2088%2BrDVJfUDFSin2SUBwNNkznw%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google