Controlling Selection with CSS user-select

IE10 Platform Preview 4 includes support for a new CSS property, -ms-user-select, which makes it easier for Web developers to control exactly what text can be selected on their Web sites. If you were to watch me all day at my workstation, you would notice that as I read on the computer, I select text. I’m not the only one who reads like this; selecting text on the Internet is important in many other scenarios.

Consider a typical news Web site. Most pages will include a news article, the contents of which the user needs to be able to select because they read by selecting text or because they want to share the content. Also on the news Web page there are some menus and links to other parts of the site. Users likely don’t need to select these items. Using -ms-user-select, the Web developer can specify that text selection is allowed in the news article but not allowed in the menus.

The IE Test Drive site includes an example that does this.

Screen shot of the user-select Test Drive demo showing one possible markup pattern of -ms-user-select.

Setting -ms-user-select:none on the entire page and then setting -ms-user-select:element on the element containing the blog post allows only the contents of the blog post to be selected. -ms-user-select:element is a new property first introduced by IE which we think could be useful in many situations. Setting -ms-user-select:element means that the user can select the text of that element, however, the selection will be constrained to the bounds of the element. People who want to select the contents of a news article probably don’t want to select the footer elements just past the article. Setting -ms-user-select:element makes it easy for users to just select the contents of the article without having to worry about getting the mouse placement exactly correct.

-ms-user-select accepts four values:

  • text – the text is selectable
  • element – the text is selectable, constrained to the bounds of the element
  • none – the text is not selectable
  • auto – if the element contains editable text such as an input element or contenteditable element, the text is selectable. Otherwise selection is determined by the parent node’s value.

auto is the default value for -ms-user-select.

A developer can turn off text selection by setting -ms-user-select to none. In IE, when text is set to -ms-user-select:none, the user will not be able to start a selection within that block of text. However, if the user started selecting text on a different area of the page, the selection would continue into any area of the page including areas where -ms-user-select is none. In Firefox, if the developer sets –moz-user-select:none then selections can’t start in that area and also can’t be included in any other selection. In Webkit, setting –webkit-user-select:none will make it appear as if that the text is not included in the selection, however if you copy and paste the content, you will see that the content is included in the selection.

user-select was originally proposed in the User Interface for CSS3 module; this module has since been superseded by CSS3 Basic User Interface Module, yet it does not define the property. Both Mozilla and Webkit support their own prefixed versions of this property. However, as discussed above, there are some differences in the implementations.

Play around with the examples on the IE Test Drive site and let us know what you think.

—Sharon Newman, Program Manager, Internet Explorer

