Like everyone else I have been keeping my eye on the discussion on adopting tables as part of the CommonMark spec. But the thought expressed in this topic’s title was really sparked when I read Dr Drang’s YAMF (linked to here by @ComplexPoint) and Joe Rosensteel’s Legitimate Text Processing linked there.
Several major contributors to the CommonMark spec have written in to say it has its roots in currently existing Markdown implementations, e.g. “this project is focused on codifying core markdown features”. John specifically states he “explored differences between markdown implementations extensively using [babelmark 2][bm]”. Yet some real changes were taken in as part of CommonMark, @stuartpb addressed this previously, and as Drang and Rosensteel point out code fences are especially noticeable.
So why exactly were fenced code blocks included? Have they become a de facto standard simply because of being included in some of the biggest implementations? Is it because the contributors to CommonMark had some personal preference for it? (Which would really make this their flavour rather than a core set of rules.)
I ran a little snippet of Markdown through [Babelmark][bm] to look for table support, using the example table from the tables discussion:
| Header | Another header | |---------|----------------| | field 1 | something | | field 2 | something else | ``` html <!doctype HTML>
I disregarded whether the info string was parsed correctly for the code block and looked only for `pre` and `code`. For the table I disregarded header markup and was simply looking if a table was made. Results: | Implementation | Tables | Fences | |---------------------------------------|--------|--------| | showdown 0.3.1 | No | Yes | | marked 0.2.6 | No | Yes | | cheapskate 0.1.0.1 | No | Yes | | Markdown.pl 1.0.1 | No | No | | Markdown.pl 1.0.2b8 | No | No | | lunamark 0.2 | No | No | | RedCarpet 2.1.1 | No | No | | pandoc (strict) 1.13.1 | No | No | | pandoc 1.13.1 | Yes | Yes | | RDiscount 1.6.8 | Yes | No | | PHP Markdown 1.0.2 | No | No | | Python-Markdown 2.4 | No | No | | cebe/markdown 1.0.0-dev | No | No | | Maruku 0.7.2 | Yes | No | | PHP Markdown Extra 1.2.8 | Yes | Yes | | Maruku (Math-Enabled) 0.7.3.beta1 | Yes | No | | Minima 0.8.0a2_20130826 | No | Yes | | kramdown 1.2.0 | Yes | No | | Blackfriday | Yes | Yes | | Haskell markdown package 0.1.7 | No | Yes | | Parsedown 1.0 | Yes | Yes | | s9e\TextFormatter (Fatdown/PHP) | No | No | | cebe/markdown GFM 1.0.0-dev | Yes | Yes | | cebe/markdown MarkdownExtra 1.0.0-dev | Yes | Yes | * Tables: 10/24 * Fences: 11/24 This begs the question, again, why were fenced code blocks accepted in CommonMark but are tables fervently rejected as being an extension to the original syntax? --- While I was writing all this, @ComplexPoint opened [a new topic based on the same premise](http://talk.commonmark.org/t/call-it-yamf-leaven-the-brand-sell-it-on-its-merits-not-its-name/410). [bm]: http://johnmacfarlane.net/babelmark2/