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
Anonymous
February 04, 2015
The comment has been removedAnonymous
February 04, 2015
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.Anonymous
February 04, 2015
@Brian - does your functionality work with IE11? Which specific functions are you concerned about IE removing?Anonymous
February 04, 2015
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.Anonymous
February 04, 2015
Brian, I did something similar to you - but elementFromPoint isn't an "old IE method", it appears to be supported everywhere... developer.mozilla.org/.../document.elementFromPointAnonymous
February 04, 2015
@Brian - thanks for the feedback. I will look into doing it in a future release. It was previously tracked on Connect at connect.microsoft.com/.../693228. I will reactivate that bug as well so we can track this there.Anonymous
February 04, 2015
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 :)Anonymous
February 04, 2015
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.Anonymous
February 04, 2015
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.Anonymous
February 04, 2015
In the Links section there is still a link to "Exploring IE"! This link leads to windowsteamblog.com/.../ie and is DEAD! As I have already previously reported: please remove this link!Anonymous
February 04, 2015
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.Anonymous
February 04, 2015
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.Anonymous
February 04, 2015
@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.Anonymous
February 05, 2015
@Andrew, 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.Anonymous
February 05, 2015
@Š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 w3c.github.io/editing-explainer. 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."Anonymous
February 05, 2015
英語わからんので日本語で失礼します。 IEにまた脆弱性が見つかりましたね。 来週のパッチ、何とか間に合わせて下さい。 いつ攻撃起きてもおかしくないそうです。 少なくともWin7＋IE11はやばいのでしょう。 あと良く落ちるバグも直してほしいなと…。Anonymous
February 05, 2015
The comment has been removedAnonymous
February 06, 2015
@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.Anonymous
February 11, 2015
The comment has been removedAnonymous
February 13, 2015
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!