100

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?

  • 5
    Where are you using this CSS property? If you are doing <div class="company_address" style="user-select: none"><!-- address info here --></div> then you are guaranteeing that people will not willingly return to your website. @topher I too ponder the same question...Massachusetts Bar Association? – MonkeyZeus Aug 18 '15 at 13:03
  • 8
    With things like this I like to apply the thought exercise of worst case impact. If someone wants to select the text but can't is that worse than a user who didn't want to select the text but does so accidentally? User A obviously has a reason for wanting to do it, and you're preventing them from doing so, and they have no alternative. User B has accidentally done something that is easily reversible. – JonW Aug 18 '15 at 13:12
  • 40
    Opinion time: If you stop me from selecting text in a situation where I expect it to to work, I generally assume you're up to something fishy. Same as if I'm stopped from copying or pasting - I take any breach of the normal UI rules as evidence that the website is trying to pull a fast one on me. – Michael Kohne Aug 18 '15 at 18:32
  • 28
    @MichaelKohne ... and then being a programmer I fire up my browsers debug mode and copy the text I wanted before departing. Never to voluntarily return. – Dan Neely Aug 18 '15 at 21:19
  • 9
    Relevant. – Kaz Wolfe Aug 19 '15 at 2:25
103

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.

  • 16
    +1 All points are good, but particularly preserving the ability to copy messages from "error" messages. – TripeHound Aug 19 '15 at 15:58
  • 7
    That "What about protecting my content from people who will copy it by selecting it!?" section is so beautiful. Registered on this SE community just to upvote it. – mirichan Aug 21 '15 at 7:55
  • 6
    "Some people would argue that (some) mobile applications have removed the degree to which [copying text] is a standard interaction" - I would argue that, when they do this, it's infuriating and is one of the reasons I always assume that (until proved otherwise) a website's app will be a worse experience than simply using their website. Same with other common interactions like zooming (obligatory xkcd cartoon) – user56reinstatemonica8 Aug 21 '15 at 9:52
  • I like to think of this example as one of the more useful browser interactions that this rule disables. – Octahedron Aug 21 '15 at 19:52
  • 2
    Additional note: user-select: none; is also useful when using the <canvas> tag. Sometimes you are implementing drag-and-drop functionality to your game and it suddenly selects everything on the page. I'm looking at you, Windows. – Tiago Marinho Aug 23 '15 at 6:07
69

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:

  • 5
    "Just think about, what the user will do with your text. Support the user with their needs." Nice and succinct. – Nathan Hornby Aug 18 '15 at 13:02
  • 12
    I disagree, that Wild As Hell website to me just felt like a big ad... not something I'd show my friends, relatives or even want to visit very deep. – insidesin Aug 18 '15 at 13:35
  • 20
    Upvote for the Googlefonts gif - I've had that exact issue many times, disabling a feature for the good of everyone is one thing, but hijacking a feature I find quite distasteful (ask me about hiding scrollbars, I dare you!) – Nathan Hornby Aug 18 '15 at 14:25
  • 13
    Pro tip: For Google Fonts (and other places that do the same thing) you can press Ctrl+C to copy the highlighted text before letting go of the mouse. – Ajedi32 Aug 18 '15 at 18:51
  • 10
    Please no text highlighting context menu, please no no... They are very very annoying! As you can see in your example I have no more chance to read the text under the context menu. Happens to me every time! – Preexo Aug 19 '15 at 7:59
32

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: http://blogs.msdn.com/b/oldnewthing/archive/2015/05/28/10617693.aspx

  • I do this too. However, nothing bothers me more than selecting some text and having seemingly unrelated divs also selected. I prefer to have those elements only disabled from selection. – Thane Brimhall Aug 21 '15 at 17:46
  • I do that too. But I like the popups (medium.com). They overlay the text which I already read. And so on, it don't bother me at all. But I like your 3rd sentence. +1 – Michael Schmidt Aug 22 '15 at 6:35
  • I also perform selections while reading, many times in order to use it as a bookmark. So for instance if I at this point I wanted to read again some point in the question or a previous answer, I may select the point I was reading, so I can easily scroll back to it (a pity that the browsers don't provide a better solution). +2 for the third paragraph. – Ángel Aug 23 '15 at 22:21
  • 1
    I hadn't thought of that and I'm glad you raised it. It's possibly an accessibility issue for some. – Brody McKee Aug 24 '15 at 7:01
15

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.

  • 8
    There are very good reasons to restrict someone from copying some text. In javascript heavy applications other elements than input/buttons can be used for interaction (native input/buttons are already text-un-selectable, try to select the text on the "Add Comment" button on the right side). Clicking one of these "custom" interactive elements will in some cases select the text as well as be interacted with, and this text-selecting-behavior can cause confusion to the user. – Bluewater Aug 18 '15 at 9:25
  • im only talking about text , not buttons or labels obviously. why would someone copy the text inside a button? – downrep_nation Aug 18 '15 at 9:26
  • To recreate a button behavior, you use the css "user-select: none" My vote is now locked, but I agree on your point that the page in general should not have "user-select: none" on default. – Bluewater Aug 18 '15 at 9:28
  • 7
    There are too many assumptions (some of which demonstrably false) in this answer I'm afraid. And it's not over dramatised, just horribly subjective. – Nathan Hornby Aug 18 '15 at 13:05
  • 8
    @downrep_nation "im only talking about text , not buttons or labels obviously. why would someone copy the text inside a button? " They wouldn't, which is exactly why you might disable it to prevent accidental highlighting with this CSS rule… that's the question! – Nathan Hornby Aug 18 '15 at 13:07
9

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

  • my apologies,caps isnt shouting, also i noticed it says should be able to select any instead of shouldn't be able to select any. sorry i lost context there. – downrep_nation Aug 18 '15 at 14:10
  • I knew you'd get there in the end :) But it's an important distinction, so I wanted it to be clear. Especially as I agree that you shouldn't disable highlighting for all the text. – Nathan Hornby Aug 18 '15 at 14:11
  • still a bit early here, gotta warm up my brain - delete your replies to me so noone missunderstands the comments – downrep_nation Aug 18 '15 at 14:12
  • Mate, mine rarely warms up at all - no judgement here :) – Nathan Hornby Aug 18 '15 at 14:12
5

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)
1

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.

  • But is it a good or bad idea? This is what OP is asking for. Please edit the answer and try to answer the question. Thank you. -1 – Benny Skogberg Aug 21 '15 at 11:11
  • @BennySkogberg I thought that it was pretty obvious. I still made it even more obvious. Can you understand it now? – Philipp Aug 21 '15 at 11:19
  • Nice! Now even I understand what you mean! Thank you :-) – Benny Skogberg Aug 21 '15 at 11:27
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.