Differences in popular markdown parsers

Meta
1

There are a lot of implementations of “markdown”. Some claim to comply with Gruber’s original specification or testsuite, others target Commonmark conformance or are said to be compatible with GFM, PHP Markdown Extra or another popular dialect.

I’ve asked several developers in GitHub issues whether they would consider documenting the differences of their implementation from Commonmark, especially those that try to be compatible with GFM now that GitHub is using an extended fork of @jgm’s reference implementation written in C, cmark. The responses have been underwhelming. Earmark has it planned at least.

We do have Babelmark 2 and 3 for comparing the results for small snippets. I wish we had automatically generated and updated reports for those engines run against the CM testsuite. This could both inform choices for changes to the spec as well as bug reports to implementers.

Sadly, setting this up goes beyond my capabilities. Would anyone else be interested and able to?

2 Likes
2

Ah, is this why many repos’ README.md headers now render like #Section one ?

The starting point is probably http://spec.commonmark.org/0.28/#why-is-a-spec-needed-, but it doesn’t attempt to tally which implementations have conflicting behaviour, merely notes the points that commonly diverge.

3

Hello, a while ago I started the “Markdown Can I use ___ ?” initiative / website to document what features you can use - see http://mundimark.github.io/markdown-can-i-use Very early stage - so far the response was - surprise, surprise - silence and the only feedback was don’t steal my content or something from a markdown processor author. Cheers. Prost.

1 Like
4

That’s close to what I have in mind, but with the focus less on extensions, more on interoperability of basic syntax; also note automation.

1 Like