LGTM1, but want to reiterate something here (as discussed in this morning's API OWNERs discussion): when we ship stuff, web developers need to be able to depend on it. The concrete is poured.
Given the lack of signals from WebKit and the risk we're taking by shipping first, we need to understand what's happening here as a commitment to not making breaking changes post-ship without a full deprecation and removal process, which is already discouraged in the case of new features. There has been a disturbing pattern of entertaining post-ship bikeshedding, and I2S LGTMs always come with this implicit requirement that we not do that. In this area, I want to make that extremely explicit. If there's reason to worry about bikeshedding or a lack of developer validation for the shape of this API, we can always I2E to strengthen the case instead. Best, Alex On Wednesday, December 17, 2025 at 3:32:10 AM UTC-8 [email protected] wrote: > On Tue, Dec 16, 2025 at 11:07 PM Joey Arhar <[email protected]> wrote: > >> *Contact emails* >> [email protected] >> >> *Explainer* >> https://github.com/whatwg/html/issues/11477 >> >> *Specification* >> https://github.com/whatwg/html/pull/11758 >> >> *Summary* >> This feature extends customizable select support to the listbox rendering >> mode, including single-select and multi-select in listbox mode. The listbox >> rendering mode means that the select element is rendered in-flow or in the >> page rather than with a separate button and popup. Listbox rendering mode >> is opted into across platforms via the multiple or size attributes, like >> <select multiple> or <select size=4>. When the appearance:base-select CSS >> property is applied to the select element with these attributes, it will >> now have improved rendering and input behavior. This feature does not >> support customizable select for the multi-select popup, which will come >> later. The following attributes must be set in order to get a multi-select >> popup: <select multiple size=1>. >> >> *Blink component* >> Blink>DOM >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EDOM%22> >> >> *Web Feature ID* >> customizable-select <https://webstatus.dev/features/customizable-select> >> >> *Motivation* >> The previous iteration of customizable select, which has a picker popover >> built into it, had a restricted set of use cases because of the content >> model restrictions on what can be put inside of its picker. By adding a >> customizable listbox which is just the listbox without the picker, more >> complex patterns where the developer provides their own picker are enabled. >> This enables, for example, the labels picker on github which has a >> filtering text input before the listbox and a "edit labels" button after >> the listbox. Various component libraries on the web also include a >> "listbox" component which behaves like this. Multi-select is also a common >> feature for listboxes on the web which this feature supports. >> >> *Initial public proposal* >> https://github.com/whatwg/html/issues/11477 >> >> *TAG review* >> *No information provided* >> Customizable select with a popup already had a TAG review here >> <https://github.com/w3ctag/design-reviews/issues/1007>, and the spec for >> customizable select listbox has already been merged, so I don't think a TAG >> review is needed. >> >> *TAG review status* >> Not applicable >> >> *Risks* >> >> >> *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 >> > > I'm pretty sure @Una Kravets <[email protected]> and @Bramus Van Damme > <[email protected]> can get you some citable sources for the Web > developers signal. I'd say: Web developers are suuuuper enthusiastic about > this. > > >> >> *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. >> >> >> *Debuggability* >> This feature has the same debuggability as customizable select, which >> includes DevTools issues for non-conforming content inside the select >> element and strikethroughs in -internal-auto-base(). >> >> *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>?* >> Yes >> >> https://wpt.fyi/results/html/semantics/forms/the-select-element/customizable-select-in-page/customizable-select-listbox >> >> *Flag name on about://flags* >> *No information provided* >> >> *Finch feature name* >> CustomizableSelectListbox >> >> *Rollout plan* >> Will ship enabled for all users >> >> *Requires code in //chrome?* >> False >> >> *Tracking bug* >> https://issues.chromium.org/issues/357649033 >> >> *Availability expectation* >> Once other browsers implement customizable select, which will hopefully >> be sometime soon, they can implement this feature easily on top or >> implement both rendering modes at the same time. >> >> *Adoption expectation* >> Once this feature is baseline, I expect that it will have significant >> usage across the web because listboxes are very common in websites and >> frameworks. >> >> *Adoption plan* >> Continue to respond to feedback on the spec from other implementors while >> they are implementing, which has already begun for customizable select. >> >> *Non-OSS dependencies* >> >> Does the feature depend on any code or APIs outside the Chromium open >> source repository and its open-source dependencies to function? >> None >> >> *Estimated milestones* >> Shipping on desktop 145 >> Shipping on Android 145 >> Shipping on WebView 145 >> >> *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). >> There are no open spec questions about this feature. >> >> *Link to entry on the Chrome Platform Status* >> https://chromestatus.com/feature/6222145025867776?gate=5168552637890560 >> >> *Links to previous Intent discussions* >> Intent to Prototype: >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKbJ%3D2cm4D3gtkKevMoMVwJT7PYJPCp2EyNKu%3D8pW1FKQ%40mail.gmail.com >> >> >> 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/CAK6btwJMwhX9T%3DC6h9jVihkFXE28X4vW8ALU-1Lfvr4fquJA2A%40mail.gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwJMwhX9T%3DC6h9jVihkFXE28X4vW8ALU-1Lfvr4fquJA2A%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > Thomas Steiner, PhD—Developer Relations Engineer (blog.tomayac.com, > toot.cafe/@tomayac) > > Google Spain, S.L.U. > Torre Picasso, Pl. Pablo Ruiz Picasso, 1, Tetuán, 28020 Madrid, Spain > > CIF: B63272603 > Inscrita en el Registro Mercantil de Madrid, sección 8, Hoja M-435397 > Tomo 24227 Folio 25 > > ----- BEGIN PGP SIGNATURE ----- > Version: GnuPG v2.4.8 (GNU/Linux) > > iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck > 0fjumBl3DCharaCTersAttH3b0ttom.xKcd.cOm/1181. > ----- END PGP SIGNATURE ----- > -- 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/e774d643-8731-4f04-b092-be53b537ffefn%40chromium.org.
