> What's the status of the spec PR? I just updated the commit message and pinged a reviewer.
> Do you know if this works as expected with screen readers? I imagine the pop up style rendering works since that's currently a common experience, but not sure what would happen in an in-page rendering on mobile? Thanks for bringing this up. I tested out the in-page listbox rendering on android voiceover, and I found that the single-select worked fine but there is something wrong with the multi-select mode. I am looking into it now. On Wed, Sep 10, 2025 at 8:15 AM Vladimir Levin <[email protected]> wrote: > Do you know if this works as expected with screen readers? I imagine the > pop up style rendering works since that's currently a common experience, > but not sure what would happen in an in-page rendering on mobile? > > Thanks, > Vlad > > On Thursday, September 4, 2025 at 9:55:18 PM UTC-4 Kent Tamura wrote: > >> LGTM1. The consistent behavior is reasonable, and the compatibility risk >> looks very small. >> >> >> On Fri, Sep 5, 2025 at 2:42 AM Joey Arhar <[email protected]> wrote: >> >>> Contact [email protected] >>> >>> Explainer >>> https://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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwLEPi_ObWz9KhGJwsH2088%2BrDVJfUDFSin2SUBwNNkznw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> TAMURA Kent >> Software Engineer, Google >> >> >> -- 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/CAK6btwK-e0ZZWLtGUY4XYMThGZ%3DGDQb4s1py0esOjKiLCO6u8A%40mail.gmail.com.
