The Chrome team is working towards enabling customization of the <select> element using the new <selectmenu> element. This upcoming feature allows developers to replace the browser's default dropdown styling with custom HTML, offering greater flexibility and control over the appearance and functionality of dropdown menus. Developers will be able to integrate richer interactions, accessibility features, and more complex layouts within the select element, all while preserving the semantic meaning and native behavior like keyboard navigation and screen reader compatibility. This enhancement aims to address the longstanding developer pain point of limited styling options for the <select> element, opening up opportunities for more visually appealing and user-friendly form controls.
The Chromium Developers blog post, "RFC: Customizable
The core of the proposal revolves around "selectmenu," a proposed new HTML element. This new element will allow developers to define a customizable template for the dropdown portion of a <select> element. Within this template, developers will have the freedom to use standard HTML, CSS, and JavaScript to craft the precise layout, styling, and interactive behavior of the options presented to the user. This means developers can incorporate elements like images, checkboxes, complex layouts, and even custom search functionalities directly within the dropdown.
Furthermore, the proposal addresses keyboard navigation and accessibility concerns, ensuring that custom selectmenus remain usable and navigable via keyboard input, aligning with accessibility best practices. It emphasizes that while the visual presentation can be highly customized, the underlying functionality and accessibility features of the native <select> element should be preserved.
This change is expected to simplify the development process for creating rich and interactive select menus. Developers will no longer need to rely on complex JavaScript solutions, leading to more maintainable and performant code. The standardization offered by this proposal also promises improved cross-browser compatibility and consistency for customized select elements. The blog post encourages community feedback and participation in the standardization process to refine and solidify the proposal's details before its eventual implementation.
Hacker News users generally expressed frustration with the <select> element's historical limitations and welcomed the proposed changes for customization. Several commenters pointed out the difficulties in styling <select> cross-browser, leading to reliance on JavaScript workarounds and libraries like Choices.js. Some expressed skepticism about the proposed solution's complexity and potential performance impact, suggesting simpler alternatives like allowing shadow DOM styling. Others questioned the need for such extensive customization, arguing for consistency and accessibility over visual flair. A few users highlighted specific use cases, such as multi-select with custom item rendering, where the proposed changes would be beneficial. Overall, the sentiment leans towards cautious optimism, acknowledging the potential improvements while remaining wary of potential drawbacks.
The Hacker News post "Customizable HTML Select" discussing the Chrome developer blog post about customizable <select> elements has a moderate number of comments, exploring different facets of the proposed changes.
Several commenters express cautious optimism about the potential for improved user experience. They highlight the long-standing difficulty in styling the <select> element and acknowledge that the proposed changes could offer more control and flexibility. However, they also emphasize the importance of careful implementation to avoid creating new accessibility issues or inconsistencies across different browsers. One commenter specifically points out the need for proper keyboard navigation and screen reader compatibility, urging developers to prioritize accessibility during the design and implementation phases.
Another recurring theme is the complexity of the current workaround solutions. Commenters share anecdotes of struggling with JavaScript libraries and custom CSS to achieve the desired look and feel for <select> elements. They express hope that the native customization options will simplify the development process and reduce the reliance on external dependencies. Some commenters also discuss the performance implications of heavy JavaScript solutions, suggesting that native browser support could lead to more performant web pages.
A few commenters raise concerns about potential downsides. One points out that the new features might introduce browser compatibility issues if not implemented consistently across different browsers. Another commenter expresses skepticism about the value of extensive customization, arguing that the standard <select> element is sufficient for most use cases and that excessive styling can lead to usability problems. There is also a brief discussion about the potential for abuse, with one commenter suggesting that customizable <select> elements could be used for deceptive practices, such as disguising ads as dropdown menus.
Finally, some commenters share their own experiences and preferences regarding <select> element styling. One commenter mentions using a specific CSS framework for styling dropdowns, while another suggests that the proposed changes might finally allow them to achieve a particular design they've been struggling with. These personal anecdotes provide concrete examples of the challenges developers face and their hopes for the future of <select> element customization. The overall sentiment seems to be one of cautious hope, with commenters acknowledging the potential benefits while also stressing the importance of careful consideration for accessibility and cross-browser compatibility.
Summary of Comments ( 120 )
https://news.ycombinator.com/item?id=43113790
Hacker News users generally expressed frustration with the
<select>element's historical limitations and welcomed the proposed changes for customization. Several commenters pointed out the difficulties in styling<select>cross-browser, leading to reliance on JavaScript workarounds and libraries like Choices.js. Some expressed skepticism about the proposed solution's complexity and potential performance impact, suggesting simpler alternatives like allowing shadow DOM styling. Others questioned the need for such extensive customization, arguing for consistency and accessibility over visual flair. A few users highlighted specific use cases, such as multi-select with custom item rendering, where the proposed changes would be beneficial. Overall, the sentiment leans towards cautious optimism, acknowledging the potential improvements while remaining wary of potential drawbacks.The Hacker News post "Customizable HTML Select" discussing the Chrome developer blog post about customizable
<select>elements has a moderate number of comments, exploring different facets of the proposed changes.Several commenters express cautious optimism about the potential for improved user experience. They highlight the long-standing difficulty in styling the
<select>element and acknowledge that the proposed changes could offer more control and flexibility. However, they also emphasize the importance of careful implementation to avoid creating new accessibility issues or inconsistencies across different browsers. One commenter specifically points out the need for proper keyboard navigation and screen reader compatibility, urging developers to prioritize accessibility during the design and implementation phases.Another recurring theme is the complexity of the current workaround solutions. Commenters share anecdotes of struggling with JavaScript libraries and custom CSS to achieve the desired look and feel for
<select>elements. They express hope that the native customization options will simplify the development process and reduce the reliance on external dependencies. Some commenters also discuss the performance implications of heavy JavaScript solutions, suggesting that native browser support could lead to more performant web pages.A few commenters raise concerns about potential downsides. One points out that the new features might introduce browser compatibility issues if not implemented consistently across different browsers. Another commenter expresses skepticism about the value of extensive customization, arguing that the standard
<select>element is sufficient for most use cases and that excessive styling can lead to usability problems. There is also a brief discussion about the potential for abuse, with one commenter suggesting that customizable<select>elements could be used for deceptive practices, such as disguising ads as dropdown menus.Finally, some commenters share their own experiences and preferences regarding
<select>element styling. One commenter mentions using a specific CSS framework for styling dropdowns, while another suggests that the proposed changes might finally allow them to achieve a particular design they've been struggling with. These personal anecdotes provide concrete examples of the challenges developers face and their hopes for the future of<select>element customization. The overall sentiment seems to be one of cautious hope, with commenters acknowledging the potential benefits while also stressing the importance of careful consideration for accessibility and cross-browser compatibility.