Is "user-select: none" bad UX?

Question

I was having a discussion today with a colleague. I showed her "user-select: none" - a CSS property that stops a user from selecting text.

To me, this property allowed a more app-like experience to be created on a page - ensuring that events like double -clicking didn't cause text selection on areas that wouldn't be selectable in an app (like options on a nav bar, custom select elements, labels, etc).

My colleague disagreed that it added any polish, and suggested that users should be able to select and copy any text in a web-app.

What's the consensus on this from a UX perspective. Should we be trying to make sites feel more like apps? Or should the web feel like the web - meaning that we don't change default behaviors like this one?

Answer 1

There's an easy way to approach user-select: none, and that is to ask a single question:

Would selecting the text be the primary/secondary interaction a user would intend if touching the screen there, or would it be a hindrance to the task they were trying to carry out?

Image Carousels (love them or hate them) are a fantastic example of this. In a touch interface, what do you—as someone trying to interact with the carousel—want to happen when you press your finger down above one and then slide to the right or left? Do you want the carousel to rotate, or do you want to be selecting the image under your finger?

If an individual carousel image element gets selected by accident while scrolling, can you even deselect it, or are you now presented with a selected element that may do something else if you try tapping it to deselect it (such as page navigation, if the img element is encased in an a element)? Or, depending on the arrangement of divs that makeup the carousel's structure, did you now just somehow select a higher layer that's leaving a selection highlight across each image? (I've seen all of these happen in poorly coded carousel implementations)

Generally speaking, this is a case where you want the presented set of objects to work as a navigation control (sliding list of images) and if the browser interpreted the touch as a selection command it would interfere with that role and make interacting with your control frustrating.

The goal in employing user-select: none should always be limited to reducing user frustration from unintended selections resulting from interaction that can easily cause them when attempting to carry out the primary task purpose of a control it is used on.

"What about protecting my content from people who will copy it by selecting it!?" you may be inclined to ask. The answer to that will always be: no. Not only is that poor UX, but it is also absurdly pointless. Anyone who truly wishes to copy your content still has access to it; you've just made it more frustrating to get to, which will make them less inclined to care about whether what they are doing is ethical: you're essentially promoting moral disengagement and allowing their evaluation schema to balance their normal ethics schemas against their frustration with you, reducing the threshold of cognitive dissonance in self justifying an act like copying your content.

user:select none is never a security factor. Never use it expecting to achieve any higher level of security from copyright infringement/etc. Your content is still right there in the source (and is still easy enough to take screenshots of, which would be even harder for you to find if you were trying to trace infringement).

You should never use user-select: none to prevent selection of content text. The browser itself is responsible for deciding between scrolling and selection in this case and should be relied upon to do its job properly in discerning user intent between the two potential actions (selection or scrolling). While there will always be exceptions, keep in mind that these two actions are globally consistent expected interactions. Interfering with them will likely lead to your application not behaving in a manner that is expected, which is a primary source of frustration.

Personally, I would say you are on the right track with your example uses.

I would only caution that user-select: none is a very blunt edged instrument to be employed only based on definite need. While it can add polish, be careful that you aren't using it someplace where from your context selecting seems pointless, but which might actually be something a person using your application would want to be able to select for a given reason, and where being able to select it won't otherwise interfere severely with the intended interaction in attempting to carry out the primary task the control exposes.

A good example of this is modal error dialogs. It might be tempting to make them non-selectable so that any interaction removes them, or some similar rationale for what's intended to be a streamlined experience of some sort, but this can be hugely frustrating if someone is faced with an error and wants to look it up or report it to support, but can't easily copy it to do so. Always err on the side of caution and a light touch when affecting and especially when removing standard provided modes of interaction within a given environment.

In general, I would say that any time something is (or includes) informative content—like the error message example—rather than a control action that contains no new information, it in nearly all cases should not have user-select: none applied to it. This is especially true when that content is not presented in a selectable form elsewhere on the same or a tightly related screen. There will always be exceptions, but I would caution that it is generally better to re-evaluate how you are implementing something and finding a different method of control than it is to apply user-select: none where content is presented instead of simply action words/generic terms/etc.

Some people would argue that (some) mobile applications have removed the degree to which this is a standard interaction. I would say that within the broader, most global context it is still a standard interaction and many of those applications have likely degraded their user experience by doing so, or have simply been sloppy in their programming by not providing the ability to make selections (as is sometimes the case, instead of specifically disabling them).

Particularly when we are presenting an application through a different agent (such as a web browser) it is important to let the user agent preserve its own methods of content interaction as much as possible. Not only does this increase conformity and consistency in the user experience, but it also heightens cross platform/agent compatibility, and even helps ensure future proofing and functionality across use cases or environments you may not have personally foreseen.

Answer 2

In general, you shouldn't use it globally.

Oftentimes, users select some text, maybe to highlight something to show a part of the text to a friend, to copy text or to mark the text just to be able to read it better (which I do when the text is pretty wide and it's hard to follow the text wrap in the sentence).

However, there are really good examples where it is a good option.

• A button

  If you allow a user to select the text on a button, they might think they've clicked the button, so disable the selection highlight effect on the button.
  CSS rule to disable text selection highlighting for better UX

• A page with code on it

  You want to copy the code, but not the line numbers, so disable the highlighting just on the line numbers.

• A site where you can drag the pages horizontally to navigate.

  If you allow the user to select the text, then the navigation gets really tricky.

  However, if you have such a site, don't put the content on it. Because a rich-text content need to be selectable.

A good solution here would be to create a title site which is able to be dragged horizontally to the next title page. To display the content, you need to press a button and proceed to the content page.

You also talked about the "app experience", and yes it is true, you can rarely copy text. What I personally find really annoying is when an app doesn't let you copy or highlight content at all; for example, posts in the Facebook app—it does let you copy an entire comment responding to a post, but again, won't let you highlight individual words.

You need to decide if you want to disable the highlighting. If the text-highlighting doesn't harm the usability (e.g. horizontal dragging), then I wouldn't disable it, especially as desktop users are used to be able to copy text.

Better: enhance the experience of text-highlighting.

Medium.com give you multiple options, what you can do with the highlighted text:

Just think about what the user will do with your text. Support the user with their needs.

However you can also make it worse, like Google Fonts:

Answer 3

There are such people as "selection readers". I am one of them. I (for some reason consciously unknown to me) have a tendency to select text while I'm reading it. Sites that stop me from doing so make me very sad and mess up my user experience.

I also completely disagree with the point in what is currently the top answer. Those things that pop up whenever you select something also seriously annoy selection readers.

Stop trying to make things app-like! My computer is not a phone! I don't want to be limited to only the actions I can perform on a phone when using your site!

Further reading: https://devblogs.microsoft.com/oldnewthing/20150528-00/?p=45014

Answer 4

Not being able to select text is the most annoying anti user-friendly CSS property there is right now in modern websites.

Reasons:

• Let's not try to act as if our website is something it isn't. It's not a mobile app and the reason you cannot select text in an application is because it is not inside a text-box and therefore is not supposed to be selected for a reason.
• The mobile ecosystem is completely different than the "power user" PC system. Most people that use websites on their computer want to get work done - or do practically anything they couldn't do on their mobile device due to the FREEDOM the mouse and keyboard gives them.
• I can't see any reason why someone would restrict someone from copying some text. If you are going to be that annoying and restrict me from doing that on the user level, I will simply dive a bit into the HTML code, copy what I need and NEVER USE YOUR WEBSITE EVER AGAIN.

I know this is a bit over-dramatized - but please don't do it.

edit: This does not mean that having buttons or labels with text that has no actual reason to be copied with that property is false, it is actually desirable.

Answer 5

There are many contexts in which it is good UX, and many where it is bad UX - there's no one-size-fits all answer.

As you flag in your question a button or action that when clicked highlights the text isn't good UX, and there are likely to be very few circumstances when a user should need to highlight that text.

However bodies of text shouldn't be disabled - if there's an interaction that causes that text to be highlighted then it may need to be reconsidered - as it's clearly not appropriate for the medium.

And as stated elsewhere, you should never disable highlighting of all the text. If you're going to do it it should be very selective (buttons, basically).

Answer 6

Messing around with standard application features (eg selecting text in a browser) is a bad idea in almost every instance ... the user expects to perform whatever action they've done. They can't, because you've broken it - ergo you've failed to meet user expectations. Simple as that.

Personal rule of thumb:

• In all cases, disabling highlighting of text is incredibly silly. Even if you think that nobody will ever want to highlight it, you never know. You'd be surprised what people get up to.
• Disabling highlighting when highlighting in some way breaks the UI is a good thing. Rare, but it can happen. 'Breaks the UI' might be things like
  • allows you to scroll when you shouldn't be able to
  • gives the user a false impression (eg that they can do something that's impossible)

Answer 7

There is just one context where I found this a useful feature, and that was in the context of a game.

I had a playing area the player was interacting with using the mouse. On that playing area were objects with text labels. Sometimes the player meant to click an object, but marked the text in the label instead. This was bad because it was not what the user wanted to do. Setting user-select: none on the text labels fixed the issue. This was a good idea.

Answer 8

If I'm working alone, I like to disable it by default and enable it selectively.

I I think selecting a menu item's text or a button title doesn't add much value to the final product and sometimes user interactions might corrupt the design by adding strange backgrounds to text nodes. (Maybe there's a usability side I'm not aware of?)

The only case I can think selecting text might be useful is when there's informative text, like on a document or magazine, or the purpose of the page is to present text.

However, when working on a team, I think this is not okay, as it overrides the default way a browser delivers a page, and new team members need to know beforehand unnecessary information that might cause bugs? (I can't think right now of bugs that might be cause by this property).

As every feature, if you take care of it, and you know what you're doing, there shouldn't be unsolvable and critical issues.

Answer 9

For me, I found the following rule cover 99% of the cases.

div {
  user-select: none;
}

This single rule instantly improved my web application. Obviously, I need to go through the UI and test it. And it worked like a charm!

It does not affect input, p, textarea. So, it especially helpful when you use semantic approach to html tags.

Also, you need to be extra careful when showing data pieces, not just UI labels, as data pieces should be selectable in most cases.