# Is CommonMark really Markdown "compatible"? **URL:** \ **Category:** Uncategorized\ **Created:** [September 9, 2014, 10:46pm UTC](https://talk.commonmark.org/t/is-commonmark-really-markdown-compatible/540 "2014-09-09T22:46:43Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![BrendanLong](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/brendanlong/32/77_2.png) [@BrendanLong](https://talk.commonmark.org/u/BrendanLong)\ **Post date:** [September 9, 2014, 9:31pm UTC](https://talk.commonmark.org/t/is-commonmark-really-markdown-compatible/540/1 "2014-09-09T21:31:04Z")
> Because CommonMark is, above all else, designed to be 100% Markdown compatible But… [it’s not](http://talk.commonmark.org/t/what-changed-in-commonmark/15). Having a Markdown logo seems like the same problem as calling this Markdown. If we’re not going to call it Markdown, why keep a Markdown logo? ---
**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:** [September 9, 2014, 9:37pm UTC](https://talk.commonmark.org/t/is-commonmark-really-markdown-compatible/540/2 "2014-09-09T21:37:17Z")
As stated earlier, it is literally _impossible_ to implement Markdown reliably because the current spec is so ambiguous – and the last official code release was in 2004. Thus, every single implementation of Markdown deviates from “Markdown” in unknowable ways. **We generally define “compatible” as “meets consensus in Babelmark”** , e.g. the unavoidable diverging implementations of Markdown (as the spec was ambiguous-by-design) agree most on this set. [See for yourself](http://johnmacfarlane.net/babelmark2/?text=%23+Hello+there%0A%0AThis+is+a+paragraph.%0A%0A-+one%0A-+two%0A-+three%0A-+four%0A%0A1.+pirate%0A2.+ninja%0A3.+zombie). This is where the word _common_ comes from, as in “In this set of markup, Markdown is commonly interpreted to mean…” There is definitely a tiny bit of unavoidable editorial choice in there, since there might be two “reasonable” divergences that you have to decide among. Wherever choices were made we tried to stay in harmony with the original goals of Markdown. ---
**Author:** ![BrendanLong](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/brendanlong/32/77_2.png) [@BrendanLong](https://talk.commonmark.org/u/BrendanLong)\ **Post date:** [September 9, 2014, 10:22pm UTC](https://talk.commonmark.org/t/is-commonmark-really-markdown-compatible/540/3 "2014-09-09T22:22:22Z")
> We generally define “compatible” as “meets consensus in Babelmark”, e.g. the unavoidable diverging implementations of Markdown (as the spec was ambiguous-by-design) agree most on this set. See for yourself. But you’re trying to redefine what Markdown is (which I think is why John Gruber keeps getting upset). Markdown [has a spec](http://daringfireball.net/projects/markdown/syntax) which CommonMark [unambiguously violates](http://talk.commonmark.org/t/what-changed-in-commonmark/15). I happen to agree with your changes, but they’re not just “Markdown without ambiguity”. ---
**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:** [September 9, 2014, 10:25pm UTC](https://talk.commonmark.org/t/is-commonmark-really-markdown-compatible/540/4 "2014-09-09T22:25:20Z")
As I said, every implementation of Markdown violates the current “spec” because it is so ambiguous. So this is kind of a meaningless statement to make. ---
**Author:** ![BrendanLong](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/brendanlong/32/77_2.png) [@BrendanLong](https://talk.commonmark.org/u/BrendanLong)\ **Post date:** [September 9, 2014, 10:38pm UTC](https://talk.commonmark.org/t/is-commonmark-really-markdown-compatible/540/5 "2014-09-09T22:38:48Z")
> As I said, every implementation of Markdown violates the current “spec” because it is so ambiguous. This doesn’t follow. If the spec is ambiguous, then different implementations can choose to implement the ambiguous behavior in different (incompatible) ways, but that doesn’t mean that they’re not compliant with the spec. “Undefined behavior” in C and C++ is a good example of this. Do you mean that Markdown has conflicting requirements? I could see what you mean if Markdown has conflicting requirements and your changes were just to pick one which one is more important, but are you really arguing that adding fenced code blocks is an example of removing ambiguity in the original spec? ---
**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:** [September 9, 2014, 10:49pm UTC](https://talk.commonmark.org/t/is-commonmark-really-markdown-compatible/540/6 "2014-09-09T22:49:10Z")
> [@BrendanLong](#): > > are you really arguing that adding fenced code blocks is an example of removing ambiguity in the original spec? Absolutely. Give an average user the task of putting code inside a numbered list and watch them struggle with the hidden 8 space rule. Very, very few people ever figure this out. On top of that, there are also many places where the 4 space indent rule for code introduces additional ambiguities in output. So having a fenced code block that starts ‘flat’ against the left side ```` ``` like so ``` ```` versus ``` like so ``` _does_ allow you to express Markdown in a way that is less prone to ambiguities of interpretation. For example, [try this](http://johnmacfarlane.net/babelmark2/?text=is+this+a+code%0A++++block%3F). ``` is this a code block? ``` And existing code blocks continue to work fine, of course. That’s the “compatible” bit. ---
**Author:** ![ComplexPoint](https://cdn.commonmark.org/letter_avatar_proxy/v2/letter/c/5f9b8f/32.png) [@ComplexPoint](https://talk.commonmark.org/u/ComplexPoint)\ **Post date:** [September 10, 2014, 12:42pm UTC](https://talk.commonmark.org/t/is-commonmark-really-markdown-compatible/540/7 "2014-09-10T12:42:26Z")
You feel it’s constructive to describe other contributor’s observations as ‘meaningless’ ? Your own claim is certainly not ‘meaningless’, but its meaning does seem arguable: > every implementation of Markdown violates the current “spec” because it is so ambiguous Well, John MacFarlane [openly acknowledges](http://talk.commonmark.org/t/what-changed-in-commonmark/15) that there are: > places where this spec says things that contradict the canonical syntax description Do you disagree then, with John’s distinction between **contradictions** and variations authorised by ambiguity ? Unless you do, it might well seem just a little careless or aggressive to claim that **all** variations within the scope of ambiguity “violate” the current spec, and perhaps a little combative or defensive to inform others (on demonstrably shaky ground) that their very reasonable and helpful statements are **‘meaningless’**. In the last analysis, any technical standard (or indeed constitution or law) expresses a compromise between differing interests, and the nature of the compromise is effectively shaped by the prevailing balance of forces at the time. If this standard is to enjoy respect and confidence, contributors do need to feel that their views and needs are respected, and that the shots are not being called exclusively by those who happen to own the platform of discussion, or are given to egregiously self-righteous or aggressive rhetoric. In short, they need to feel that the forum is not a charade, a theatre set up by powerful interests who are determined to shape events in the manner which best suits their own interests and businesses. The tension between: 1. Claims that the initial project is to add rigour to the existing core, and 2. the fact that it already incorporates changes which in John MacFarlane’s words “contradict the canonical syntax description”, and which are closely associated with particular and powerful players, is already expressive of a balance of forces which might well risk undermining credibility, and alienating potential adopters. A pity, because the product of these efforts could be valuable. ---
**Author:** ![ComplexPoint](https://cdn.commonmark.org/letter_avatar_proxy/v2/letter/c/5f9b8f/32.png) [@ComplexPoint](https://talk.commonmark.org/u/ComplexPoint)\ **Post date:** [September 10, 2014, 2:01pm UTC](https://talk.commonmark.org/t/is-commonmark-really-markdown-compatible/540/8 "2014-09-10T14:01:11Z")
PS I look forward (in 5-10 years time) to reading a Wiki entry on the prevailing Standard Plain Text Markup, which comments that it emerged out of an earlier standard, now forgotten, which was called Markdown. It would be good to think that something like that, by any other name, could emerge from all of the goodwill and thoughtful contributions that are accumulating here. But counter-productive preoccupation with variants of the word ‘markdown’, and with securing victory in various over-publicised personal conflicts, can only weaken that prospect. ---
**Author:** ![sam](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/sam/32/71_2.png) [@sam](https://talk.commonmark.org/u/sam)\ **Post date:** [September 10, 2014, 2:07pm UTC](https://talk.commonmark.org/t/is-commonmark-really-markdown-compatible/540/9 "2014-09-10T14:07:48Z")
Personally, I feel the best strategy for CommonMark is to distance itself from Markdown. Not attempt to build “a canonical Markdown” but instead attempt to build something better specified, more extensible that will last us for the next 10 years influenced heavily by Markdown, but not married to it. It should also have a very aggressive goal of displacing Markdown and its 50 differing implementations. I do feel that extensibility and in particular extensibility “standards” are at odds with Markdown, there is zero consumer value in having 700 different “table” plugins, CommonMark should be specifying this stuff. Similarly certain controversial decisions need to be made at the core, like newline handling and so on. I really hope that the answer to “Is CommonMark really Markdown “compatible”?” Becomes, you can easily drop in CommonMark and expect the vast majority of users to notice no change, except less odd bugs. ---
**Author:** ![EnCey](https://cdn.commonmark.org/letter_avatar_proxy/v2/letter/e/53a042/32.png) [@EnCey](https://talk.commonmark.org/u/EnCey)\ **Post date:** [September 10, 2014, 9:01pm UTC](https://talk.commonmark.org/t/is-commonmark-really-markdown-compatible/540/10 "2014-09-10T21:01:27Z")
The OP has one point that seems to have fallen under the table: why keep the Markdown logo? From a consumer standpoint alone it’s totally confusing if Markdown and CommonMark use the same logo. That being sad, who actually knows what the Markdown logo looks like? I happen to know it, but I suspect a vast majority of e.g. GitHub or StackExchange users don’t (and may not even know they’re typing Markdown). What I’m trying to say is: I don’t believe the Markdown logo is very recognizable, so sticking to it has little gain but the above mentioned drawback. I believe a new CommonMark logo would be better. ---
**Author:** ![alex](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/alex/32/294_2.png) [@alex](https://talk.commonmark.org/u/alex)\ **Post date:** [September 11, 2014, 3:38am UTC](https://talk.commonmark.org/t/is-commonmark-really-markdown-compatible/540/11 "2014-09-11T03:38:38Z")
I’m in agreement with Sam that CommonMark should distance itself from Markdown for a few reasons: 1. To put the naming controversy behind us. (Also why we need a new logo). 2. To allow CommonMark to go its own direction and supersede Markdown in its own right. 3. Extensibility - if we want to add something that the founders of the CommonMark spec don’t feel should be included, and was never part of Markdown originally, we should be able to say “this is an implementation of CommonMark with Tables and ID headers” and people will know what we mean. ---
**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:** [September 11, 2014, 6:18am UTC](https://talk.commonmark.org/t/is-commonmark-really-markdown-compatible/540/12 "2014-09-11T06:18:16Z")
> [@sam](#): > > Not attempt to build “a canonical Markdown” but instead attempt to build something better specified, more extensible that will last us for the next 10 years influenced heavily by Markdown That _is_ the goal. More extensibility is further on, since we’re currently building on quicksand and that has to be addressed first. > [@EnCey](#): > > why keep the Markdown logo? The same reason USB devices have the USB logo – it indicates compatibility. ![](https://cdn.commonmark.org/uploads/default/373/4039a8a3f2aa92d9.png) “oh, I can plug my USB cable in here and it will work” ![](https://cdn.commonmark.org/uploads/default/374/2c1faf520362fcc6.png) “oh, I can type Markdown in here and it will work” > [@ComplexPoint](#): > > Well, John MacFarlane openly acknowledges that there are: > > > places where this spec says things that contradict the canonical syntax description That’s an awfully … convenient … place to clip the quote. Let’s [look at the full quote](http://jgm.github.io/stmd/): > Because Gruber’s syntax description leaves many aspects of the syntax undetermined, writing a precise spec requires making a large number of decisions, many of them somewhat arbitrary. In making them, I have appealed to existing conventions and considerations of simplicity, readability, expressive power, and consistency. I have tried to ensure that “normal” documents in the many incompatible existing implementations of Markdown will render, as far as possible, as their authors intended. And I have tried to make the rules for different elements work together harmoniously. In places where different decisions could have been made (for example, the rules governing list indentation), I have explained the rationale for my choices. In a few cases, I have departed slightly from the canonical syntax description, in ways that I think further the goals of Markdown as stated in that description. > > There are **only a few places** where this spec says things that contradict the canonical syntax description: Here is what you quoted: > places where this spec says things that contradict the canonical syntax description What happened to “only a few”? Was quoting a complete sentence not possible? I suggest reading the paragraph before which provides the complete context. ---
**Author:** ![ComplexPoint](https://cdn.commonmark.org/letter_avatar_proxy/v2/letter/c/5f9b8f/32.png) [@ComplexPoint](https://talk.commonmark.org/u/ComplexPoint)\ **Post date:** [September 11, 2014, 8:59am UTC](https://talk.commonmark.org/t/is-commonmark-really-markdown-compatible/540/13 "2014-09-11T08:59:27Z")
We can take as large a sample of John’s texts as we like (the larger the better) and we still find him drawing a important distinction between: 1. Variants **authorised by ambiguity** 2. **Contradictions** of the original spec. This (correct) distinction is incompatible with your (repeated) claim (see above): > As I said, every implementation of Markdown violates the current “spec” because it is so ambiguous The point is not whether the number of contradictions of the Gruber spec is small or large. The point is that there is a difference between legitimate variation within the scope of ambiguity, and straightforward contradiction. John seems relaxed about acknowledging that. Is there some value in plastering over it, or trying to skate over it rapidly ? Either the new spec is ‘Markdown’ or it isn’t. If it contains any **contradictions** of the spec at all, even one, (and John acknowledges that there is more than one) then it may well be better than Markdown for some purposes, (I think it is), but it is not **‘compatible’** with it. Hanging on to the apron-strings of the ‘Markdown’ name, while developing a spec which contains contradictions of it, has a cost, but no value. The cost is of creating an impression of being more preoccupied with effective ownership and control of a name than with simply developing a good and widely respected spec. Surely an enriched and more rigorous spec is more valuable and more motivating than a costly and constraining ‘Markdown’ fetish ? ---
**Author:** ![ComplexPoint](https://cdn.commonmark.org/letter_avatar_proxy/v2/letter/c/5f9b8f/32.png) [@ComplexPoint](https://talk.commonmark.org/u/ComplexPoint)\ **Post date:** [September 11, 2014, 10:17am UTC](https://talk.commonmark.org/t/is-commonmark-really-markdown-compatible/540/14 "2014-09-11T10:17:12Z")
Let me see if have understood your position. You believe that **every** implementation ‘violates’ Gruber’s Markdown spec, but that CommonMark is ‘compatible’ with it ? So there is only one class of implementation – those that violate ? No distinction between those that vary within the scope of ambiguity and those that contradict ? Are you then inviting us to speak a language in which ‘violates’ is a synonym of ‘compatible with’ ? Is that the sense in which you speak of CommonMark being ‘compatible with’ Markdown ? (‘compatible with’ = ‘violates’) ? I have to say that I find it easier to make sense of John’s distinction, which gives us two classes of implementations: 1. Those that vary within the scope of ambiguity, and 2. those that contradict. ‘Compatible’ seems a good name for the first class of implementation. (But an unconvincing and rather unhelpful name for the second class) ---
**Author:** ![mikl](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/mikl/32/67_2.png) [@mikl](https://talk.commonmark.org/u/mikl)\ **Post date:** [September 11, 2014, 2:15pm UTC](https://talk.commonmark.org/t/is-commonmark-really-markdown-compatible/540/15 "2014-09-11T14:15:43Z")
> [@ComplexPoint](#): > > Either the new spec is ‘Markdown’ or it isn’t. No, I don’t think such concrete clarity is possible here. Markdown is used by many thousands of people, of those, I’d think less than 10% use (or have ever used) the original `markdown.pl` implementation (Perl isn’t commonly used in application development, whether deskop, mobile or web). So for all those who’ve learned markdown through PHPMarkdown or Discount or any of the zillion other implementations – markdown for them is that specific implementation. That’s why CommonMark(down) uses Babelmark to determine the consensus of all the mainstream markdown implementations, and generally uses the consensus as the standard. So to the most people, this will be hopefully turn out to be “markdown” in their eyes. A laudable goal, I think. ---
**Author:** ![EnCey](https://cdn.commonmark.org/letter_avatar_proxy/v2/letter/e/53a042/32.png) [@EnCey](https://talk.commonmark.org/u/EnCey)\ **Post date:** [September 16, 2014, 9:58am UTC](https://talk.commonmark.org/t/is-commonmark-really-markdown-compatible/540/16 "2014-09-16T09:58:12Z")
> [@codinghorror](#): > > “oh, I can type Markdown in here and it will work” I get the idea, but can you provide an example of where the Markdown logo is actually used in such a way? I checked StackOverflow and GitHub and the **Markdown logo is nowhere to be found**. On StackOverflow, when writing a question, there is a “_How to format_” help box, but it doesn’t even mention that the format being used is Markdown – the word “Markdown” first appears when you follow the [formatting help link](http://stackoverflow.com/editing-help), but still no logo in sight. This brings me to my initial point: the Markdown logo isn’t (very) recognizable, the comparison with the USB logo falls short because I personally haven’t seen the logo used in this way. * * * Aside from that, what about features exclusive to CommonMark, like fenced code blocks? As a user, I would appreciate it if I knew I could enter CommonMark and not _just_ Markdown, simply by glancing at the CommonMark logo. If the Markdown logo alone is used, I have to try whether or not fenced code blocks (or any other non-standard feature) is supported. I honestly don’t get why CommonMark should cling to the Markdown logo (or the name “Markdown”). ---
**Author:** ![Vilx\_](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/vilx_/32/184_2.png) [@Vilx\_](https://talk.commonmark.org/u/Vilx_)\ **Post date:** [September 16, 2014, 6:43pm UTC](https://talk.commonmark.org/t/is-commonmark-really-markdown-compatible/540/17 "2014-09-16T18:43:58Z")
Well, maybe that’s because the logo is as old as CommonMark? It may or may not become widely adopted. Only time will tell. But if it does, it will indicate that “this place is compatible with CommonMark, so everything that goes in CommonMark, goes here”. Or, at least, that’s how I’ve understood it. ---
**Author:** ![dajare](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/dajare/32/30_2.png) [@dajare](https://talk.commonmark.org/u/dajare)\ **Post date:** [September 17, 2014, 4:01pm UTC](https://talk.commonmark.org/t/is-commonmark-really-markdown-compatible/540/18 "2014-09-17T16:01:04Z")
> [@Vilx\_](#): > > Well, maybe that’s because the logo is as old as CommonMark? Actually, no. The logo has been around since 14 Mar 2012, the work of [Dustin Curtis](http://dcurt.is/the-markdown-mark), and is found in places like [WhatIsMarkdown](http://whatismarkdown.com/), one “evangelist’s” attempt to promote its use. More at the [Github repo](https://github.com/dcurtis/markdown-mark). ---
**Author:** ![bp\_](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/bp_/32/60_2.png) [@bp\_](https://talk.commonmark.org/u/bp_)\ **Post date:** [September 17, 2014, 4:20pm UTC](https://talk.commonmark.org/t/is-commonmark-really-markdown-compatible/540/19 "2014-09-17T16:20:45Z")
> You should use this mark to identify user input areas which support Markdown-compiled HTML output or **to identify general Markdown support**. Although you may modify this mark any way you like, without restriction, please respect the following guidelines CommonMark certainly counts as “general M **n"; "general M** n” is kind of _the whole mission statement._ ---
**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:** [September 18, 2014, 6:19am UTC](https://talk.commonmark.org/t/is-commonmark-really-markdown-compatible/540/20 "2014-09-18T06:19:20Z")
> [@EnCey](#): > > I checked StackOverflow and GitHub and the Markdown logo is nowhere to be found Look more closely: ![](https://cdn.commonmark.org/uploads/default/406/69731c5010de7c03.png) [Next page](https://talk.commonmark.org/t/is-commonmark-really-markdown-compatible/540.md?page=2)