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
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.