In this article I’ll take a closer look at the
<select> box and give you some handy tips on what you should think about when desiging or developing a website and considering creating a custom select box and not using the browsers pre defined styles and functionality. Spoiler: Don’t.
I am not a designer. I’m an interaction designer and a frontend developer. I can understand that designers want to deliver a full package to their clients. In a web project they want to deliver an end product that has been fully customised to fit into the visual profile they have created for them. Everything down to the last detail has to express something from the profile. I totally get that. It’s part of being proud of your art and what you do. If you let someone else, in this case the browser, take care of how something looks, you’ve not done your job. It’s the same as using Bootstrap elements so you don’t have to make them yourself. Lazy and unprofessional, right?
If you’re gonna do it, be nazi about it
Let’s say you’re making a select box in your HTML. Here’s what an unstyled select box looks like:
It’s not the prettiest thing in the world, but it does the job. Let’s take a closer look at it’s functionality and appearance across the four major browsers on Mac OSX Yosemite and Windows 8.
The differences between the select boxes in the same OS are almost none. I’m not a browser developer, but I’m guessing the browser takes a lot of functionality and design from the OS itself. Just take a look at the browsers on OSX Yosemite’s way of rendering them. The reason my select boxes has the blue box on the right side is that I’ve chosen the blue theme in my system prefrences. If I’d chosen the graphite theme they would be graphite. Check out the screenshot below. . The fact that all select boxes on my computer has the same style - not only in my browser, but in my OS as well, really makes it easy for me to understand the functionality of it once it appears on a website. This goes for radio buttons and checkboxes as well.
The differences between the select boxes in the two OS’s are subtle, but big in terms of UX. The biggest difference is that on Windows they all have arrows pointing down, and on the Mac there have arrows pointing both up and down. You could argue for both of the designs, but my personal thought is that Apple is doing it better in this case. The reason is that on a select box you might have chosen an option that is in the middle of the list. When you click on the select box again you will have options available up/before and down/after your selected item. Windows is taking the approach to the select box as if it was a dropdown list. It is not a dropdown list. It is a select box.
Why native select boxes are awesome
I look at the
<select> element like a special child in HTML. The reason is the way browsers treat it. When you click on the select box the browser goes out of its way to show you the options inside it. Let’s say you’re visiting a website and there is a select box on the bottom of the screen. When you click it, the browser gives it a z-index that trumps all z-indexes in the browser, and it even goes outside and over the browser window itself to show you the content. Check out the screenshot below:
If this select box was a 100% custom checkbox it would fail miserably and not show you the content. It would be hidden behinde the browsers own overflow. You would probably wonder if you’d clicked the select box or not.
Another good example is how touch devices/touch OS’s handle select boxes. Check out the screenshots below:
If you’re gonna do it custom, go hybrid
If you are a frontend developer that is involved in the design process, you should be able to have a constructive conversation with the designer about the looks of the select boxes. Here’s a list of things to keep in mind:
- You should never agree to go fully custom. You want to keep the sweet treatment the browser gives the
<select>element. You must therefore always use the
<select>element if you are creating a custom select box. You have to describe to the designer what you are missing out on if you go fully custom. And by fully custom I’m talking about not using the
<select>element and doing something like this instead.
- Since you now have decided to use the
<select>element you can explain to the designer that you can’t control how the list that appears when you click it will look. This is up to the browser. The only thing you can control is the button to open it up.
- This brings you over to the next topic, which is if you’re gonna go with just the standard unstyled select box, or if you want to customise the button - and if so, will it have an arrow pointing down (Windows style) or one pointing up and one pointing down (Apple style) ?. If you go with the Apple style, the Windows users will be confused because they are used to the one arrow pointing down. And browser detection is out of the question. UX wise it is most definitely safest to go with the native unstyled version. It will adapt to whatever OS and browser it is in, and the users won’t have to get confused.
The hybrid technique
The hybrid technique is based on wrapping the
<select> element inside a container. Let’s call this container .selectContainer. The .selectContainer has to have an
overflow-x: hidden; and the
<select> inside has to have a width of about 160% to hide the arrow graphics the browser/OS gives it. We can now use the .selectContainer to give the user an illusion that this is the
<select>. Styling this is up to you. In the live example I’ve put the “icon” in the :after element of the .selectContainer, but you can of course use a background image.
Custom select box basic styles by hanserino (@eplehans) on CodePen.
I guess the point of this article is to highlight the importance of having a discussion with the designer around the
<select> element before the design gets into production. It is important to know the pros and cons of native and custom select boxes and how the browser treats them.
Here is question you should ask yourself and the designer involved in the project when deciding on going native or custom:
<select> contain a lot of options? If so, what is worst case? Will all of the options be visible when the select box is open?”
If the answer is no, go for the native unstyled version or an elegant/subtle hybrid version. If the answer is yes, you should consider calling it a dropdown list and design it like a dropdown list with no similarities or indications that it will act like a select box.
If we don’t use the
<select> element when creating a select box we are also screwing up with our semantics. This also screws up for our accessibility levels. Changing the looks of form elements is dangerous for people with low vision. Not using the
<select> element also screws up for our screen reader users. It’s just like road signs. If you cross a border to a new country or state and the sign for yielding looks way different than you’re used to, you will be confused and make errors. Don’t create confusion. Give the users a consistant user experience. Going to a new website is like crossing a border to a country or state.
So please, think twice before you design or start developing a custom select box.