I was looking over an older article Patrick Brosset penned for us introducing <selectmenu>, a new proposal at the time for a more style-able cousin to <select>. From there, I clicked the linked-up <selectmenu> explainer and got… this:
OK, link rot is a thing and happens all the time. Perhaps the site needs a little URL designing? But no, it’s not that at all. I searched a bit and found Jared White’s post saying that <selectmenu> is no more, which came by way of Una’s post over at the Chrome Developer Blog seeking feedback on a “customizable select”. And Adam Argyle’s got a wonderful demo dedicated to it, no surprise there.
I’m only sharing the links for now but plan to spend some time with it and jot down notes on Open UI’s new page for the Customizable <select>. I enjoyed looking at the boilerplate from Adam’s demo as a first glance:
select {
&, &::picker(select) {
appearance: base-select;
}
&::picker(select) {
transition:
display allow-discrete 1s,
opacity 1s,
overlay 1s allow-discrete
;
}
&:not(:open)::picker(select) {
opacity: 0;
}
&:open::picker(select) {
opacity: 1;
@starting-style {
opacity: 0;
}
}
}
I see the ::picker(select) there that’s driving all of it. If I sneak a peek at Una’s post, I see that there are more ways to select different <select> parts, including:
<selectedoption> (the current selection)
<option> (which now accepts HTML in between the tags!)
option::before
option:checked (a little confusion here with the selected option)
<button> (the little chevron arrow marker thingy)
So, perhaps Chrome is more of a fan of extending the native <select> with additional CSS features for selecting the existing parts rather than moving forward with a completely new element. That’s cool, as one of Una’s demos shows how we still get the default <select> behavior even if a browser does not support the new selectors.
The selectmenu Element is No More…Long Live select! originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.
