# Tables vs fenced code blocks, when is something “common”? **URL:** \ **Category:** Spec\ **Created:** [September 5, 2014, 11:28am UTC](https://talk.commonmark.org/t/tables-vs-fenced-code-blocks-when-is-something-common/411 "2014-09-05T11:28:16Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Zegnat](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/zegnat/32/182_2.png) [@Zegnat](https://talk.commonmark.org/u/Zegnat)\ **Post date:** [September 5, 2014, 11:28am UTC](https://talk.commonmark.org/t/tables-vs-fenced-code-blocks-when-is-something-common/411/1 "2014-09-05T11:28:16Z")
Like everyone else I have been keeping my eye on the discussion on adopting [tables as part of the CommonMark spec](http://talk.commonmark.org/t/tables-in-pure-markdown/81). But the thought expressed in this topic’s title was really sparked when I read [Dr Drang’s YAMF](http://www.leancrew.com/all-this/2014/09/yamf/) (linked to [here](http://talk.commonmark.org/t/standard-markdown-is-now-common-markdown/404/4) by @ComplexPoint) and [Joe Rosensteel’s Legitimate Text Processing](http://joe-steel.com/2014-09-04-Legitimate-Text-Processing.html) 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.](http://talk.commonmark.org/t/features-from-kramdown/111/3) “this project is focused on codifying core markdown features”. John specifically [states](http://jgm.github.io/stmd/) 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](http://talk.commonmark.org/t/what-changed-in-standard-markdown/15/3), 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](http://talk.commonmark.org/t/tables-in-pure-markdown/81): ````markdown | Header | Another header | |---------|----------------| | field 1 | something | | field 2 | something else | ``` html ```` ```auto 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/ ``` ---
**Author:** ![mofosyne](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/mofosyne/32/1438_2.png) [@mofosyne](https://talk.commonmark.org/u/mofosyne)\ **Post date:** [September 5, 2014, 11:57am UTC](https://talk.commonmark.org/t/tables-vs-fenced-code-blocks-when-is-something-common/411/2 "2014-09-05T11:57:03Z")
I agree. Since they changed the name from Standard Markdown to Common Markdown, the philosophy of Common Markdown much change to match. I envision markdown to be something that can encompass the most common usage of writing a typical document. Tables and fenced blocks of codes are both in common usage in the net. Especially tables, since office workers are not coders who need fenced blocks (and thus has the voice and the power to push that view), but they have just as much right in consideration for the common markdown feature set. Also, is anchor reference common? [I seen it in markdown extra](https://michelf.ca/projects/php-markdown/extra/#header-id). ``` ## The Site ## {#the-site} ``` ## edit: hmmmm according to [babelmark](http://johnmacfarlane.net/babelmark2/?normalize=1&text=%23+markdown+%7B%23test%7D) - 6 x `

markdown

` - 18 x `

markdown {#test}

` - 1 x `

markdown {#test}

` ---
**Author:** ![Zegnat](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/zegnat/32/182_2.png) [@Zegnat](https://talk.commonmark.org/u/Zegnat)\ **Post date:** [September 5, 2014, 12:11pm UTC](https://talk.commonmark.org/t/tables-vs-fenced-code-blocks-when-is-something-common/411/3 "2014-09-05T12:11:31Z")
> [@mofosyne](#): > > Since they changed the name from Standard Markdown to Common Markdown, the philosophy of Common Markdown much change to match. This has nothing to do with the name change. That’s just a _lucky_ coincidence. Everything I have linked and quoted was written before the name change, including the philosophy that Common Markdown “is focused on codifying core Markdown features”. > [@mofosyne](#): > > Also, is anchor reference common? I wouldn’t say so, like you already showed in your edit. Funny enough, 4 of those 6 that support it also support creating an ID without any extra syntax: ```markdown ## The Site ``` Will be transformed by showdown, pandoc, Maruku, and kramdown into the following HTML (excuse the regex): ```html

The Site

``` ---
**Author:** ![codinghorror](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/codinghorror/32/2_2.png) [@codinghorror](https://talk.commonmark.org/u/codinghorror)\ **Post date:** [January 5, 2016, 12:04pm UTC](https://talk.commonmark.org/t/tables-vs-fenced-code-blocks-when-is-something-common/411/4 "2016-01-05T12:04:32Z")
More practically, the question is > When does the average internet user, when typing words into a text box on the Internet, need to use a full-blown table? And the answer to that is > really, _really_ rarely Compare with: bold. italic. header. link. quote. etc … and yes, code. ---
**Author:** ![zzzzBov](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/zzzzbov/32/218_2.png) [@zzzzBov](https://talk.commonmark.org/u/zzzzBov)\ **Post date:** [January 5, 2016, 3:26pm UTC](https://talk.commonmark.org/t/tables-vs-fenced-code-blocks-when-is-something-common/411/5 "2016-01-05T15:26:51Z")
> [@codinghorror](#): > > More practically, the question is > > When does the average internet user, when typing words into a text box on the Internet, need to use a full-blown table? > > And the answer to that is > > really, really rarely I don’t necessarily disagree with this, but I would like to see evidence of this stance. Part of the issue is that adding tables to markup tends to be challenging especially for the average internet user, and in many cases there is no support for tables whatsoever, so other approaches are taken: code blocks with tabular data, images of tabular data, lists, links to the data, etc. Asking when a user “needs to use a table” is almost a red herring because without support they will find a way around the issue. I think it’s more appropriate to ask a question along the lines of: > When does the average internet user, when typing words into a text box on the internet, want to display tabular data? I don’t know the answer to that question. ---
**Author:** ![jgm](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/jgm/32/1360_2.png) [@jgm](https://talk.commonmark.org/u/jgm)\ **Post date:** [January 5, 2016, 11:10pm UTC](https://talk.commonmark.org/t/tables-vs-fenced-code-blocks-when-is-something-common/411/6 "2016-01-05T23:10:27Z")
> [@codinghorror](#): > > When does the average internet user, when typing words into a text box on the Internet, need to use a full-blown table? Tables are needed quite a lot in various sorts of writing. If you look at writing in general, and not writing by programmers, I’ll bet tables are much more common than highlighted source code. It’s important not to limit ourselves to thinking of CommonMark as something used for “text boxes on the internet.” I write lots of long documents, lecture notes, and letters in Markdown, and this is becoming increasingly common for academics. Lots of people now write scientific papers using Markdown. I know people who write novels in Markdown. So I think tables are very, very important. My main reason for leaving them out at the preliminary stage is that it’s important to get it right, and the design space is huge. Pandoc supports four different kinds of Markdown tables (simple, mulitline, pipe, grid), each with its own advantages and disadvantages. The kind of pipe table most implementations support is okay for simple things, but isn’t very flexible. Each table row has to fit on one line of the source, which is a huge restriction. You can’t have block-level content in table cells (e.g. lists, code blocks, multiple paragraphs). You can’t specify relative column widths. There’s no way to have cells spanning rows or columns. Some implementations provide ways to do these things at the expense of very ugly syntax that goes against the “readable source” spirit of Markdown. So it’s hard to know how to get the right balance. There are some good ideas in the thread on this forum about table syntax, and this is something we should revisit soon, after 1.0, along with math and maybe footnotes and definition lists. ---
**Author:** ![codinghorror](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/codinghorror/32/2_2.png) [@codinghorror](https://talk.commonmark.org/u/codinghorror)\ **Post date:** [January 5, 2016, 11:25pm UTC](https://talk.commonmark.org/t/tables-vs-fenced-code-blocks-when-is-something-common/411/7 "2016-01-05T23:25:32Z")
> [@jgm](#): > > There are some good ideas in the thread on this forum about table syntax, and this is something we should revisit soon, after 1.0, Totally agreed, I just feel there is little evidence of urgency around tables being _so_ important that they need to be built into the foundation under the house… ---
**Author:** ![jkdev](https://cdn.commonmark.org/letter_avatar_proxy/v2/letter/j/e79b87/32.png) [@jkdev](https://talk.commonmark.org/u/jkdev)\ **Post date:** [May 24, 2016, 8:16pm UTC](https://talk.commonmark.org/t/tables-vs-fenced-code-blocks-when-is-something-common/411/8 "2016-05-24T20:16:17Z")
Just to clarify, are we creating a CommonMark core spec based on (1) John Gruber’s Markdown, (2) Basic implementations of John Gruber’s Markdown, (3) [As many Markdown versions as possible](https://github.com/jgm/CommonMark/wiki/Markdown-Flavors), including extended flavors like GitHub, Markdown Extra, and Multimarkdown, (4) Other? If (1) or (2), it seems to me that tables and fences – useful as they are – should be in extensions only. If (3), then core could include the most compatible syntaxes (simple pipe-type tables and triple-backtick fences), with extensions for more flexible syntax and advanced features. ---
**Author:** ![codinghorror](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/codinghorror/32/2_2.png) [@codinghorror](https://talk.commonmark.org/u/codinghorror)\ **Post date:** [May 24, 2016, 10:15pm UTC](https://talk.commonmark.org/t/tables-vs-fenced-code-blocks-when-is-something-common/411/9 "2016-05-24T22:15:21Z")
The answer to your list is 1+2+4. The rationale is explained a number of places, can you please clarify what exactly it is you read, and why it didn’t answer your question? ---
**Author:** ![jkdev](https://cdn.commonmark.org/letter_avatar_proxy/v2/letter/j/e79b87/32.png) [@jkdev](https://talk.commonmark.org/u/jkdev)\ **Post date:** [May 24, 2016, 11:08pm UTC](https://talk.commonmark.org/t/tables-vs-fenced-code-blocks-when-is-something-common/411/10 "2016-05-24T23:08:09Z")
[http://commonmark.org](http://commonmark.org) “We propose a standard, unambiguous syntax specification for Markdown… One of our major goals is to strongly specify Markdown, and to eliminate the many old inconsistencies and ambiguities that made using Markdown so difficult.” But how are inconsistencies resolved? Is the goal to specify a “least common denominator” (fewer features, stricter syntax, but highly compatible with existing flavors) or a “greatest common multiple” (many features, more flexible syntax, but compatible with fewer flavors)? I had assumed it was the “least common denominator” approach, but including fenced code blocks doesn’t seem consistent with that. ---
**Author:** ![chrisalley](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/chrisalley/32/906_2.png) [@chrisalley](https://talk.commonmark.org/u/chrisalley)\ **Post date:** [May 25, 2016, 8:04am UTC](https://talk.commonmark.org/t/tables-vs-fenced-code-blocks-when-is-something-common/411/11 "2016-05-25T08:04:10Z")
We can consider “code blocks” to be a single feature and “tables” to be a single feature. If we do, then the decision to include only the former is consistent with the goal of the core spec to represent features of the original Markdown spec. Conceptually it is easier to communicate these broader feature categories than specific syntax variations that someone new to Markdown may not be aware of.