I feel dirty pimping my project, but I think it's relevant enough and sets out one angle of my interest in Markdown: I created a Chrome/Firefox/Thunderbird extension called Markdown Here (MDH) that lets you write your email in Markdown and then render it before sending. Check it out: https://github.com/adam-p/markdown-here -- I wrote it because I wanted it to exist, and it's actually pretty sweet. I'm very ambivalent about the prospect of a new Markdown spec. In favour of a new spec: Experience with one MD dialect is irritatingly non-transferable. I work on projects on both Github and Bitbucket. I'm pretty comfortable with GFM at this point, but I struggle to figure out Bitbucket's dialect (seems to have undocumented backtick-fences? but not syntax name? unlike GFM there's no clear description of it?). Even dialects have dialects. In MDH I use the JS renderer Marked (https://github.com/chjj/marked) -- specifically in GFM mode (it was the best GFM-supporting JS lib I could find). But even it doesn't exactly implement GFM's mods (line breaks, tables). Concern about a new spec: I have trouble believing that any single spec can encompass enough of the MD extensions to "win". And I think winning is probably necessary, or else the "n+1 specs" objection is compelling. Maybe some kind of extensibility can be built into the spec? Cool, but complex. (Standardized flags indicating what table format to use? Editor symbols to quickly show users what table format is available?) Would such extensibility really gain us enough/anything over what we have now? (I don't mean to be glib with that question. I think it might gain us a lot.) Tangent: If MD starts getting used a lot for extracted code docs, there's going to be a push for Javadoc-ish extensions. With the help of a user I, uh, added TeX math formula support to MDH. Like so: "$-b \pm \sqrt{b^2 - 4ac} \over 2a$". So I've done my part to dirty the dialect waters. I don't feel good about this. I think that one of the issues is that there's a tension between "MD as primarily markup" and "MD as primarily plaintext". Two examples of this, from GFM: Fenced code blocks. Indented blocks of code look pretty nice when reading plaintext. Fenced code doesn't look as nice, and even less so when you specify the language. But writing/pasting 4-space indented code is more of a hassle, and it's not clear how to specify the language. GFM line breaks. Gruber's original spec basically discarded single linebreaks -- this allowed MD writers to maintain 80-char lines without breaking flow when rendering. In contrast, GFM interprets a single linebreak as a <br>. I don't like this GFM change, but I also don't like the original spec's "two spaces at the end of the line to get a <br>". Those examples might seem pretty minor, but the more we extend MD, the less plaintext-readable it becomes. Probably. (I don't mean for that statement to be shrill. I love many of the extensions. And maybe it's okay that extensions get somewhat less plaintext-readable if the base stays clean. Artificially constraining MD's growth sure won't work, anyway.)