3 ms·

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 conte

• simonbrown 14y ago
  But it definitely proves the positive.
• gergles 14y ago
  Why does this parameter exist? What possible legitimate use could you have for disabling selection?
  • simonbrown 14y ago
    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
    • gergles 14y ago
      Fair enough; I hadn't even thought of someone wanting to drag-and-drop from/within a webpage. Thanks for the insight.
  • nixterrimus 14y ago
    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-driving-me-crazy-heres-how-to-fix-it/ http://blog.dcxn.com/2012/02/29/selectable-elements-are-driv...
    • Periodic 14y ago
      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.
    • kalleboo 14y ago
      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.
    • morsch 14y ago
      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.
  • arriu 14y ago
    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.
  • deno 14y ago
    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.
  • tomjen3 14y ago
    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).
• tterrace 14y ago
  Yup, also you can use a css background-image rather than an html img tag.