LGTM2 Also supportive of not entertaining expensive and potentially risky breaking changes only for the purpose of "bikeshedding", while also not blocking indefinitely (2.5 months in this case <https://github.com/WebKit/standards-positions/issues/559>) waiting for standards positions from other implementers.
Rick On Wed, Dec 17, 2025 at 11:36 AM Alex Russell <[email protected]> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e774d643-8731-4f04-b092-be53b537ffefn%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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/CAFUtAY97MnWE2%3DB32qYLM7%2BTHzWYtddPh09eWnovq%3D_xp%3DKd_Q%40mail.gmail.com.
