CommonMark gave an ambiguous format a strict specification

An implementation, not a specification, had been the reference

The CommonMark project's own account of its origin does not flatter the original Markdown. It states that 'John Gruber's canonical description of Markdown's syntax does not specify the syntax unambiguously', so early implementers instead consulted 'the original Markdown.pl code to resolve these ambiguities' even though 'Markdown.pl was quite buggy'. Because 'nothing in Markdown counts as a syntax error', a document could render one way on one platform and differently on another without either tool reporting a fault. By 2014 the project counts 'dozens of implementations in many languages', each having resolved the same ambiguous cases its own way.

What the specification defines

CommonMark's response was a formal grammar plus a machine-checkable test suite, tracked as dated, numbered releases at spec.commonmark.org. The earliest version listed there, 0.5, is dated 25 October 2014; the specification has been revised regularly since, reaching version 0.31.2 on 28 January 2024, the version current as this is written. Each release ships its own JSON test cases, so a converter can be checked mechanically against thousands of input-and-expected-output pairs rather than against a human reader's judgement of whether the rendering looks right. That is the concrete thing a specification adds that a description cannot: a pass-or-fail result for a given piece of software, repeatable by anyone.

What a strict spec does not settle

A specification only helps if a tool actually implements it, and CommonMark is not the only dialect in circulation. GitHub's own flavour extends CommonMark with tables, task lists and automatic links; other applications add their own syntax for footnotes, callouts or embeds, none of which CommonMark defines. So the practical benefit for someone moving notes between a note-taking app, a static site generator and a wiki is conditional: two tools that both claim 'Markdown support' may still disagree on a table or a nested list if one implements CommonMark and the other implements a different, older, unspecified dialect. The specification removes one source of surprise, the core syntax, without eliminating the larger one, which is that Markdown remains a label covering several related but not identical formats. This is an editorial point worth stating directly: a spec is a shared test, not a guarantee that every tool sat the same exam.

• Does the destination tool document which Markdown dialect, if any, it implements?
• Do the features actually used, such as tables or footnotes, fall inside or outside the core CommonMark grammar?
• Has the exported file been checked in the new tool before the old one is retired?

CommonMark did not standardise Markdown so much as it standardised a well-tested core of it, leaving room around the edges for exactly the kind of divergence that made the project necessary in the first place. Knowing where that core ends is the useful, checkable question for anyone relying on plain text to survive a move between tools.