Why styling form controls with CSS is problematic

As someone who has spent lots of time taking screenshots of various CSS applied to form controls, I know that styling form controls consistently across browsers and operating systems is impossible. If you don’t know what I’m talking about, have a look at Styling form controls, Styling even more form controls, and Styling form controls with CSS, revisited.

In the discussions following those articles (and any article that discusses styling of form controls), there tends to be a bit of frustration expressed by designers who feel that being able to specify exactly how form controls appear in a graphical browser is necessary for their design to work well. I really cannot agree with that. In my opinion form controls should be left mostly alone (though some light styling may be acceptable) in order for the user to quickly recognise them for what they are.

Regardless of whether or not you agree with my opinion on this you will probably find Eric Meyer’s article Formal Weirdness a good read. In the article, Eric explains some of the technical reasons for form controls being so hard to style consistently across platforms with CSS. He also asks a lot of good questions related to how various CSS properties should affect form controls if browsers would let them.

Eric wrote the article as a follow-up to his series of articles about resetting the default CSS in browsers in order to get a consistent, cross-browser base stylesheet. His reset stylesheet evolved over several articles, and the final version is described in Reset Reloaded. Several people posted comments asking why Eric did not use a universal selector to set the margin and padding properties of all elements to zero. Eric’s response to that is that he avoided doing so because of the problems it causes for form controls.

After reading Formal Weirdness I think you will understand why.

