This is useful in situations where you want to provide an easier/cleaner copy-paste experience for users (not have them accidentally text-select useless things, like icons or images). However it's a bit buggy. Firefox enforces the fact that any text matching that selector cannot be copied. WebKit still allows the text to be copied if you select elements around it.

You can also use this to enforce that an entire element gets selection:

Otherwise, if the computed value of user-select on the parent of this element is all, the computed value is all

Otherwise, if the computed value of user-select on the parent of this element is none, the computed value is none

Otherwise, the computed value is text

In other words, it intelligently cascades and resets to a sensical state. It looks like maybe this feature could be used to make pseudo elements selectable, but no final word yet.

Older/Proprietary

Firefox supports -moz-none, which is just like none except that it means sub-elements can override the cascade and become selectable again with -moz-user-select: text; As of Firefox 21, none behaves like -moz-none.

Internet Explorer also supports a so-far-proprietary value, element, in which you can select text inside the element but the selection will stop at the bounds of that element.

The pointer-events property allows for control over how HTML elements respond to mouse/touch events – including CSS hover/active states, click/tap events in Javascript, and whether or not the cursor is visible.

Although Firefox, Chrome and Safari support it all through, the implementations are slightly different, in Firefox, when one does mousedown on the given element and drags along it to copy text, the cursor remains default type (i.e if it was originally cross-hair it remains cross-hair during the drag, if it was pointer, it remains pointer), whereas in Chrome and Safari, the cursor turns crosshair during the drag, whatever be the original cursor type declaration for that element.

Also worth noting, -webkit-user-select causes major hang ups in the current version of safari. After including it on a basic page I was able to make safari freeze by clicking the mouse 6 times in a row.

In Firefox, this property value affects the element’s children and therefore you will not be able to select them either. Even manually overriding the children’s CSS properties will not allow you to select them.

If you wish to manually override the children’s selection, then you must use the property value “-moz-none” instead of “none”.

I’m curious in an app setting, would it be frowned upon to set this to none universally, and then enable it for areas that makes sense to be selectable (a body of copy, copy/paste interfaces, etc…) For me, it seems it could make the experience a little more seamless if someone Cmd/Ctrl-A’s inside the page, or drags too long unintentionally.

The comments are indeed unselectable, if I try to select them. Thanks for the trick!

BUT, when I select several lines (the commands) it DOES highlight also the unselectable parts (the comments), althgough the comments are actually NOT selected (as we see when copy/pasting). It is a visual glitch, which is misleading for the user.

Does anybody have any trick to disable highlighting of unselectable text?

what if, I want to make the text really unselectable (not even by source)?
Actually I want to display a very long code but I want it to be unselectable, so that other users are unable to copy it. they can just ‘view’ it.

1The -webkit-touch-callout property allows you to dictate what does or doesn’t happen when a user taps and holds on a link on iOS. The default value is default and tap-holding on a link brings up the link bubble dialog; by using the value of none, that bubble never comes up.
2The -khtml prefix predates the -webkit prefix and provides support for Safari 2.0-
3The -moz prefix is defined twice with the value none and the value -moz-none on purpose. Using -moz-none rather than none prevents elements and sub-elements from being selectable. However some older browsers like Netscape won’t recognize moz-none so it’s still necessary to define none for them.
4**Don’t forget, non-prefixed property should be last in line.

I have pages with a lot of user-created text. Users often want to “select all” to paste into email, etc. The text they want is across several long “contenteditables” (think Google Doc but multiple docs in on eweb page). “Select all” makes the most sense, since select and drag makes you have to scroll a lot and also the selection stops when you reach the boundary of the contenteditable.

But “select all” also selects the “chrome” of the page (nav, etc.) which they don’t want.

You’d think this “user-select” would be what I want, but the way it works (FF at least) is that “select all” selects the user-select:none text.

I suppose there is a danger of making it too easy for the devs to make it too hard for users to select text. Still, it might be a nice thing if we could figure it out.

I have a UI with rows of content that have “buttons” in them too, and I was trying to prevent the buttons from having their text copied too, when people tried to copy the content. What I did was change the text I didn’t want selected from being part of the element to being created by a css :before pseudoelement. It worked like a charm!

Hey gang, CSS ‘pointer-select: none;’ has exactly the same behavior, where selection of anything before or after ‘select none’ tag content enables selection of all content in the selection area. There is a cmd processing hack here (somewhere), something CSS-Tricks should be able to bring to light: the parent selection must be made to react in a certain way to the child ‘select none’ element. Prettify.js (“google.code.prettify”) handles this sort of focus management nicely. HTML/CSS workaround?

The display reflex for select-none behavior is almost identical. Attach pointer-events to parent PRE, and attach user-select to child CODE (each line a separate CODE tag) and parent selection happens with outside drag in/across. Cmd-based interference, with nothing outside visibly selected, paste selection reveals inclusion of last pre-PRE character invisibly included in copied selection. Behavior of counter and code is as not selectable from inside PRE or attributed CODE counter. Therefore, the google prettify.js uses attribution in some way as our missing hack would. Which will be another blog post, here at CSS-Tricks.

Basically a DRM feature, I’ve just found a site abusing this. All the crud on the page can be selected, but nothing in the article. I want to view a bit of the source to see how their web2.0 malware works, but found they are hindering that.

FF, and all the modern browsers, are just proprietary application delivery platforms. And for that reason they suck in ways that Windows does. The user should be in control, sites should not be able to do stupid things without the user specifically allowing it.

There are tons of valid non-DRM use cases for this feature. In my personal case building a custom WYSIWYG editor. Being able to control user selection is an application level feature needed for the types of rich apps being built today.

Unfortunately, there it still isn’t standardized to a high degree across browsers. Especially when contentEditable becomes involved.

Submit a Comment

Posting Code

You may write comments in Markdown. This makes code easy to post, as you can write inline code like `<div>this</div>` or multiline blocks of code in triple backtick fences (```) with double new lines before and after.

Code of Conduct

Absolutely anyone is welcome to submit a comment here. But not all comments will be posted. Think of it like writing a letter to the editor. All submitted comments will be read, but not all published. Published comments will be on-topic, helpful, and further the discussion or debate.

Want to tell us something privately?

Feel free to use our contact form. That's a great place to let us know about typos or anything off-topic.