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::beforeoption: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.
I solved the select issue years ago: https://github.com/pigfox/unselect2/tree/d2fc5fa979cef444f85f5d8fc62cccbc57693ac6
It’s just that HTML never decided to implement it, eh?
Bummer. One of the things I was looking forward to with the proposed element was the possibility that it might support the
langattribute. I work on a language learning platform and native select does not supportlang, so anyoptions not in the language of the page get mangled by screen readers.Oh, interesting! I wonder if that, too, can be solved on the HTML Working Group side just as styling is being solved on the CSS Working Group side.
Maybe I’m not understanding the problem properly, or I’m missing something. Knowing myself, this is a possibility that is not unlikely. ;-)
I had however a quick look at the specs and both,
selectandoption, seem to support the global attributes, including thelangattribute. Could it instead be missing support on the client side, causing this to fail for you?Worth to mention that this replaces the native picker on mobile devices too.