Comments (28)
  1. Bepo says:

    Interesting feature, certainly can be useful on the web. I just hope it will then also be used the right way (but lucky me knows how to some extend override annoying things on web pages).

    But I wonder if there couldn't be situations where the web developer would prefer to have it the way Firefox implemented it, though I can't think of any right now. I guess in the end IE's behaviour is better in protecting the user against web devs being potentially overambitious in that regard.

  2. alvatrus says:

    One might wonder why users select text without doing anything with that selection. It's just to guide the eyes when reading.

    A text might be marked unselectable because the author doesn't want to have the text copied and pasted to somewhere else.

    In that case, can the selection still have a visual appearance to aid reading, while making it clear that nothing can be done with this selection. (for example, the selection colour with a 50% opacity).

  3. Sunil says:

    Thanks , This blog is turning out to be a great resource of learning new Web Based technologies

  4. L. says:

    I can see this property getting misused soon.

  5. RichardDeeming says:


    Great to see the standards at work, ensuring that the same markup has the same effect in all browsers!


    OK, you're all still using a prefixed property, so it doesn't need to be exactly the same, but with such drastic differences between major browsers, even the prefixed versions aren't much use.

  6. Bepo says:

    @alvatrus: It should be made clear to any author that this property is not meant to prevent copying of stuff because the author doesn't wants it copied, <sarcasm> there are already alert boxes that open on right-click for that </sarcasm>.

  7. Bepo says:

    @L.: True, maybe this should be easily over-ridable by the user (menu? right-click? key combination?), so that web devs are less likely to succumb to the temptation of using it as something other than to help to the user.

  8. pmbAustin says:

    I have to say that I find selecting text in web pages to be consistently frustrating.  It just never behaves in a way that seems logical or user friendly.

    For example, imagine selecting the text in the example starting at the end and dragging to the top of the paragraph.   In many cases, you have to VERY CAREULLY AND ACCURATELY place your mouse cursor as close to the end of the text as possible, before dragging up… otherwise you either select nothing, or too much, or entirely the wrong thing.  Whereas in Windows, you can just place the cursor anywhere after the final word in the paragraph on that last line (in this case 'usability') and drag up, and it'll "do the right thing".  It just never seems to "do the right thing" on the web… or at least misses often enough to be a real pain.

    A forward-selecting example can be seen right in the comments of this page… try to start at the beginning and select a comment.  If the mouse cursor is just a hair too far to the left of the first word of a comment, suddenly the date — way over on the right and one line up — is selected as part of your text.  When is that EVER what the user actually wants to do?

    This is especially true if there are images the text is wrapping around.  I imagine at the source level there are various divs, but it's very frustrating to select what looks to be one logically continuous flow of text and suddenly find side-bars, and completely unrealted text ALL selected as you cross some "invisible boundry".  I'd really like to see some work done in correcting this behavior… having the select work more intuitively and naturally, based on the visible rendering of the page rather than the underlying structure.

    Am I making any sense?

  9. Joe says:

    Quote: " has since been superseded by CSS3 Basic User Interface Module, yet it does not define the property"

    Since the editor on that paper was from Microsoft, why was it removed and could somebody take the initiative to submit a new recommendation for a standard?  This is one area where it's easy to tell that you're running in a browser vs native, everything is selectable.  It should be fixed in a standard way.

  10. todd says:

    user-select:none; should not allow selecting of the text… at all… ever… that's how it was designed.

    The reason why developers are and have been using this in all other browsers is to stop users from accidentally selecting text on "tabs" and "buttons" rendered on the screen using CSS and links etc.

    In IE it has always been an issue, because a quick click and slight mousemove would select random text… and then to add insult to injury, shows the accelerator icon (which no one uses BTW).  The user being a creature of trying to control their environment then has to click elsewhere to get rid of the highlight and the icon.

    Thus the IE implementation that allows selection when the developer has requested that they do not… is just plain annoying… if the developer has decided that the default selectable behavior is undesired… why would Microsoft decide that when the user selects over it that for some reason it should switch from being unselectable to being selectable?

    Thanks for mucking up stuff before asking developers what they want.  While you are at it, can you make document.getElementById(id) return any checkbox that isn't checked… that would be really inconvenient too.

    SWEET MOTHER OF PEARL!!!! HOW COME THIS BLOG ALWAYS FAILS TO SAVE COMMENTS THE FIRST TIME!!! thank goodness non-IE browsers can save textarea content for you… must suck for IE users.

  11. woo says:

    Nice, how about webGL now? Maybe emulate it using DirectX?

  12. @todd

    I' am using accelerators, many times a day, so I think I'm not the only one.

    And most often when I have a problem on a web form or writing a post, clicking the back button gives me the text & selections back…

    Sorry for you not to benefit the same behaviour


    I am completely in agreement with pmbAustin : why defining "unselectable" pages/areas whyle we will allways find a solution to "copy" the text when needed : this is just widenning the gap between "standard" & "advanced" users, or encouraging the multiplicity of addins to do such simple things !

    If the only objective is to improve the selection behavior, just work on selection behavior !

    I'm sure web developers would appreciate not having to lose their time with this.

  13. Martijn says:

    "constrained to the bounds of the element" is not a very clear description, iyam.

    So to clarify, -ms-user-select:element means that if a visitor selects text within the applied element, the selection will not "bleed" into other elements (except children of course?). So you can't accidentally select too much, even though the entire page is selectable as always.

    Sounds right?

  14. Michael says:


    Bingo. I thought that was very clear.


    you're right, no one uses accelerators, mostly because no one uses IE


    you should implement a property to add "no-right-click" without javascript. that's what most of us want isn't it?

  15. Wesley says:

    @Michael: HTML text is transferred over HTTP to the client PC. You can do with the downloaded/transferred data whatever you want.

    It's not because you can't right click you can't copy content. Even a screenshot (CTRL+Printscreen) is copying content.

  16. says:

    user-select will be good feature when developers implement it properly.

    Hopefully, it will also be easy for users to override the user-select property when developers have implemented it poorly.

  17. In some ways this seems a nice feature, in other ways not so much.

    Particularly this concerns me because there will always be some scenario in which a user wants to select a particular piece of text on the page.

    Taking the news article example, usually users will be wishing to select the article text. However there are numerous scenarios in which copying the menu text may be useful, from writing up a guide to using the website, to bug reporting.

    This feature makes me think of the many many pieces of uncopyable text within Windows programs I've had to write out by hand, for explanations to friends and for bug reports amongst other reasons.

    As you plan this feature, please consider how painful uncopyable text can be for users.

  18. Harry Richter says:

    I don’t think that this feature will be abused too much, because developers will soon learn that this –being CSS – can easily be stopped by using the developer tools (F12) with the disable CSS feature there. I guess also the inferior browsers have something like this feature IE has, so for “protecting” content it is a no-starter.


  19. @Harry Richter says:

    Are you dumb or are you dumb? W3C decides which feature belongs to CSS and HTML not Microsoft and others! So they giving the developers "more control" over the content! There is no point in liking or disliking it…

  20. Nebu says:

    « This feature makes me think of the many many pieces of uncopyable text within Windows programs I've had to write out by hand, for explanations to friends and for bug reports amongst other reasons. »

    So true, like the text of the winver.exe dialog.


    There are certainly accelerator users, just like there were people using of the infamous IE6 image toolbar (OK that was mean but SCNR).

  21. Larry says:

    When will IE fully support open HTML5 Video and Audio? these are the two features we care about… are we going to see support in IE10 or will we have to wait until IE11?

  22. Alasdair King says:

    Many assistive technology programs (programs for people with disabilities, like blindness or dyslexia) use "copy selected text to the clipboard and speak/braille it" as a useful approach. This works very well in web pages. This feature will be used by website designers to disallow selection and copying of their text to "protect" it, which will be a significant problem for many of the AT programs.

    Ideally this CSS markup would not be applied to anything that isn't a UI element – that is, a button or input element. So no matter what the CSS says a user would still be able to select body text. The user should be privileged over the website creator, especially the user with a disability.

  23. commongenius says:

    Can someone from the IE team comment on the perceived use case for this feature? It can't be content protection, since we know there are plenty of ways to access content other than selecting and copying it.

  24. jader3rd says:

    I would love it if I could select the words in links. If I click and hold a link and drag to the right, instead of the text being selected, all I get is a circle with a cross through it. Just because there's a link behind that text, doesn't mean that I don't want to copy the text.

  25. ieblog says:

    @David A Nelson: As you point out, it's not about content protection; it's all about Web apps' user interface elements.

    Think of a Gmail, Hotmail, or Outlook Web Access. They have tons of UI elements implemented in HTML and selecting them just gets in the way of the app's intended task: reading and writing email messages. These apps today use the -moz- and -webkit- versions of these properties or go through convoluted event handling to prevent the selection of UI text.

    We trust developers to do the right thing with the Web platform features. This is simply another tool in the very rich HTML/CSS/SVG/JavaScript toolbox.

  26. toyotabedzrock says:

    If you think this won't be abused your dreaming.

  27. RP says:

    If you find it easier to read a site by highlighting bits, it seems self-defeating to give site creators the ability to disable that.  I realize this is just meant for menus, but why should the reader not have the right to select menu text?  What if a site has used an unusual word or name in their menu, and it's more than a few letters long or includes an unusual character?  Rather than retyping it, you might want to copy and paste that word into a search engine, email or IM to ask what it means.  Is that now to be prohibited?  This is as bad as letting site creators disable right click, or the way that DVDs are allowed to disable fast-forward – control is being taken away from actual users.

  28. @{!toyotabedzrock and other stew-pid jokers} says:

    Why did W3C include this feature in the specification in first place? Ask W3C talking heads for this wisdom or folly. Don't be foulmouthed here or any other vendor's blog. We expect browser vendors to deliver the "standard compliant" software.

    And hey! look at the following code:

    -moz-user-select: none;  

    -webkit-user-select: none;  

    -ms-user-select: none;

    When Mozilla and Chrome/Safari implemented it, did you guys complaint? Or is it just the way you guys (the typical trolls) show your grudge against MS?

Comments are closed.

Skip to main content