There has always been big differences across how different browsers handle form styling. There probably always will be – because UI design choices aren’t described in the specs. Browser makers perhaps view this as one of the ways they can differentiate the user experience a bit. Select (dropdown) menus are one that is particularly weird.
When I say dropdown menu, I mean:
<select>
<option>Apples</option>
<option>Oranges</option>
<option>Banannas</option>
</select>Left completely alone by CSS, this will render consistently across browsers. On Macs, 11px Lucida Grande.
Styling selects has changed a smidge since this article was written. Mid-2020 we still don’t have amazing styling control, but you can style the outside pretty well with this technique.
What if you change the font-family?
select {
font-family: Cursive;
}WebKit browsers (Safari, Chrome) will ignore you. Firefox, Opera, and IE will respect your change. The font-family won’t cascade into the select though, you have to explicitly declare it on them.
What if you change the font-size?
select {
font-size: 32px;
}This is a fun one. In WebKit, if the font-size is between 0 and 10px, it will render the font size as 10px. From 11px to 15px, it will render as 11px, and 16px or larger it will render it as (wait for it), 14px. This behavior is similar they handle search inputs.
Firefox, Opera, and IE will respect your change but again only if explicitly declared on the select, it will not cascade.
Can you get WebKit to respect your changes?
Kinda. You can set border: 0; on the selects and it will make it look like a kinda crappy version of a dropdown but still have some UI. It will also allow your font size and style choices to come through.
You can also set -webkit-appearance: none; and you’ll get what looks like a rounded corner input box, but still has the interactions of a select (click to reveal menu, keyboard commands, etc). It will also respect your font choices this way.
I’d say appearance is your best bet for fully custom dropdowns, but it would be WebKit only because while -moz-appearance: none; works it doesn’t remove all the chrome, just some. Opera doesn’t support appearance at all.
What about the dropdown itself?
As in, the thing that shows the choices when activated. As far as I know, there is no way to style these in any browser. Not even bold or italic. The closest thing to style you can get is grouping them by using . This is probably mostly a UI thing, but it might be a security thing too. You wouldn’t want people doing tricky things with fonts that make it unclear what option is selected.
What if you want complete design control?
First, try everything you can to make that not necessary. Default form elements are familiar and work well. Making a dropdown menu match the font and colors of your brand isn’t usually necessary and is more likely obnoxious at best and bad UX at worst.
If you decide that it’s absolutely a good idea to customize a dropdown, then you should use JavaScript to:
- Accessibly hide the original select.
- Rebuild the select with custom markup (probably a definition list), that you style how you want.
- Replicate all the functionality that default selects have, which include: keyboard events like up and down arrow keys and return to select, scrolling of long lists, opening the menu upwards when select is against bottom of screen, to name a few.
- For mobile, trigger the opening of the native select menu, because that functionality is just about impossible to replicate. For example, the iOS flipwheel.
- You might want to consider a “clickthrough” style for desktop as well. Have the select be custom styled by default, but when you click it, it opens the native dropdown menu (in place). When you select an option it displays the custom styling again with the choice shown.
It’s a lot of work and easy to screw up, so beware. This tutorial deals struggles through some of that. Here is a Pen with some of the testing from this article in it.
Nice one. Pity that styling dropdowns themselves appeared so late. I still don’t get – why only selectboxes were not editable with CSS so far. All input elements could be modified ages ago, but not selects :). I still use JS to do those the same for all browsers as you stated in the last paragraph, and I guess that solution will be required for at least couple more years
Not only selects haven’t editable appearance – it is also checkbox, radio and file input (that is not editable at all). The problem is that these form elements are not controlled by browser but by OS. The default select, checkbox, radio or file input looks very different even in Firefox on Windows, Linux and Mac OS (same for other browsers on different OS).
If You want to style the checkbox or have another file input apperance You still need some JS library to achieve the goal.
Wow, great timing. I was just researching this for a new project. Thanks!
For me one of the things that upsets me with (Win) Chrome is the font. They always end up looking choppy and then I have to use all these hacks to make it look better. Like this sites font looks choppy to me now. Especially the menu font on top.
The community has been complaining to Chrome about this for well over a year now but they haven’t done anything about it.
This is mostly because Microsoft left font anti-aliasing in the hands of the user (why? no idea, they do strange things, but they could have at least defaulted it to look good). Go under control panel -> appearance and personalization -> adjust cleartype text then make sure it is turned on. Fonts in general should look much nicer for you now on the web.
In my opinion, even with cleartype enabled OS X renders fonts nicer but it should at least help you a bit.
Smashing Magazine had a great article on this: http://www.smashingmagazine.com/2012/04/24/a-closer-look-at-font-rendering/
Chrome still uses Window’s old font rendering, while Firefox and IE9 use the new DirectWrite rendering method. DirectWrite looks great in my opinion, I’d love for Chrome to support it.
Cleartype makes no difference to how Chrome renders text. But yes Chrome is particularly bad at rendering most fonts.
Oh and I just realized that css-tricks is broken in Windows Safari Chris. I will hook you up with a screenshot/details so you can check it out.
Just wanted to point out that some of the drop-down plugins don’t really do the trick well. I have yet to find one that will fire events on both the real (hidden) drop-down as well as the styled (DIV) drop down. States will usually get updated properly, but events are not passed on as they should.
My favorite technique so far is the jQuery Mobile way, where an invisible native drop down is positioned on top of a styled dropdown. A events and behaviors take place on the real drop down, and you simply have to update the styled DIV with the selected value. The only drawback is you still can’t style the options (this is not a drawback in mobile, however).
Have a look over one me and a friend made, it seems to do the trick.
http://andrew-jones.me/blog/styling-select-items/
I would normally recommend against styling elements because it’s easy to do it wrong.
However, lately I have had good success with first using Modernizr to detect for a very new property (e.g. border images), then using -webkit-appearance: none; and restyling the dropdown with :before and :after elements.
Using @moz-document-url-prefix to fix some Firefox issues (namely Firefox reacts different to line-height and padding properties in form elements)
This works pretty well: IE9, IE10, Chrome and Firefox all get the nice select. When you click it you get the native options (this is not stylable).
However, it also is not very future friendly: once Opera starts supporting “obscure property” the plan falls apart.
Using JS to make a custom dropdown is not advised but sometimes you have to: maybe you want a mega dropdown or you want to display different content than only lists in the dropdown.
There’s a ton of things people forget when they code custom dropdowns, the demo mentioned in the article for example doesn’t implement (1) ESC key to close (2) clicking outside to close. Then there is (3) multiple dropdowns on 1 page (4) no z-index clashing with modals and other overlaid elements. The list goes on.
I hope browser makers do good work on the “shadow DOM” to make each and every UI element stylable. This will help the web grow as a true app platform (vs. native apps)
I’ve been dealing with dropboxes for a project now for a while. Being on mainly Linux I’ve noticed that (generally) newer browsers does obeys CSS rules better.
Here’s some screenshots for Chrome, Firefox & Opera, taken on Ubuntu 12.10.
I very much disagree with the last section. “Making a dropdown menu match the font and colors of your brand isn’t usually necessary and is more likely obnoxious at best and bad UX at worst.”
The only reason it is “bad UX” today is because of limited technology in the past. Many “standard” ways of doing things on the web became standard due to these limitations and now that the limitations have been lifted, I think its time we start branching out. Not all select menus need to look the same. Its possible to design a select menu that still looks like a select menu all the while not looking like the default OS.
If we continue to do things exactly as users expect them, then design on the web will never progress anywhere. I say push the bounds whenever you can as long as its fitting. Do your best to make sure it works for people on older browsers, but cater to the people staying up to date as long as they are not the vast minority. The future is not full of default styled anything. The future is wide open.
That is certainly not the only reason why it’s bad UX. Any deviation from the default OS style for form controls is most definitely going to confuse somebody. Considering you have absolutely no idea what OS a user is using, and therefore what that default OS style is.
You cannot be certain the user will never the less find your preferences as the page author intuitive enough to understand what the hell your alien drop-down menu supposed to be. Especially when users have customised their form controls in their OS.
The key is to design robustly around the form elements, and not mess with the form elements themselves. Frankly, if you don’t like the way a particular OS renders its form controls, then don’t use that particular OS.
Form elements don’t all have to be one way to be intuitive. Not all phones look the same, but you still recognize them as a phone based on the context. Every now and then there’s an exception where you see a phone and you think, “Wow, I had no idea that was a phone.” but on the whole as long as people don’t go crazy people recognize a phone when they see it. Even though the shape, color, buttons, etc are different. Form elements will be the same way if we let them. Form elements, in the grand scheme of things, are incredibly new. You want to lock them down and keep things the way they are? I want to keep it open and leave room for people to innovate. Perhaps we don’t have it right just yet?
Your comment about not liking default OS form elements could also be said about a website. You don’t like the websites form elements? Don’t use the website. :D
Generally speaking, custom form elements turn into unaccessible form elements, which is not fair, and down-right bad development. Someone with a disability needs to be able to use whatever you throw at them. Don’t forget that.
I personally hate forms that don’t allow me to fill it out entirely using my keyboard. It’s very distracting, and frustrating to have to lift my hand off the keyboard and click a slow-to-respond JavaScript “pretty” dropdown (which then of course does not let me narrow the 50 states by pressing “M”).
For the same reason its easy to see why leaving form elements as the user “expects” them is better UX. People expect forms to look like forms. There is no need to “pizazz” them up. Why make the user learn to use your new interface, possibly causing frustration, so that it “matches your brand?” Is a user really going to say, “Well…That was one boring dropdown! I don’t think I’ll be using this site again.”? I’m going with no.
You’re right, they don’t have to be one way to be intuitive, that’s why you shouldn’t style them. Styling them is trying to make them ‘one way’. Messing with them will increase the chances that somebody isn’t going to interact with them.
If you want the web to ‘progress’ with respect to form field design, then start looking at the operating systems. Any application that deviates from the native OS design is doomed.
As time moves on, my default OS themed form fields will keep up with any progress made through the years. However, your customised form fields will always stay the same, and will one day look or behave more dated than mine. So where is the progress?
Just stop trying to be clever, and keep it simple.
@Lee – You definitely flipped my words on me. When I said “Form elements don’t all have to be one way to be intuitive” you knew what I meant. I meant that all form elements on all websites look the same on a given operating system. And I still don’t think, from a design perspective, this is necessary for any of the reasons either of you have stated.
Take a look at Mint.com. They have a huge user base and they use custom styled dropdown menus with custom functionality. Chosen from the awesome folks at Harvest is another great example of customized form elements that are still very user friendly and arguably easier to use.
@Merne – It seems like you’ve been burned by some bad implementations of custom drop downs. But that’s bad technology and bad code. The design wasn’t necessarily the problem.
It seems both of you are very focused on what works right now and not how we can shape the future. And I don’t think anyone needs to go do design for an operating system if they want to change the world of form elements. Everyone seems okay with customizing textfields but that’s only because the technology has been there for a long time.
Over the years users have grown accustomed to a variety of ways form text fields look and it doesn’t seem to be a problem (even this site does it). The same will happen with all other form elements as the technology gets better. Look at what has happened to web typography. We’re finally making strides forward. And its not perfect yet, but its getting much better because people innovated and didn’t take system default as the be all end all. The more people we have trying to push the web forward, the faster it will move. I’m going to help push.
Ultimately though, I guess we’ll just agree to disagree on this one. It will be interesting to look back at this discussion in 10 years assuming this site is still around :D
But if you meant they don’t have to match the OS to be intuitive, then you’re mistaken, because they do. Any deviation is a distraction away from affordance. As real intuition doesn’t really exist in human-computer interaction, everything must be learned.
The working assumption is that OS is most intuitive because the likelihood is that it will have already been learned before they visit your site. Sites that deviate, cannot claim to be more intuitive, they can sometimes be more user-friendly, but that is not the same thing. Even if your site is better, the fact that it’s different will stumble users.
For example, the custom select boxes created by the Chosen plug-in (http://harvesthq.github.com/chosen/), whilst very good, and currently much better than OS, do not support all the keyboard short-cuts that native ones do, like page-up/page-down (could be an oversight).
Regardless, in standard drop downs, I expect to get to ‘United Kingdom’ by repeatedly pressing ‘U’, as typing ‘United K’ is often more work (and using the mouse means moving my hands when filling out a form), but on the enhanced Chosen drop-downs, repeatedly pressing ‘U’ is not supported by the design, and fails.
Of course, this could all be addressed, but it’s a lot of effort, just to get these ‘better’ drop downs to work exactly how everybody expects, when the alternative is to simply use what’s already available. You also cannot get custom designs to work how everybody expects since these controls behave differently on different OS, it would be an impossible task.
I could see nothing special about the design of the forms on mint.com, however, I’m not allowed to use it being in England. I could only see the drop down for country on their sign up page, which wasn’t special at all as far as I could tell (which is a good thing).
Only this weekend I ordered something on play.com and it took a few seconds more to find the button to complete checkout because of its background colour – and one would consider that to be an extremely minor and harmless deviation, as do I.
The bottom line is, if you are content with your style of form-field redesign, it’s a sure sign that you have designed them for yourself.
Please note: I am only referring to the type of activity described in the 5 steps at the end of the article. Doing something completely different or new is fair game, but you cannot argue that re-engineering an existing mechanism, just to realise your own branding or design of the same functionality is creative, progressive or justified. Not a single user will appreciate your effort, I mean, if they don’t want to use your site, it’s never because you’ve used default OS form fields, it’s always something else.
This isn’t quite true. I’ve changed the background of
optionin one project to represent the status of an option. (Green background for available, orange or something for possibly available.) Cross browser compatibility was extremely poor, and it did not work on a Mac at all.On Windows browsers, you can change the background colors of
option. The behavior is a little different depending on Firefox/Chrome or IE. I’ve discovered two odd things when stylingselectandoption:IE10 with
optionstyled to havebackground: white;renders the current selection unreadable: http://jsfiddle.net/HQLAR/On iOS
selectstyled with a-webkit-gradientwill eliminate the arrows indicating it’s a select box.Don’t reinvent the wheel if you don’t have to. If you’re using jQuery or Prototype, try Chosen. It’s easily stylized and improves on the
<select>functionality in a number of ways.110% agree.
No need to worry if this or that does or doesn’t work with this or that rendering engine in this or that OS.
Chosen is, hands down, the way to go if you need to style your dropdowns/selects.
I agree too, Chosen is definitely the way to go. It’s the best plugin I’ve personally seen for Dropdown Styling.
I’ve been trying some stuff on the select boxes and I found the following things, I can’t explain and they seems to be completely random.
The styling of the font, will only be applied to the select box if:
* You set the background. This could be like: background: green;, but background: none; will also work.
* You set the border-radius to more than 5 pixels. If you set the border radius to 6 the styling will be applied to the select box. Changing the border-radius doesn’t work at all, but it triggers the select box somehow. And it doesn’t make any difference or you set the border-radius to 20px or 100px, it makes it possible to apply some styling to it, but the size of the select box and the actual border-radius doesn’t change at all.
This is all in the latest chrome version on mac. I can’t figure out why these settings make the select box listen to the presentation markup…
See the pen I made (a fork from Chris): http://codepen.io/anon/full/HofDw
I’ve also tried styling this element in webkit, and even though select is kind of a container element, things like inheritance and pseudo elements cannot apply. As for the opt groups and options themselves you can change the background color but that’s about it.
Like Chris said, if you really need this to match your brand then JavaScript is the way to go—using a popular framework like jquery you can easily do just that….
Or if you don’t care about compatibility you can try doing it in pure CSS3 using :target… See my demo http://jsfiddle.net/alexh58/wymny/embedded/result/
Yea, it’s bloated and impractical, but it can be done!
Ummm… is it just me, or does the Pen display completely different behaviour to what Chris says? I’m on Chrome 22.0.1229.94 m, Windows 7, and the fonts are scaling properly (right down to 1px!), the font-family is applied even without the border hack, and the styling is being applied to the drop-down list, too!
The comment seems to have swallowed my image link; let’s see if it works this time:
Yup, you’re right. Even on the same browser versions, the
selectandoptionbehaves very differently across operating systems. Chris only looked at things on the Mac.First, great article. Moving on, it might not be the best solution to styling the options, but you can apply styles to the options via the style attribute on each option.
http://codepen.io/Pmac627/pen/kodDx
I’ve only done this once for font size. Its a pain with a ton of options (like state selection for example), but if the styling is the same, a loop would take care of that.
@Pat,
Styling individual select options works fine in Firefox, not in Chrome, which is the gist of the article.
Drupal users: http://drupal.org/project/select_with_style
@RdeBoer,
Is there a particular reason why the background-color works but the rest do not (with chrome)? Even using !important doesn’t override chrome.
I was looking for information about this yesterday! Are you spying on me?
Hi,
I tried to save this document in pdf using chrome, but when I view it, in pdf the texts are completely breaking. I’m an offline user & a great fan of your site.
@Pat — no idea what the reason is that colours are honoured only sometimes. As @Stefan pointed out earlier in this thread… there are so many factors that appear to have an effect in certain contexts and not others… There seems to be little consistency across browsers and OS’es when it comes to drop-down selectors.
Great timing! Just debating about the best way to do customise the dropdowns for a new project – very helpful!
Mozilla related bug https://bugzilla.mozilla.org/show_bug.cgi?id=649849
I used to work on a CRM software that supported only webkit, primarily.
The user could select a helpdesk entry’s status through a
<select>. As each status had its own tag bg color, I applied the status css class to each<option>and the bg colors worked pretty well, and that made the select very usable in that context, as people could easily recognize the status through color.This is what I used to do to change the appearance of Select menu even on Mac
selectwill there be any issues if we use this? See the jsfiddle demo{
border: none;
background: none;
-webkit-appearance: initial;
}
Firefox respects font styling inside of selects, specifically the old tag. I made an HTML5 editor called 5edit which uses these for the font selections. If you visit the link in Firefox you’ll see this in action, and any other browser of course you won’t.
Hi,
I just want to apply the color to the dropdown’s * character like Category *(red color for star)
thanks in advance
This seems to be broken in the latest version of Firefox 30. Anyone have any idea what happened?