Formalize CSS — Dress up your forms!
As designers, we are used to having quite a bit of control over how things are displayed in a browser. Sure, differing rendering engines don't always agree on everything, but for the most part we can at least find ways to mitigate variance through workarounds, or by writing for the lowest common denominator.
By far, one of the most frustrating parts of dealing with browser inconsistencies has got to be forms. There are two distinctively differing schools of thought regarding (not) styling form elements. For the longest time, we've had people on both sides of the proverbial fence, neither group being particularly pragmatic.
Some designers advocate styling form elements to match the brand of a site. Others would tell you to leave them alone entirely, so that they adhere to the native look and feel of a given operating system.
That's all well and good, except most browsers don't mesh completely when it comes to OS consistency. Some browsers use a monospace font for
textarea, and OSX neglects to style the border of
textarea the same as text
input elements. So what's a designer to do? It's a conundrum, for sure.
I would say that I fall somewhere in the middle of the two camps.
I want some measure of control over form elements, without changing them so drastically as to appear foreign in a user's operating system. Thus, my quest to find a happy medium, where browsers would generally agree and let me keep my sanity. The result is what I'm simply referring to as Formalize CSS.
I've attempted to bridge the gap between various browsers and OS's, taking the best ideas from each, and implementing what is possible across the board. For the most part, this means most textual form elements have a slight inset, and all buttons look consistent, including the
I have also added a few niceties. All browsers that support
box-shadow — even those on Windows and Linux — now have a light blue
:focus border, ala OSX. Also, via jQuery I've added support for the HTML5
autofocus attributes, for browsers that don't yet handle it natively.
I've left untouched the input types of
file. As far as I'm concerned, they are the pariahs of form elements — inconsistent and stubbornly resistant to styling. For those browsers that do actually support
range, it's a slider, but for those that don't, it's a text box. I've left it alone, with the assumption that when all browsers eventually handle
range, they'll do so as some sort of slider.
Make it Yours
Note: In the demo pages, I have not applied any widths, so that you can see how browsers would natively handle the various form elements. For instance, Opera styles some elements (url, email, datetime, datetime-local) considerably wider than others, a quirk I've not seen in any other browsers.
I have included utility helper classes at the top of the formalize.css file, which can be sprinkled in to add set widths to the
select tags, such as: input_tiny, input_small, input_medium, input_large, and input_full (100% width). Feel free to change these, or delete them entirely. They're simply meant to be suggestions, to show how you can resize elements if need be.
Unlike a framework such as the 960 Grid System — which is intended to be written against, but not altered — in general, Formalize exists just to offer some guidance as to how you might approach form styling. Nothing is set in stone. If you want to adapt it to more uniquely suit your needs, go right ahead.
I debated whether to leave
<select> alone, since I rather like how it looks in WebKit (Safari + Chrome) on OSX. However, since it's the "odd man out" so to speak, I went ahead and styled it to look consistent across all browsers. For what it's worth, this is how it would've looked in Safari on Windows anyway.
I've managed to wrangle the
search input under control in WebKit. This means that Safari and Chrome will render
search the same as a
text input, but you still get a recent search list, and clear/reset
[x] functionality. In case you're curious, these magic lines of CSS undo WebKit's native rounded styling:
IE6 & IE7
input[type=text]. Oddly enough, this involved duplicating styles, rather than stacking IE6 class names, because the presence of an attribute selector in a comma separated list of elements will cause IE6 to ignore the style rules completely. For example…
/* This works in IE6. */
/* This doesn't work. */
Needless to say, if you do not need to support IE6 (hooray), feel free to delete the entire section in formalize.css that pertains to it, because all those styles are duplicated just for that one browser. Really, you ought to drop IE6 anyway.
Additionally, IE6 and IE7 have faux
box-sizing support added for
class="input_full", so they can go to 100% width, and still have border and side padding applied. You can read more about
box-sizing at CSS Tricks.
Several people helped me make Formalize what it is. Namely, Anthony Short for pointing out that
search is indeed conquerable in WebKit, and Chris Coyier for a tip on how to style the color of
placeholder text. Additionally, thanks to Jonathan Snook for taking a screenshot in IE6 on Windows XP for me (just to double check IETester), and to John Saddington for snapping a shot on his iPhone 4.
Note: Formalize's buttons differ slightly from these screenshots (now less round).
If you're curious how things look in various browsers and operating systems, check out the attached screenshots. I have to say that while Opera takes the cake as far as raw functionality, it also sports the ugliest looking styles for some of the newer HTML5 form elements, the worst offender being