Intent to Ship: Customizable select listbox

[Joey Arhar]

Contact emails

jar...@chromium.org

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

Web Feature ID

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, 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

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?

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.

[Thomas Steiner]

I'm pretty sure @Una Kravets and @Bramus Van Damme can get you some citable sources for the Web developers signal. I'd say: Web developers are suuuuper enthusiastic about this. 

 

--
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/CAK6btwJMwhX9T%3DC6h9jVihkFXE28X4vW8ALU-1Lfvr4fquJA2A%40mail.gmail.com.

--

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

[Alex Russell]

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

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwJMwhX9T%3DC6h9jVihkFXE28X4vW8ALU-1Lfvr4fquJA2A%40mail.gmail.com.

[Rick Byers]

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) waiting for standards positions from other implementers. 

Rick

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/CAK6btwJMwhX9T%3DC6h9jVihkFXE28X4vW8ALU-1Lfvr4fquJA2A%40mail.gmail.com.

--

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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e774d643-8731-4f04-b092-be53b537ffefn%40chromium.org.

[Bramus Van Damme]

I don’t immediately have something to link to here, unfortunately. But yes, I’ve heard this request from developers directly while at conferences, together with the need to filter the customizable select (which is a separate feature).

[Chris Harrelson]

LGTM3

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e398be71-596a-469d-8990-6c50cc8dc1fcn%40chromium.org.