How Rangy Differs From Native Apis

How the Rangy Range and Selection APIs differ from native browser APIs

Rangy implements the DOM Level 2 Range specification, the draft WHATWG Selection specification (formerly part of HTML5) and existing browser behaviour as closely as possible. However, while you can usually use exactly the same code with Rangy Ranges and Selections as you could with with the native APIs of standards-based browsers, there are a few key differences that prevent this always being the case. This page lists these differences.

Ranges

Range objects do not update when the DOM is changed, except when it is a Range method doing the changing

This is the major stumbling block. The DOM Level 2 Range specification does (mostly) specify what should happen to a Range under DOM mutation and browsers do implement it. However, without DOM mutation events (which are absent in IE <= 8), it's simply impossible to detect all DOM mutation and therefore impossible for a Rangy Range to update itself in response to DOM mutation. Therefore since one goal is to provide the same functionality in all supported browsers, Rangy makes no attempt to follow this aspect of the specification.

None of the properties of a Range object throw an exception when assigned to

Simple solution: do not attempt to assign a value to a Rangy Range property (startContainer, endContainer, startOffset, endOffset, commonAncestorContainer and collapsed), since it's not legal anyway.

Properties of a detached Range object throw no exceptions when accessed

This is also simply solved: do not attempt to interact with a detached Range.

Selections

The Selection object is not yet standardized but there is a lot of common ground between non-IE browsers that Rangy's Selection object implements. However

TO BE COMPLETED