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.

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

• Anonymous
  January 11, 2012
  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.

• Anonymous
  January 11, 2012
  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).

• Anonymous
  January 11, 2012
  Thanks , This blog is turning out to be a great resource of learning new Web Based technologies

• Anonymous
  January 11, 2012
  I can see this property getting misused soon.

• Anonymous
  January 11, 2012
  <sarcasm> Great to see the standards at work, ensuring that the same markup has the same effect in all browsers! </sarcasm> 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.

• Anonymous
  January 11, 2012
  @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>.

• Anonymous
  January 11, 2012
  @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.

• Anonymous
  January 11, 2012
  The comment has been removed

• Anonymous
  January 11, 2012
  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.

• Anonymous
  January 11, 2012
  The comment has been removed

• Anonymous
  January 11, 2012
  Nice, how about webGL now? Maybe emulate it using DirectX?

• Anonymous
  January 11, 2012
  @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 @microsoft 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.

• Anonymous
  January 11, 2012
  "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?

• Anonymous
  January 11, 2012
  @Martijn Bingo. I thought that was very clear. @todd you're right, no one uses accelerators, mostly because no one uses IE @microsoft you should implement a property to add "no-right-click" without javascript. that's what most of us want isn't it?

• Anonymous
  January 11, 2012
  @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.

• Anonymous
  January 12, 2012
  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.

• Anonymous
  January 12, 2012
  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.

• Anonymous
  January 12, 2012
  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. Harry

• Anonymous
  January 13, 2012
  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...

• Anonymous
  January 13, 2012
  « 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. @todd: There are certainly accelerator users, just like there were people using of the infamous IE6 image toolbar (OK that was mean but SCNR).

• Anonymous
  January 14, 2012
  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?

• Anonymous
  January 14, 2012
  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.

• Anonymous
  January 16, 2012
  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.

• Anonymous
  January 16, 2012
  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.

• Anonymous
  January 16, 2012
  @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.

• Anonymous
  January 17, 2012
  If you think this won't be abused your dreaming.

• Anonymous
  January 18, 2012
  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.

• Anonymous
  January 22, 2012
  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?