Subscript and strikethrough compatibility

[chillbram]

Description

I was working on an extension to supersede the sup-sub extensions, which haven't been updated for 5+ years and don't support Commonmark v2. These render subscript and superscript when delimiting text with ~ and ^ respectively.

I got everything working, however when testing compatibility I ran into troubles when using both the sub tag (~) and the official strikethrough extension from this package (~, ~~). As this extension also supports strikethrough with just one tilde, an error is thrown due to the now ambiguous rendering rules.

When disabling support for single tilde strikethrough, the simple use cases can now be fixed. However, nested tags still cause trouble (e.g. x~sub~~strikedsub~~~ which should show x<sub>sub~~strikedsub~~</sub>, but instead show x<sub>sub</sub><sub>strikedsub</sub>~~). I had a look at how you guys implemented emphasis (*, ** and _, __) which has the same ambiguity problem and that solution of combining two rules into one seems like the only way to prevent similar issues.

Example

Just thinking out loud, here are some options to allow both sub tags and strikethrough to work together:

1. Strikethrough no longer supports the single tilde (~). This would technically break the Github Flavoured Markdown spec and also cause backwards compatibility problems.
2. We add a configuration option to allow users to set the behaviour of option 1. This would give users the freedom to knowingly break the spec to instead gain simultaneous sub and striketrough support. This is much better with regards to backwards compatibility and expected behaviour. This does not support combining strikethrough and sub tags.
3. Sub (and less relevant sup) get implemented into this package. This still requires a decision for either option 1 or 2, but allows us to also implement a similar delimiter length logic as emphasis. It does, however, implement the (albeit quite frequently used) ^ and ~ characters which are in neither the Commonmark nor the GFM spec.

Option 3 would seem ideal to me as it would allow solving the nested problem, although I would understand if supporting something outside cmark or gfm is something you're not willing to do. Option 2 would still be great as it would at least support the basic usage of both extensions.

If any of these options are agreeable, I'd be willing to draft a PR to implement it.

Did this project help you today? Did it make you happy in any way?

Thanks for all the great work on this package :)

[gaufde]

It would be great if we could get some clarity on this! I'd love to have superscript and subscript support in CommonMark.

@chillbram you end up writing a solution for yourself?

[chillbram]

The options I provided are still on the table should @colinodell give their blessing to one of them.

In the meanwhile we have opted for supporting the <sup> and <sub> HTML tags in markdown. With our own extenstion that still works even when escaping/stripping all other HTML input. So not ideal that we have to use HTML in Markdown but it works for us.