Hacker News Reader

Comment by arriu | Hacker News Reader

One day these things won't be "selectable" to prove to us that they are HTML

Selection is probably not the best way to check whether something is browser content...

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

View on HN

Why does this parameter exist? What possible legitimate use could you have for disabling selection?

Any time you need the user to drag their mouse or double-click and don't want selections getting in the way. e.g. drag and drop

Fair enough; I hadn't even thought of someone wanting to drag-and-drop from/within a webpage. Thanks for the insight.

I've thought about this quite a bit. As HTML applications continue to evolve we should make them feel "appish". Things like selectable buttons take the user away from experience the app. Also graph labels shouldn't be selectable.

One of the big ideas of the web is selectable content. However UI elements shouldn't be included in this set.

I've written a little more about this (with some screenshots to illustrate my thinking) here: http://blog.dcxn.com/2012/02/29/selectable-elements-are-driv...

A simple example is an image-cropping system. The user has to click and drag. If you don't disable the selection and the user clicks in just a slightly wrong way they can end up selecting or dragging the image, which looks totally wrong for someone who wanted to select a region of an image. Both actions have the same user input (click, drag, release) but your intent is that it have a very different behavior than the browser default.

I travel a lot and have to use UIs in several languages, and being able to copy the text on button labels (or graphs!) to paste it into a dictionary is very important to me. On some sites I have to fall back to using the web inspector and it's just as annoying every time.

I disagree completely.

For the Github example, you want to disable selecting the file list header and, bizarrely, you tend towards disabling selecting the file list itself. Considering the files and their meta information are Github's content, disabling copy-pasting file names and commit messages is incomprehensible to me -- that's the last thing I'd consider disabling. And if I want to copy/paste the entire file list, I might want to copy the list header along with it for the benefit of the recipient. I wouldn't disable the selection on anything on your Github example.

The graph label example is just as strange. I tried the linked Morris.js example, and I can't select the label text. How is that a better user experience? What if I want to IM a friend the 2011 Q3 numbers? What if I want to search for similar data? Both quintessential web actions.

I think braking selection is almost as bad as breaking the back key, the cardinal sin of web apps.

If you are making a WebGL game, you do not want UI elements to select each time you try to rotate the camera.

I have used this property quite a few times for perfectly legitimate reasons. Any time that the user needs to click and drag to accomplish an action other than selecting text, you would want to use this.

You could do this for a long time by calling Event::preventDefault method on MOUSEDOWN event. This is just the same using CSS.

Obviously, this is useful for a lot of things, disabling selection being only one.

Games.

You don't want the user to accidentally drag your images all over the screen when he is trying to click on them (happens daily when I test the games I work on).

Yup, also you can use a css background-image rather than an html img tag.

But it definitely proves the positive.

Reply on news.ycombinator.com