Skip to content

ara pehlivanian

Web Standards, Web Culture, Web Everything.™

The Skinning Trade-off

Anyone who’s built a website has likely had to deal with the temptation to skin native browser elements, such as the pulldown menu, the input field, the radio button, the checkbox, the button, the text field and the scroll bar. The most common skinning job that pervades the web is that of the simple button. That’s because of the styling latitude browsers allow for that particular element. However, apart from a few colour changes, styling a pulldown, or worse a scroll bar, is next to impossible.

Even though browsers don’t allow elements to be skinned, it’s still possible to emulate them in JavaScript and skin them that way. But there’s a problem with this. Whenever you emulate a browser’s native functionality, you inevitably lose something. That’s because native elements have a whole slew of unseen things built into them that come for free. Some examples of this include focus and blur events, the ability to tab to them, that pressing the enter key while focused will in most cases trigger the element’s onclick event, and that changes to the state of some elements will be directly communicated to the OS for use by assistive technologies. Emulating these things is at best a difficult and cumbersome task and at worst, impossible.

On top of it all, usability experts recommend leaving these elements in their native rendering because that’s what users are used to and are expecting. Changing the appearance of an otherwise familiar element can cause confusion and will most likely cause users to think, which isn’t a good idea.

So even though skinning a browser element gets you all sorts of graphical awesome, you’re going to inevitably lose something by doing it. So the next time you’re tempted to skin a browser element, think twice and maybe just leave it alone, for all our sakes.

Sphere: Related Content

Buy my book

The Art & Science of JavaScript / SitePoint
The Art & Science of JavaScript

Advertisement

Firebug - Web Development Evolved

Advertisement

3 Comments

  1. Gravatar for Jonathan SnookJonathan Snook says:

    In my presentation at FOWD last year, I talked about this very topic. For every action we look to override, we have to work harder to replicate all the functionality that it used to have. Not just for mouse users, but for keyboard users, and for screenreaders. You have to have a pretty good business justification for breaking a user expectation and “it looks cool” isn’t one of them. :)

  2. Gravatar for Sarven CapadisliSarven Capadisli says:

    Not the mention the responsiveness will never be as good as the native support.

    No brainer, but, one plus that comes with skinning native browser elements is actually improving the UI visually (invoking certain emotions yadi yadi yada) and have it more consistent with the rest of the page design. Usability vs. Emotions - There is a trade off at some level.

  3. Gravatar for Luke MaciakLuke Maciak says:

    Well said. I ran into the same set of issues when my boss decided he wants to have a 3-state check box (checked, unchecked and unavailable/grayed out). I had to hide the actual elements, then use JavaScript magic to replace them with images on the fly, and react to clicking.

    Keyboard navigation was lost, and the whole system would fail if you were using a screen reader or a browser without JS enabled. In the end it worked out because it was an internal app used only by certain employees.

Leave a comment

Note: First time comments will be held for moderation as an added anti-spam measure.

Skip to navigation

More stuff by Ara elsewhere on the web

    Snook Approved!

    © 2005-2008, Ara Pehlivanian.

    Stock photography courtesy stock.xchng. This site uses Akismet to catch spam (54,743 caught since May 2006) is hosted by DreamHost and powered by WordPress.