Introducing the Selection API specification

Developers who build rich text editing experiences (such as email, blogs, wikis, etc.) are familiar with challenges supporting a diversity of browsers. Today’s browsers support different functions and have a range of bugs to work around. There is an effort to improve this situation at the W3C, where we are working on the future of web editing. Selection is fundamental to editing so we are prioritizing investments in more interoperable selection, paving the way for a better experience across the web.

To this end, we've been working with browsers and developers at the W3C to specify a Selection API, allowing developers to interact with the user’s selection consistently and predictably. With help from developers and other browser vendors, the document recently reached First Public Working Draft – the first step towards becoming a W3C Recommendation. This is a work-in-progress publication which we’ll continue to evolve with the community via the W3C public process. It will allow developers to have a simpler, more powerful and interoperable way to design the selection experience of their site.

As we’ve evolved this proposal, we helped ensure that it covered several currently used APIs so that it can be a reference for browsers and developers to use when building and using these APIs. In the latest preview builds of IE on Windows 10, several new APIs from the W3C spec are now available. These include containsNode(), extend(), setBaseAndExtent(), and collapse(). The definition for each of these methods can be found in the spec. We chose to add these APIs in IE because they are used across the web today, as well as being requested in feedback from developers on Connect. We’ve also received feedback requesting the modify() API and we are discussing how to specify it at the W3C. We hope to provide it in IE and Project Spartan in a future release.

If you work with selection experiences on your site, try these out in the Windows 10 Technical Preview and let us know via Twitter or Connect how we can continue to improve this area and make your life easier!

Ben Peters
Program Manager, Internet Explorer Platform

