Findings from the customizable select request for developer feedback form

Adam Argyle

Published: December 16, 2024

In September we asked for your feedback on the experimental customizable select feature. The feedback you shared included use cases (for example, design systems, combo boxes), thoughts on the API's entry mode, and feedback on base styles. Concerns included accessibility, browser compatibility, the need for search functionality, and the desire for multi-select support. It looks like you are eager to use the API in production, but have some reservations and specific feature requests.

All of this information has been used by Chrome engineers and managers to make informed decisions about the feature. This post shares the key takeaways from each of the questions in the customizable select survey.

What would you build with this new API?

There was a variety of use cases shared, in general they included:

  1. Building design system components: create select components for their design systems, ensuring consistency and customizability across their projects.
  2. Creating various types of selectors: things like language selectors, country selectors, user permission selectors, and more.
  3. Enhancing existing select elements: enhance existing select elements with features like images, SVGs, and richer styling.
  4. Replacing custom select implementations: replace custom-built select components with a standardized, native solution.
  5. Building combo boxes and custom pickers: more complex features like combo boxes, custom pickers for phone numbers, time zones, currencies, and other data types.
  6. Improving form UIs: improve forms by creating more visually appealing and functional select elements.

These responses highlight the versatility of the new API and its potential to improve the user experience and development efficiency for a wide range of web applications.

Do you plan to use this API in production once it reaches Baseline widely available?

95% of you said "yes."

Have you tried the new API? If so, were you able to build what you wanted with it?

30% of you said "yes."

What are your thoughts on the entry mode for customizable select (appearance: base-select on the <select> element and ::picker(select))

Feedback on this entry mode is mixed:

  1. Some find the approach acceptable, reasonable, or even better than the current situation. They see it as a "logical" or "fine" way to progressively enhance the <select> element.
  2. Others express confusion or find the syntax awkward. The use of two properties (appearance: base-select and ::picker(select)) is seen as redundant or unnecessary. Concerns are raised about the naming (base-select might be misleading) and potential confusion for newcomers unfamiliar with the underlying concepts.
  3. A few respondents suggest alternative approaches, such as using a single property or selector, or avoiding the appearance property altogether.

Overall, while some respondents are comfortable with the current entry mode, others find it confusing or suggest improvements for clarity and simplicity. This feedback highlights the importance of clear documentation and examples to guide developers in using the new API effectively.

Do you have any feedback on the existing base (user agent) styles for customizable select?

Some respondents find the styles acceptable or good, while others have specific criticisms or suggestions. Some of the feedback points include:

  • The checkmark icon is not pretty or could be simpler.
  • There is not enough space for a checkmark next to items.
  • The base styles look cramped, with the focus ring cut off and no gap between the checked icon and text.
  • The styles could be closer to the OS platform style or a <dialog> element.
  • The default arrow should point down and flip to the top when open.
  • A reset may be needed to remove base user-agent styles.

Do you have any questions, comments, or concerns about this feature?

There was a variety of feedback, questions, and concerns about the new customizable select API. Some of the key themes include:

  1. Accessibility: Several respondents raised concerns about accessibility, particularly with screen readers and keyboard navigation.
  2. Multi-select and combo boxes: There's a strong desire for multi-select functionality and combo box support.
  3. Search functionality: The ability to search within the select options is a requested feature.
  4. Styling and browser compatibility: Concerns were raised about styling options, browser compatibility, and the need for CSS resets.
  5. Implementation details: Questions were asked about specific implementation details like focus lock, rendering behavior, and custom children.
  6. General feedback: Some respondents shared general feedback, such as the desire for a simpler API entry mode and the ability to render outside the browser chrome.

Overall, the feedback highlights the need for improved accessibility, additional features like multi-select and search, and clear guidance on styling and browser compatibility.

Is there any other feedback you would like to add?

Key themes from the thoughts and suggestions of respondents include:

  1. Desire for multi-select and combo box functionality: Multiple respondents specifically request the addition of multi-select and combo box capabilities.
  2. Importance of accessibility: Some respondents emphasize the need for continued focus on accessibility features.
  3. Positive feedback and feature requests: Some express excitement about the API and offer suggestions like a search option or the ability to detect support using @supports.
  4. Specific use cases: A few respondents mention specific use cases they'd like to see supported, such as rendering outside the browser chrome or allowing custom values within the <select> element.
  5. General comments: Some offer general praise or express the desire for consistent appearance across browsers.

Overall, this feedback reinforces the demand for multi-select and combo box features, highlights the importance of accessibility, and provides additional insights into potential use cases and areas for improvement.

We thank everyone again, and hope this community feedback summary finds implementers and developers well, aiding in a better customizable select experience for users and developers alike.