Implementing extensions on top of the JS reference implementation

Implementation
1

Hey all,

I’ve been doing a bit of preliminary research into what it would take to get support for strikethrough added to my favorite chat application. There is an open issue but it is stalled, stating that it is a limitation of CommonMark. Following that thread landed me at this topic. I’ll be the first to admit that I was sharpening my pitchfork (so to speak) at the beginning of the topic, but by the end I was persuaded by the arguments - strikethrough does not (yet) belong in the CommonMark specification.

Of course, I still want support for strikethroughs (primarily to indicate that a message is no longer accurate while avoiding the confusion of a message disappearing completely), so what is the best way for a consumer of the reference implementations to add extensions? In thinking about this, I came up with two fundamental strategies:

  1. Make use of the parser/renderer split to do custom processing on the AST before it is rendered
  2. Add some configuration to the parser to allow it to do simple substitutions before returning the AST

The first strategy works today and has the additional advantage of being able to implement more complex extensions (e.g. tables). The second strategy would need modification to the reference implementation, but it would allow folks to easily add support for “simple” extensions like strikethrough (~~ → <del> or <s>), diff (-- → <del>, ++ → <ins>), GFM task lists, and disallowed HTML.

I see a number of topics asking for support of various extensions and the discussions all seem to end up taking the same shape: some are arguing that a particular extension should be included in the core specification while others are defending where the line has been drawn. I can certainly empathize with both positions and wonder if the second strategy might be a good way to reduce this pressure on the community - frequently requested extensions can be enabled with a single line of configuration to the parser.

I haven’t looked through the JavaScript implementation yet, so there may be technical considerations (e.g. performance) that render this second strategy unworkable. I’m curious to know what folks think about this approach though. Is this appropriate for the reference implementation? Is it technically feasible?

1 Like