I feel like it's not been that long ago that I ran into trouble with "standard xterm escapes". As I recall, there are a lot of those, and many of the more interesting ones are at best very unevenly supported across terminals. The last such experience is in fact what led me to avoid doing anything more complicated in a terminal than basic colors and a few emoji.
That said, if your terminal support is as good as advertised, it probably shouldn't be hard to surface that on your site. (If you really want to sell me on it, let me try it out in a web-based terminal emulator like xterm.js! Then let me package up that test script for download, so I can easily run it locally in my terminal, as many of them as I like, and see for myself how well it works there.) Maybe also include feature coverage in your test suite and even CI, although that's definitely a trickier engineering problem.
As it is, I'd be very hesitant to use the library since doing so would risk incurring a dependency (on the user using a supported terminal) that wouldn't be easy to characterize more closely than "I tried this in xterm, y, and z and it worked, but if it breaks for you I'll have no immediate idea of why, and I'll have to choose between #wontfix and losing velocity on feature work."
I have been using textual extensively inside Visual Studio Code which uses xterm.js behind the hood [1], so far everything except hyperlinks works flawlessly, and hyperlinks don't obstruct anything either, it just shows as plain text. All 256 tests pass on my machine and the coverage based on lines of code is 42%, but you have to keep in mind that this project is still in beta [2] so that number is going to change
Also since the project is based on rich from the same author, some of the terminal features are from rich and the test coverage on that is 99% [3].
Yeah, that's fair. The perils of reading code on a busy Sunday, I suppose - I didn't get as far as noticing that Textual has basis in a much more heavily used and tested library, and that definitely changes my evaluation.
That said, if your terminal support is as good as advertised, it probably shouldn't be hard to surface that on your site. (If you really want to sell me on it, let me try it out in a web-based terminal emulator like xterm.js! Then let me package up that test script for download, so I can easily run it locally in my terminal, as many of them as I like, and see for myself how well it works there.) Maybe also include feature coverage in your test suite and even CI, although that's definitely a trickier engineering problem.
As it is, I'd be very hesitant to use the library since doing so would risk incurring a dependency (on the user using a supported terminal) that wouldn't be easy to characterize more closely than "I tried this in xterm, y, and z and it worked, but if it breaks for you I'll have no immediate idea of why, and I'll have to choose between #wontfix and losing velocity on feature work."