Posted on May 24, 2007 in CSS, Quicklinks


  1. Well, in general I agree with you. But at the same time, in web sites where design and image is a very important aspect, i think it’s ok to add extra styling to those who support it, and let it fallback to the default rendering to those who don’t.

    However, to find that delicate balance is a bitch… :-)

  2. May 24, 2007 by Roger Johansson (Author comment)


    add extra styling to those who support it, and let it fallback to the default rendering to those who don’t

    How would you apply styling only to the browsers that support it? JavaScript browser sniffing? CSS filters? As a Safari user I’ve seen too many examples of half-styled form controls rendered almost unusable (and very ugly).

  3. Oh, I agree. And no, not by JavaScript or CC filtering; only regular CSS.

    It can only be done with minimal things like setting a height, or removing borders (thinking mostly of text boxes now). But then, of course, the result has to be tested to ensure that it doesn’t break anything.

  4. I don’t agree with you there Roger. Navigation is also an integral part of the site, and it’s very important that people recognise it. Still you don’t adapt it to the operating system the person uses, it’s up the the programmer to make it work. Should select boxes behave any different? I don’t think so.

  5. May 24, 2007 by Roger Johansson (Author comment)

    Robert: Ok, I’m with you now.

    Emil: Well, we’ll just have to agree to disagree. I’ve never understood the desire to do more than very light styling of form controls. As a user I find that attempts at advanced styling just get in my way, slow me down, and more often than not end up being uglier than the original form control.

    In my opinion, browsers should either disallow all form control styling or allow it in a consistent manner and have a “Do not let pages change the look and feel or functionality of form controls” option in their UI.

    Hmm. That would be nice actually. Anyone know of a browser (or extension) that allows the user to disable form control styling?

  6. Roger: I believe Opera 9 is configured by default to disable the styling of forms. You have to ‘Enable styling of forms’ in the options for it to act otherwise.

    Great post, by the way.

  7. @Hamish - that option must be set to be on by default though because I’ve never turned it on and it’s on on my machine (I didn’t even know it was there until I looked just now).

    Interestingly, turning it off didn’t seem to turn off all form styling - the form I tested still had background-colour on both the fieldset and select/option (inputs and textareas went back to normal).

  8. Having struggled on occasion with inconsistencies on form elements - and one client I remember who insisted on pixel perfection on any browser he came into contact with - I pretty much agree in principle. Also the usability of forms is an important factor to consider. But in practice I have to admit I do attempt to give a customised look.

    Its one of those things I do and feel dirty about later.

  9. My current thinking is somewhat parallel to yours Roger. I say current thinking because I used to style forms heavily. I say somewhat parallel because I know I still style my forms more than you do.

    I use classes with form elements so I can get very specific and avoid unintentional inheritance, then I will typically style legend and label font specifics, adjust input sizing, and I will provide a focus border and background —- which I feel is beneficial —- but slight changes only. I also style fieldsets, of course, usually by doing nothing more than stripping the border. I try not to go crazy with the elements, and some I simply won’t touch (i.e. checkboxes). I accept what I cannot change.

    What you relayed about Eric Meyer’s thoughts on the use of the universal selector is interesting and something I haven’t considered. Thanks. It is something I use, but I guess I’ve been lucky when applying my on-demand reset (I don’t use a pre-made resets but rather reset on the fly).

    This is good timing because my next-up blog article will be “The Power of Zero” and Eric’s thoughts will lend some balance. Thanks.

  10. I think like Emil. There are several elements on a site which should be default as possible. If you are a good graphical designer (I’m surly not!) you are able to change the appearance of these elements without affecting the usability.

    And on the other hand it’s easy to create a form which is not user friendly despite of not styling it.

    Therefore I would be careful making too general statements.

  11. May 25, 2007 by edbm

    As a user, I feel an urge to beat somebody up every time I see a page with too-much-styled input controls (see an example which I frequently use) – when I write controls I use only very light styling, and almost only on buttons. I feel it is more important not to confuse the user than to display eye candy.

  12. I tend to set the width, height and font of form controls. Sometimes I will use an image submit button to meet a designer’s need as long as it still looks like a button. I’m unhappy with sites that change buttons so much they become almost unrecognizable as a button.

    I like what Happy Cog Studios did with the search input and submit controls on Dictionary.com. They made them huge! It works because that is the most important thing for the user when they come to the site.

    A little, but not much styling can be a good thing.

  13. Wow forms and CSS, I spent hours yesterday getting two forms on a site I am creating to be consistent across the majority of browsers both mac and pc. Maybe I should take your view Rodger and leave the majority of the styling up to each specific browser. It would have saved me a lot of time yesterday! Interesting thoughts.

  14. I totaly agree with Tanny. When I’m dealing with form controlls the only things I’m messing with are the width and height and occasionaly an image submit button.

    In my opinion form controlls should be as universal as possible, just for the sake of the user experience.

  15. May 26, 2007 by Meh

    Form controls should be treated no differently than any other element on the page. It is the job of the designer/developer to ensure that the intent is clear. Yes, there is potential for abuse, but no, default/universal form controls are not so perfect, obvious, and intuitive for every possible scenario that they never need modification. Limiting the amount of modification possible doesn’t help anyone. Even Apple don’t follow their own UI guidelines 100% of the time. Why not? Because it doesn’t make sense! Guidelines are just that: guidelines.

  16. Even for the web?

    I agree that UI design can have it’s own form controlls or, for that matter, UI controlls. But for the web, forms are (let’s say) 95% just forms. They aren’t a part of a big UI with huge function lists.

    In general: all real web forms like: emails, comments, posts, search, etc. require the same elements and user interaction thus, in my opinion, shouldn’t interfere with UI expectations.

    Allmost all UI’s of big web apps, which require a lot of user interaction, are realised with javascript, Link elements and a lot of DOM manipulation.

    So I say styling the form controlls should be left alone, appart from applying widht’s and or heights.

    Here’s a question that came up in my head while writing this: For rich user interfaces on the web, should there be other elements than default form and link elements?

  17. May 27, 2007 by Meh

    Yes, even for the web, where as a matter of fact there are an increasing number of pages that are “part of a big UI with huge function lists.”

    Yes, users come to the page with certain expectations of how a form on a web page looks and works, and it is obviously very important for the author of the page to be aware of those expectations. However, it’s also important for the author to have the capability to expand beyond those expectations if and when a more appropriate solution exists, such as a convention commonly used in desktop apps (and thus also already known to the end user).

    I am not saying we should alter the default appearance or functionality of these elements lightly or without just cause. However, we cannot be so draconian as to say, web forms must always use default elements with default styling, because that implies that they are now and will always be the perfect solution for any problem thrown at them. That’s absolutely ridiculous.

  18. May 27, 2007 by Roger Johansson (Author comment)


    However, it’s also important for the author to have the capability to expand beyond those expectations if and when a more appropriate solution exists, such as a convention commonly used in desktop apps (and thus also already known to the end user).

    Changing the styling will not change the functionality of a form control. You also have to consider that user expectations are quite different for desktop applications and Web applications, as Bill Higgins points out in the Uncanny Valley of user interface design.

    However, we cannot be so draconian as to say, web forms must always use default elements with default styling, because that implies that they are now and will always be the perfect solution for any problem thrown at them.

    Until form control styling is standardised in a specification that is reliably supported by all browsers, I don’t see how you can get away with drastic styling without causing major problems for some users.

    If you change the appearance, and especially the behaviour, of form controls, you must make sure that doing so does not break functionality in any browser and does not cause any accessibility or usability problems.

  19. May 28, 2007 by pd

    One of the most annoying aspects of getting behind standards like CSS is it’s intrinsic failure to do simple things.

    If see another tutorial that assumes labels can be floated left of form controls and given some arbitrary percentage width to make them consistently column-like in relation to the form fields, I’ll spew.

    This ‘technique’ is not accessible as all it takes is a modified font size to break it. Nor is this ‘technique’ implemented well by browsers due to floated objects not sitting cleanly aligned with the objects they wrap around.

    Float any box element and the first thing you will notice is the bottom of it sits anything but aligned to the bottom of the element it floats around.

  20. June 2, 2007 by dbrimlow

    To me, there comes a point when a basic principle for one issue suddenly bleeds into others and before you know we have repression of creative expression.

    While I believe in standards and always tsk-tsk when I see a major corporate website using garbage code, I also believe there comes a point when people take a martinet approach to design issues on supposed browser functions.

    Yes, a brwoser’s window and scrollbars should not be changed from the browser’s skin. That should be sacrosanct.

    HOWEVER. That’s where it should stop. I don’t touch the browser skin … it doesn’t touch my design.

    Please, styling form controls and using “in-design-scrollbars” to compliment a beautifully crafted design layout does NOT cause people to throw up their hands saying they are lost and can’t understand how to work the page.

    So long as it does not affect the browser window, where is the problem?

    By forcing designers to use a browser skin WITHIN their design … is simply wrong.

    People are NOT so stupid that they become confused when coming across a changed form item or colored scroll-bar WITHIN the design itself.

    And this has and always will be one argument that I will never side with standards.

    To me, it is dictating the creative process … and that smacks off censorship.

    As a musician, former fiction and non-fiction writer, as well as a web developer, nothing gets my goat more than attempts at repressing any creative expression.

    Leave the browser skin and window alone … fine … but conversely, don’t force the browser skin within my design.


Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.