Happy to read there is some interest in “Markdown 2.0” or “lightweight markup, next generation”. With adoption by big outlets like Github and StackOverflow, and

Happy to read there is some interest in “Markdown 2.0” or “lightweight markup, next generation”. With adoption by big outlets like Github and StackOverflow, and dozens of static site generators built on plain text source files, marked-up in Markdown syntax, Markdown is becoming a _de facto_ general-purpose document _editing_ and _storage_ standard. With the advent of fast client-side parsers, soon it might even substitute html as a document _exchange format_, too (at least for some use cases). But there is no official spec, development of the syntax grew stale (from the start, thanks to Gruber)¹, and hence the language heavily suffers from fragmentation²: people want to be able to do more with light-markup, so they build extensions, or fork the language altogether. The troubles with Markdown are discussed in various³ places⁴, John MacFarlane built a formalized comparison tool⁵, but as of yet, there is no joint effort to cooperate on a lightweight markup standard. There are a few interesting projects that dare to forsake Markdown and try their luck: Fountain.io⁶ (a domain specific light markup language for playwriting), SkrivML⁷, Strictdown⁸, and z.m.l.⁹ Then there are, of course, the many predecessors of Markdown, which prove that Markdown (or light-markup in general) is not the imprescriptible privilege of its self-proclaimed benevolent dictator for life, and some of which are still widely used in various communities: Setext (1992), AFT (1999), Grutatxt (2000), AsciiDoc (2002), MediaWiki (2002), reStructuredText (2002), Org-mode (2003), Textile (2004)… We need an extensible lightweight markup language of sorts, a “lxml”, if you will, and we need to work on it together. If we want ever to succeed in establishing a true standard light markup language, the big challenge is not only to focus on extensibility, but also to reconcile the various existing and future syntaxes, and take care of backward-compatibility (with plain Markdown), as much as possible. As mentioned by quite a few commenters here and elsewhere, weeding out conflicting syntax should be the first thing to do. For starters, I begun a concordance¹⁰, listing the various delimiters and patterns used by competing lightweight markup languages. (Very rough draft, though, and need to think about a way to formalize the data, to make more accurate comparisons, and consequently, better decisions on the syntax of a future xlml.) ¹ http://blog.codinghorror.com/the-future-of-markdown/ http://blog.codinghorror.com/the-future-of-markdown/ ² https://github.com/rhythmus/markdown-resources https://github.com/rhythmus/markdown-resources ³ http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-not-my-favourite-language/ http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-not... ⁴ https://medium.com/the-future-of-publishing/495ccfe24a52 https://medium.com/the-future-of-publishing/495ccfe24a52 ⁵ http://johnmacfarlane.net/babelmark2/faq.html#what-are-some-big-questions-that-the-markdown-spec-does-not-answer http://johnmacfarlane.net/babelmark2/faq.html#what-are-some-... ⁶ http://fountain.io http://fountain.io ⁷ SkrivML ⁸ https://github.com/jakwings/strictdown https://github.com/jakwings/strictdown ⁹ http://www.z-m-l.com http://www.z-m-l.com ¹⁰ https://github.com/rhythmus/markdown-resources/blob/master/lightweightMarkupSyntaxComparison.tsv https://github.com/rhythmus/markdown-resources/blob/master/l...