Selectable Elements Are Driving Me Crazy: Here's How to Fix It

Written by

Let’s talk about selectable text and the web. And here’s the big point I want to make, not everything on the page should be selectable. Ask this question: “Would a user want to paste this into an email?”

The Problem with Selectable Elements

Selectable text is an important of the web of information. Anyone who doubts that needs only to remember back to the pre-copy and paste days on the iPhone. People were really excited about that feature. In describing his guesses for iOS 3 Jon Gruber outlined his hopes and then concluded with “pretty please, Mr. Forstall, with sugar on top — copy and paste.”.

Today we aren’t just building websites, though. We are building web tools and applications. It’s really exciting. I use tools like Github, GMail, and Pandora everyday. These aren’t websites, they’re applications. I think all of these sites could do a little bit better on user experience and it’s all about text select.

The point is that all UI elements should not be selectable. Working backwards here, let’s think about why users want to copy from a webpage. Some users are copying because they want to share the text on the page. Other users, Sharon Newman who wrote an entry about IE’s selection behavior use text highlighting to have a place that they are tracking on the page. Other users are grabbing images.

With this in mind, what isn’t the user trying to select. Certainly not your buttons, and other UI elements. And that’s the point. UI elements should not be selectable, it’s a confusing user interface. In fact, the W3C agree’s with this recommendation:

Note that although the initial value of ‘user-select’ … [allows only the selection of text Browsers] … typically do not allow selection of the contents of a BUTTON element. E.g. BUTTON { user-select: none }

Ask yourself this question: “Would a user want to paste this into an email?”. Then always air on the side of allowing them to select more than you think they would want to. Let’s take a look at Github’s user interface:

The sections in green are things that I would definitely like to select, in orange perhaps, and in red not at all. With the idea that you should always allow the user to select more of the page, rather than less I would allow the orange regions to be selectable. This small change makes the website more professional: you are treating UI elements like UI elements.

This starts to matter even more when you’re designing UIs using HTML and CSS and then packaging them for distribution as apps. TileMill is packaged as a native mac app. However it’s not a native map app, it’s a node js project that renders to an embedded browser. This creates weird problems were UI elements are selectable. It’s a dead give away that it’s not a “real” mac app. Take a look at this:

This also matters with phone gap apps on iPhone and Android. You want those apps to feel like real apps, not HTML imitations. One more place text selection really matters is on charts and graphs. Take a look at this example graph from Morris.js:

It’s a better user experience to have these labels not be selectable.

The Solution

What’s a developer to do? Here’s the quick code solution:

    -webkit-touch-callout: none;
    -webkit-user-select: none;
    -khtml-user-select: none;
    -moz-user-select: none;
    -ms-user-select: none;
    -o-user-select: none;
    user-select: none;

user-select is a draft CSS3 property. You should know that user select is not inherited but does affect children; it works like ‘display: none’

Comments or Questions? Contact Nick @nixterrimus on twitter.

Nick is a software engineer, geek, web enthusaist, open source contributor, home automation tinkerer, ocean admirer and all around general optimist living in San Francisco. Want to get in touch about professional matters? Nick Rowe is also available on LinkedIn.