<selectmenu> — The game changer
Last year I was at the Frontend Conf in Zurich. Well okay, I attended online but still had a great time. While browsing through all the fantastic talks and learning a lot, I stumbled upon a topic that has bothered me ever since I started being a frontend developer back in 2011 (phew, that’s already a really long time ago).
The great Stephanie Stimac held a talk about the <select>-element. She explained how it started and what kind of annoying issues we developers have while using it.
In this article, I will give you a quick overview of the history, the problems, and the — hopefully soon to be fully integrated — game changer, the <selectmenu>.
The journey of <select>
So, it all started in 1993, when Tim Berners-Lee (great guy!) invented HTML. Okay, maybe this reaches too far back in history. Let’s skip ahead and jump into 1995.
That year, the standardization of form functionality across browsers was introduced. All great so far. But at this time, there was nothing like CSS and styling was still nice to have. Nobody thought about how to make all the form elements easy to use and nice to look at.
When CSS finally was a thing (in 1997 CSS got officially supported by HTML — woo-hoo!), it was already too late and the selectmenu was so far spread that there was no way to make this accessible, nice looking, and easy to use at the same time. Also, a huge problem is that every browser displays this wonderful piece of art (sarcasm off) differently.
After a while, the people behind the different browsers found that it would be a good thing to provide the possibility to style these elements and invented the “appearance property”. The downside of this invention was that only system-controlled styles could be changed, and every browser worked with them differently. That led to another issue — the vendor prefixes — which are different for every browser and not even supported by every browser. Yes, Internet Explorer, I am looking at you!
Since all of these “solutions” are rather suboptimal, the only option is to write your own selectmenu or to use a library. This usually turns out to be a big waste of time and resources. So what now? As I already said, the <select>-menu, as we know it, is so far spread that it would lead to a big problem if it was changed. Every place that it is used would need to be reworked. And we know that almost every website is using a <form> and the <select>-element. Good luck with that!
And now — the big bang!
The Open UI Community Group, a group that was founded to make the web developer’s life easier, is working on a new solution for this problem. The name gives it away — it is a group that everybody can be part of and is mostly driven by browser vendors, framework authors, and design system maintainers. So, if you also want to make the developer’s world a better place, have a look at it and feel free to join (no, I am not paid by them).
Their goal is to document, analyze and define standards of form controls, states, and behavior. And as already mentioned, they try to find a better solution for the selectmenu and invented a new element. They want to make sure that they don’t overwrite the already existing element, which gives us much more possibilities.
First of all, please make sure to have the “Experimental Web Platform Features” in Chrome enabled. So far, this wonderful feature is not ready to use, only ready to test. Whenever you have it enabled, the fun can start.
The structure of the <selectmenu>
Let’s have a closer look at the element:
As you can see, we have an outer element, the <select>, which is the root element and separates the <selectmenu> into two parts. It contains the <button> and the <listbox>.
The <button> is the clickable element that triggers the visibility of the <listbox>. The <selected-value>, which doesn’t need to be nested inside the <button> — and is anyhow optional — displays the selected option.
Like every <select>-element we know, we have an icon or better an indicator that shows that there are more options to be shown. This is done with the <marker>.
The <listbox> can contain the <opt-group> — which is also optional — and groups all options with a label. It also contains the <option>, which can be more than one, and shows the values the user can choose from.
Since this is all very theoretical, let’s jump over and have a look at some code examples (the real fun part, finally!).
Let’s code the <selectmenu>
First, we will have a quick look at a minimalistic example:
<selectmenu class="new-select-menu">
<option>Option 1</option>
<option>Option 2</option>
<option>Option 3</option>
</selectmenu>By using this code, the <button>, the <selected-value>, and the <listbox> will be created.
Using this code snippet as a base, you can now easily style the select in whatever way you want. Spoiler: The fancier you want your select menu to be, the fancier your code gets. But you are not limited to using the default code, you can also add your markup to the element.
So let’s have a look at some examples which are a bit more tricky.
In this example, we are just using the code that comes with the default <selectmenu>. As you can see we use the pseudo-element ::(part) that tells the code which part of the select we want to style. This gives the possibility to address the bottom separately from the list box and provides them with all different kinds of styles.
And now, the best example, the one where you can add your own markup:
The slot=”button” that we are using here tells the <selectmenu> that the default button will be replaced with your custom button. But if this is used, we also need to tell the browser what element we actually want to use as a button. This is done with the attribute behavior=”button” on our custom element. Here we make sure that all the events and accessibility attributes — they need to work in their normal way — are attached. With this solution, you can also style and replace the <listbox> with your own markup.
These examples show you what wonderful magic can be done with the new selectmenu.
Problems with the <selectmenu>
As I mentioned at the beginning (a long time ago, but do you still remember?), the <selectmenu> is not yet supported by all browsers. To use it, you need to enable the “Experimental Flag” and this is only possible in Chrome.
The next big problem is that it is still very buggy:
- The popup does strange things when you scroll the page.
- The responsive behavior does not work properly.
- When using the dev tools, you won’t find the single parts displayed.
- Clicking twice on the <selectmenu> won’t close the <listbox>.
But as we all know, good things take some time. So stay tuned.
Some really nice use cases
Even if this stunning piece of art — and this time I mean it — is still in development, there are already some cool examples of how we can use it later on. Here you’ll find a link to the page: https://microsoftedge.github.io/Demos/selectmenu/
And now, feel free to test it and spread the word! And don’t forget to have a look at The Open UI Community Group.
