This is useful in situations where you want to provide an easier/cleaner copy-paste experience for users

Turns out it’s also useful for Facebook who use it as a #darkpattern to block copy/pasting of Facebook posts when not logged in >:(

But you can use pointer-events: none.

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.

Sorry, I meant Chrome 53+, and Opera 40.

…should be…

-webkit-user-select: all; /* Chrome 50+ */

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.

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.

Seems like “user-select:none” does not work in Android Browser prior to version 4.1
But i’ve not found any official proof for that.
I’ve tested this example http://jsfiddle.net/u88wbh10/4/ in different versions of Android Browser:
Samsung mobile device with android os 4.1.2 – works.
SE Xperia mobile device with android os 4.0.4 – does’t work.
Both android versions have the same version of webkit built-in.
There are several threads on the stackoverflow pointing to this issue. For example: http://stackoverflow.com/questions/5107651/android-disable-text-selection-in-a-webview
Although the MDN & canisue.com shows the support for “user-select” from the android 2.1:
https://developer.mozilla.org/en-US/docs/Web/CSS/user-select#Browser_compatibility
http://caniuse.com/#search=user-select
Anyone experienced the same problem?

…
PRE and CODE cannot display literal carat symbols. Element tags for carats are hand-coded &lt ; ‘<‘ left carat and &gt ; ‘>’ right carat.
…

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.

…
pre { counter-reset: line; white-space: pre-wrap; }
code { counter-increment: line; }
pre code:before { content: counter(line); margin-right: 3rem; pointer-events: none; }
pre code:before { -webkit-user-select: none; -moz-user-select: none; -ms-user-select: none; user-select: none; }

pre { counter-reset: line; }
code { counter-increment: line; }
code:before { content: counter(line); user-select: none; }

…

.item a.nevermind-x:before {
  content: "\2715";
}

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.