What is Rangy used for now?

[timdown]

Today I have published a new version with a fix for a security issue that people have been telling me about for nearly two years, which is clearly not good enough, and I'm taking stock.

I'm curious what people use Rangy for these days: to me, its main value was that the core brought DOM Range to Internet Explorer (RIP), and the rest of the modules were somewhere between experiments and overgrown Stack Overflow answers. The DOM has moved on somewhat but Rangy hasn't, so I'm not sure what value it has now.

I have been a very poor maintainer of Rangy for many years. I don't have cause to use Rangy in any of my work and don't work on side projects in my spare time now, so have been neglecting it, while still being unwilling to let go of control. My guess is that Rangy is a dependency in old codebases and all people really want is for it not to get flagged by automated tools as having security issues. If so, I am willing to commit to fixing any security issues that arise in a timely fashion from now on. If there is a desire for new features or modernisation, I'm willing to hand it over to new maintainers.

To summarise, what I'd like to know is:

• What is Rangy used for now?
• Is there any desire for new features or other major updates?
• If so, does anyone want to take that on?

[dkachurynets]

We didn't use Rangy directly in our project, but it was a dependency in some libraries we relied on. To address security issues with Rangy, we would have needed to stop using those libraries entirely, which isn’t always feasible or can be quite resource-intensive.

For example, in one of our recent projects, we used AngularJS along with the TextAngular library, which has Rangy as a dependency. While we recognize these are older technologies, we still needed to maintain them to avoid security risks. One of our InfoSec department's requirements was to address as many vulnerabilities as possible, so we paid close attention to keeping dependencies secure.

I believe others who encountered this issue might have been in similar situations, where Rangy's dependencies surfaced in legacy systems or third-party libraries, making it challenging to simply remove or replace it.

[marcbachmann]

We at Livingdocs used Rangy to reach Internet Explorer compatibility about 11 years ago.
Since some years we've also been using the native Range api in parallel as we've been aware that most things work out of the box with newer browsers. Finally we went through with the migration a year ago.

Replacing Rangy with the Native api is quite manageable, but requires deep knowledge in some codebases.

The helper functions of rangy were the most tricky ones as some didn't follow contenteditable offset conventions.

Companies with other priorities most likely can't react that quick and rewrite most parts.
In their case it would be good if they also get informed about the deprecation instead of just the security issues.

Getting explicit and clear is the easiest way to get the attention of people and companies.

For that I suggest you to deprecate the most recent version.
https://docs.npmjs.com/cli/v10/commands/npm-deprecate

[AntonOfTheWoods]

I have:

...
const sel = rangy.getSelection();
if (sel?.type === "Range" && !sel.isCollapsed) {
 doStuff(sel.getRangeAt(0).getNodes([Node.TEXT_NODE]));
}
...

Which is all I use it for basically. I have only been using it for about 4-5 years, so I guess I probably could have directly used the range API back then too. This does exactly what I want though, and having to dig into an API I have never had another use for would be... work :-)!

[Alex3917]

I'm using Rangy in production on fwdeveryone.com, in order to allow users to redact and highlight emails before publishing them on the web. The main thing I'm using is the classApplier module, which wraps text in a span element with a redact or highlight class. I don't know how difficult it would be for me to migrate this code to use the native selection APIs, because I've never actually tried, nor do I fully understand all of the edge cases that Rangy is actually handling for us. Right now it's not broken, so there is no obvious reason to fix it.

This is especially true since this module is lazy loaded, so even though there are some optimization bailouts that stem from it being common JS, as long as my build tools continue to allow me to import it there isn't any obvious benefit to having it modernized. (Right now I'm using Angular 18 in production, and the application is being built using the Angular CLI with esbuild.) That said, if build tools ever stop allowing me to import the library entirely then obviously it will be an emergency at that point. Hopefully it will be at least a few more years before this happens.

In short, while it would obviously be nice if Rangy were modernized to use ESM and drop the workarounds that are no longer necessary, it's also not an emergency until it stops working with my build tools.

[gabriel-felipe]

Similar here, I'm using mostly the classApplier, although it seems like it would be doable to use the native APIs it worked way better with Rangy module, my initial attempts didn't get all the edge cases properly when spanning over multiple elements.

[Reddine]

We are using Rangy in the Open Research Knowledge Graph. Back in 2019, we built an abstract annotator for research papers, and the Rangy selector instance was invaluable for supporting multiple browsers without having to manage the native API directly.

When users make a selection in the abstract, we use Rangy’s getSelection to create annotations for those selections.

For now, we have no plans to refactor the code to use the native API unless it becomes urgent.

[coredumperror]

I would like to migrate the wagtail-hallo project away from using Rangy and have it just use the native Range API, because the base project, Wagtail, dropped Rangy in the most recent version, which breaks Wagtail-Hallo.

Is there a guide for how to do this anywhere? I quick google didn't turn much up. marcbachmann's mention of needing "deep knowledge of the codebase" to be able to manage a migration is a bit intimidating, because wagtail-hallo is not my code. It's just that my code shop still needs it, despite it being long since deprecated by the original authors.

I'll do my best to figure this out, but if I can't, I hope folks here might have some advice.

[Masstronaut]

I use rangy for the ability to persist selection ranges. If a user highlights something, I want to be able to render that same content as highlighted for another session. Unfortunately the browser Range API isn't very conducive to serialization/deserialization.

[gschadow]

I don't personally use rangy yet, in fact only heard about it today, it was referenced in a NYT blog: https://open.nytimes.com/introducing-ice-writing-for-the-web-first-cddc9712f5b9. I remember years ago I was researching how to use contenteditable to make a WYSIWYG rich text editor and I remember to have read an article on that same NYT blog that concluded that it's hard and that the nested DOM model makes that even harder and what really was needed is to handle rich text as plain text + ranges with annotations.

Once I read that I had implemented my own algorithms for turning DOM into text + ranges (range-out) and text + ranges to DOM (range-in). I used that a lot but there is one nasty problem I haven't gotten around resolving completely yet, which is overlapping text ranges.

So today I came back researching the state of the art in rich text editing and read about ICE, and came to the NYT blog again and saw the rangy dependency. I am thinking of adopting their rich text editor.

[Masstronaut]

Rangy doesn't handle overlapping text ranges well in my experience. One example is if you have a range that starts in a paragraph and ends in the middle of a different paragraph (or a bolded section, or a link, etc.) it can't handle that.