Comments (20)

  1. Ben says:

    IE still sucks and I will stick with Opera. Thank you very much.

  2. Brian LePore says:

    Maybe I'm just not familiar enough with this, but does this mean that support for caretPositionFromPoint may be coming? I have written a plugin to TinyMCE to make it easier to drag images inside of a contentEditable element (which is different front drag and drop) with a finger/pen, but the lack of support for caretPositionFromPoint made it quite difficult/buggy to accomplish. I actually think that the software will break in Spartan because we first use caretPositionFromPoint (spec/Mozilla approach), then caretRangeFromPoint (older version of the spec/webkit/blink approach), then a lot of handwaving using IE's old elementFromPoint/createTextRange/moveToPoint. So far this gave support in all major rendering engines, but I fear it will fail once Spartan removes older-IE code without adding standard methods available in other browsers.

  3. Ben Peters (MSFT) says:

    @Brian – does your functionality work with IE11? Which specific functions are you concerned about IE removing?

  4. Brian LePore says:

    I'm concerned that IE11 has been pretty good (as far as I can tell) with implementing Range and Selection. As far as I have seen IE11 (I have not checked the Win10 build in a while) does not implement caretPositionFromPoint, so I have had to revert back to the old-school TextRange object to make up for the missing functionality/parity.

  5. Andrew Herron says:

    Brian, I did something similar to you – but elementFromPoint isn't an "old IE method", it appears to be supported everywhere……/document.elementFromPoint

  6. Ben Peters (MSFT) says:

    @Brian – thanks for the feedback. I will look into doing it in a future release. It was previously tracked on Connect at…/693228. I will reactivate that bug as well so we can track this there.

  7. Å ime says:

    Seeing that getSelection() currently returns just the selected text (instead of a Selection object) in RemoteIE, I’m assuming that you’re re-implementing this API and that the new implementation did not yet land 🙂

  8. Mihai Lazar says:

    Will you guys remove the hasLayout property? We need to display data in two columns (side by side) and they need to have their height kept in sync.

    Setting height in IE when inside a contentEditable div, gives us a lovely textbox resize like experience.. which is not what we are after. FF and Chrome don't do this, only IE.

    At least give some option to disable it. We are maintaining the row structure ourselves, but the contenteditable spans over the entire column.

  9. Simon says:

    Regarding the future of web editing, I would much prefer that brower makers just let contentEditable die and don't try to resurrect it. Instead concentrate on lower level APIs which can be used to construct editors in general. i.e. APIs like clipboard support, APIs for mapping points to characters in #text nodes and/or elements, APIs for determining where exactly on the screen the browser has layouted out and flowed the HTML and text, robust support for CSS "white-space: pre-wrap", etc.

    A one-size-fits-all solution like contentEditable isn't going to keep anyone happy for too long, and people are expecting (and demanding) more from their editors, and as developers we need the flexibility to determine how each feature and interaction works. It is hard to explain to a customer that something is baked into the browser, works differently everywhere, and that we can't modify it for them. That is the contextEditable situation now.

  10. @ IEBlog says:

    In the Links section there is still a link to "Exploring IE"! This link leads to…/ie and is DEAD!

    As I have already previously reported: please remove this link!

  11. Believer says:

    Are these changes going to be part of the new Spartan browser? or you guys keep improving IE? I though IE in windows 10 was only to be there for enterprises that need to support legacy websites.

  12. Léonard says:

    You should emphasize each method in your article and even link each of them directly to the recommandation #methods section. I spent a little more time than I would have liked on actually looking for them.

  13. NumbStill says:

    @Believer –

    As explained in previous posts, Internet Explorer and Spartan will use the same EdgeHTML engine, so it should not matter to you.

    Internet Explorer will simply have more legacy features (like ActiveX, Browser Helper Objects) and perhaps document modes for legacy websites.

  14. Brian LePore says:


    Yes, you're correct about elementFromPoint being used elsewhere, but that is used in the work around for the issue of being able to programmatically place the cursor at a given point. It gets used with the other two features which were old, Trident code. I should have been more clear with that remark.

  15. Ben Peters (MSFT) says:

    @Å ime – I'm not aware of the issue you're describing. IE has supported the Selection object for getSelection() since at least IE10. Where are you seeing just the selected text?

    @ Mihai- I'm investigating that and I'll get back to you.

    @Simon- I agree that a one-stop solution is not the right answer! Check out the work we're doing at W3C at It includes a new paradigm and a broad list of use cases we hope it will cover.

    @Léonard- Thanks for the feedback. The link to the #methods section is where it says "The definition for each of these methods can be found in the spec."

  16. noname says:







  17. Tom says:

    @Ben Peters (MSFT), before implementing the standards, please consider seeing how others have done it and get out of your "box mentality": box-model, boxology, extra boxes with ugly outlines (for which we have to use reset.css).

  18. FremyCompany says:

    @Ben Peters: For the record, I've also production code relying on IE's selection stuff to emulate caretPositionFromPoint in IE.

    I also wonder whether the Selection API should have a "copyWithFormatting" function which would copy the DOM with style attributes matching the computed style of the walked elements. I would find that very useful in some cases.

  19. Tim Down says:

    getSelection() support started in IE 9.

    Regarding document.caretPositionFromPoint(), it's pretty easy to do since IE 4 with a TextRange. However, converting a TextRange into a Range is non-trivial. Examples:…/96100…/96100

    It would be a shame if TextRange was removed from future MS browsers before new APIs replaced its capabilities. 18 years after its introduction, other browsers still haven't got all of TextRange's features. Providing an abstraction for navigating modern HTML content as a stream of visible text is hard enough to prevent anyone from trying, so we get no equivalent of TextRange's move(), moveStart() and moveEnd() and everyone wants to kill window.find() (,, which is the equivalent of TextRange's findText() method. There is some text-the-user-sees-based manipulation in Selection.modify() but that would be more flexible if applied to Range or, if Range must remain ignorant of CSS, some other non-visual abstraction.

    IE 11 removed document.selection but kept TextRange,which has a select() method and can therefore affect the selection. This is inconvenient and seems bizarre. I'd be interested to know the rationale behind that decision.

  20. Ben Peters (MSFT) says:

    Everyone- why is there a concern that IE would remove some of the textrange APIs? I don't know of such a plan. Is there a bug in the current builds around these APIs that I don't know about? Thanks for the feedback!

Skip to main content