Non Native Form Controls

Been a while since I did a blog post, been probably the busiest I have ever been over the past 3 months, but I have been a bit disappointed that I have let my blog suffer as a result. Continuing in a slightly negative vein I’d like to post about something that as a developer I just don’t get.

I’ll freely admit that I’m not a designer and that if I was I’d probably get just as annoyed when looking at a design where something doesn’t quite fit in with the overall feel as when I see a piece of code which is not as aesthetically pleasing. However if the code works I’m inclined not to change it, after all if it ain’t broke don’t fix it. So why, if there are such compelling reasons not to, do designers insist on changing the look of native form controls? Specifically I am talking about <select> and <input type=”file”> for fields, although this can easily be extended to checkboxs, radio buttons and to some extent submit buttons.

I won’t argue as to the how good or bad they look as to me its a bit of a non issue, but I can come up with some fairly compelling arguments as to why changing them, probably through the use of JavaScript is a bad idea.

  • Native controls are bullet proof – by this I mean the browser makers have spent considerable amounts of time coding and testing the native controls to ensure they work correctly. They have found and fixed all of the hundreds of edge cases, as opposed to a JavaScript solution which potentially cannot handle a multiple selection use case, or a list which is 1000 options long.
  • Native controls are future proof – what happens to your JavaScript implementation when a future browser gets released that changes the way it handles scroll events? Native controls don’t suffer from this, they will work in future releases as the browsers makers test them for you.
  • Native controls are familiar – everyone who browses the web will have come across a native control, will recognise is and will be fairly comfortable with how it works. In terms of usability you can’t trump that.
  • Native controls are accessible – going back to my first point, native controls have a lot of inherent accessibility built in, you can use the mouse or keyboard to interact with them and things like screen readers are well aware of them. Unless your JavaScript implementation covers all the same use cases that a native control does then you are simply using a inferior form element.
  • Native controls are (more) secure – a standard file control has a lot of security built in. Drag/drop interfaces whilst nice don’t always have this inherent security built in.
  • Native controls are cross browser compatible – you don’t need to worry whether your JavaScript implementation works in IE6, it just does.

This list isn’t exhaustive but it does highlight the advantages of using native controls. I’ll give a couple of recent examples.

For a project I recently did one of the requirements was to be able to upload a file via a public interface. The design had a lovely branded purple browse button and accompanying , which granted probably looked better than the standard browse button. I explained at the start of the project that styling a file form field is difficult to do and I wouldn’t recommend it. Regardless it went ahead, but I caveated my quote with a non guarantee that it would work cross browser. I styled the button using a JS implementation and for the most part it worked. I then got a bug report that it didn’t work in Firefox 14, sorry I can’t guarantee it will work. Not a huge deal as it turns out the work/won’t work scenario was intermittent (great!!). Next is this doesn’t work in iPad, well no of course it doesn’t file fields don’t work in iPad, thing is that on an iPad the native file field would be greyed out and disabled, the styled file field isn’t, there are probably a hundred mobiles that this is the case for. If we had used a native form field both of these problems would not have been a problem, it still wouldn’t have worked on an iPad but at least the user would have known.

The second example (from the same project) was that a drop down menu that had been styled didn’t work in Safari 6. It was another JS implementation, fairly good cross browser support and had recently been updated so still actively maintained. But still it had certain use case where it didn’t quite work as intended.

I’m not going to argue that layering on top of native form fields isn’t a viable progressive enhancement technique especially if there is a good usability case for improving the functionality. However to do it for purely design reasons ignoring the disadvantages of doing so doesn’t seem like the brightest idea to me. Stick what CSS can do and you can’t go far wrong, bring JavaScript into the equation and you’re asking for trouble.

Now I have to get on with some work, ah yes a lovely dropdown menu design sigh…

Clash Of Clans Cheat And Hack Tool

4 Replies to “Non Native Form Controls”

  1. Pretty strong arguments against custom form-controls, Interested to know if you think there are any pros at all?

    I think there’s plenty of room for improvement for browser form controls using CSS and JS, especially for some of the new HTML5 input types which are still quite rough around the edges, although shadow DOM should make a big impact here if/when it gains traction.

    1. I’m all for progressive enhancement of form controls to offer functionality that isn’t available or poorly implemented, a classic example which springs to mind is multiple select which is very unintuitive to the user, enhancing this form control makes sense. However adding “gloss” to a form control that replaces it (often in an inferior manner) is not something I can advocate.

  2. Do we dare bring up custom scroll bars?

    Great article. There are a number of ways to use CSS for enhancing native browser functionality, though limited to mostly newer browsers. This goes back to the progressive enhancement argument people have been making for years. I think it is completely feasible as long as WE educate our clients – they’re not going to read these blogs so they have no information to go off of except, “Well we approved that design but it doesn’t look like that on my computer’s IE7.”

    1. Good points, I’m a big fan of progressive enhancement where you are adding/changing functionality to a native control. I think its just the pure cosmetic changes that irk me.

      I also don’t entirely agree with the educating of clients, more of the educating designers (unless they are considered clients!!) Educating them on why changing the design of a native control could be considered a less than optimal solution would be more advantageous in my opinion.

Leave a Reply

Your email address will not be published. Required fields are marked *