I just tried it in the Codepen and it reverts to a regular old UI element when it has the multiple attribute.
Also just tried it with multiple="multiple" just in case. Same behavior.
Huge miss in my opinion. If it doesn’t support all scenarios I’m not sure what the Chrome team is thinking here
I expect they're thinking they should ship something that works, and covers some use cases, and gradually improve it over time to support more use cases.
Y'know, like how most software development works.
They've screwed this up several times by shipping too soon and then having to backpedal. The web is not something you want to screw up because they don't own every website in existence.
I was just wondering how people do a custom <select multiple> now. I guess they make it screen-reader-only and then have aria-hidden checkboxes for everyone else.
"Select multiple" is just a list of checkboxes. The missing part (which is also missing from select) is just the filtering.
I am not holding my breath for a decent "select multiple" field. It's been the same crap for decades and browsers could have fixed it long again without waiting for spec - it's just a "replaced element", but they don't care.
The fun part is that it looks amazing on Safari iOS (and QED it's rendered as a list of checkboxes)
I commented on this a few weeks ago. There are two future components under development that look to support selecting multiple options in a dropdown format.
Search textbox: would be supported under the more customizable Combobox element
Select Multiple: both the Enhanced Select and Combobox plan to support this
Combobox: https://open-ui.org/components/combobox.explainer/
Enhanced Select: https://open-ui.org/components/customizableselect/
> "Select multiple" is just a list of checkboxes.
Not necessarily. I've seen more than one production app with a custom filtering dropdown list of items with checkboxes.
I built a couple variants of that in React at my last gig for the company's design system. The keyboard nav was complex... that component is one of the work artifacts that I'm most proud of.
> custom filtering dropdown
I already said that. "Select" is not filterable in the browser already, so `select[multiple]` has no chance of seeing that in this decade.
However you slice/style it, it's just checkboxes (that you can filter/reorder)
Incremental improvement?
Why release anything right?
Incremental improvement is great, but I do want to know what they're thinking here.
They didn't mention it in the blog post that multiple isn't supported. Its perfectly fine if it is not supported right now. It would be great if they acknowledged that up front to set expectations accordingly.
For instance, if its explicitly not supported, then I won't be left wondering if its a bug or a misunderstanding of the implementation etc.
Communication would be really good here. I'm all for incremental improvement, I think we need more of it.
Doesn't mean there shouldn't be better communication about it.
In the original dev blog from last year they mention it’s still a work in progress.
https://developer.chrome.com/blog/rfc-customizable-select
> Note: The multiple and size attributes on select (<select multiple> and <select size=n>) are not supported in appearance: base-select yet.
From last year while it was a WIP
and now this as of Chrome 135 is shipped, and they didn't think it wise to include a back reference to this post, calling out what isn't supported?
They can and should communicate this is all.
Agreed. Should have mentioned it in this post or at least linked back to my source.