# The Future of Markdown

**URL:** <https://discourse.codinghorror.com/t/the-future-of-markdown/29>\
**Category:** blog\
**Created:** [October 25, 2012, 12:00am UTC](https://discourse.codinghorror.com/t/the-future-of-markdown/29 "2012-10-25T00:00:00Z")\
**Posts on this page:** 20\
**Page:** 3

<div class="post-metadata">

**Author:** ![sfermigier](https://discourse-cdn.codinghorror.com/letter_avatar_proxy/v2/letter/s/df705f/32.png) [@sfermigier](https://discourse.codinghorror.com/u/sfermigier)\
**Post date:** [October 26, 2012, 12:00am UTC](https://discourse.codinghorror.com/t/the-future-of-markdown/29/41 "2012-10-26T00:00:00Z")

</div>

I like Markdown a lot, but for semi-complex to complex work I have to use ReStructuredText, despite what I consider a few flaws.

What I think is an important win for ReST is its extensibility, a feature absent from Markdown.

Your initiative would certainly, IMHO, be more beneficial if the resulting standard includes an extensibility mechanism with features on par with those of ReST.

---

<div class="post-metadata">

**Author:** ![DanielS](https://discourse-cdn.codinghorror.com/letter_avatar_proxy/v2/letter/d/3ab097/32.png) [@DanielS](https://discourse.codinghorror.com/u/DanielS)\
**Post date:** [October 26, 2012, 12:00am UTC](https://discourse.codinghorror.com/t/the-future-of-markdown/29/42 "2012-10-26T00:00:00Z")

</div>

I prefer reStructuredText too, but unfortunately Markdown “won” the simple markup market.

---

<div class="post-metadata">

**Author:** ![casperOne](https://discourse-cdn.codinghorror.com/letter_avatar_proxy/v2/letter/c/bc8723/32.png) [@casperOne](https://discourse.codinghorror.com/u/casperOne)\
**Post date:** [October 26, 2012, 12:00am UTC](https://discourse.codinghorror.com/t/the-future-of-markdown/29/43 "2012-10-26T00:00:00Z")

</div>

You know, the thing that stuck out the most for me was the Yankees symbol. I respect you a little more (growing up in the Bronx, being a Yankees fan for over 30 years and going to 20+ games a year).

That said, blame RChern for the gravatar, as I lost a bet with her comparing our favorite teams respective playoff perfomance.

---

<div class="post-metadata">

**Author:** ![LeonardoH](https://discourse-cdn.codinghorror.com/letter_avatar_proxy/v2/letter/l/ce7236/32.png) [@LeonardoH](https://discourse.codinghorror.com/u/LeonardoH)\
**Post date:** [October 26, 2012, 12:00am UTC](https://discourse.codinghorror.com/t/the-future-of-markdown/29/44 "2012-10-26T00:00:00Z")

</div>

What I think is really of value are the test cases. Any resulting implementation is nice, but for me it would be only a reference implementation.

---

<div class="post-metadata">

**Author:** ![Tony4d](https://discourse-cdn.codinghorror.com/letter_avatar_proxy/v2/letter/t/df788c/32.png) [@Tony4d](https://discourse.codinghorror.com/u/Tony4d)\
**Post date:** [October 26, 2012, 12:00am UTC](https://discourse.codinghorror.com/t/the-future-of-markdown/29/45 "2012-10-26T00:00:00Z")

</div>

I endorse!

---

<div class="post-metadata">

**Author:** ![IanR](https://discourse-cdn.codinghorror.com/letter_avatar_proxy/v2/letter/i/b5a626/32.png) [@IanR](https://discourse.codinghorror.com/u/IanR)\
**Post date:** [October 26, 2012, 12:00am UTC](https://discourse.codinghorror.com/t/the-future-of-markdown/29/46 "2012-10-26T00:00:00Z")

</div>

If just stackExchange and grit hub agreed on a “standard” AND STOPPED USING their current in-house system it would be a good start.

So a converter for all the content that has already been created must be part of the effort.

---

<div class="post-metadata">

**Author:** ![FyodorS](https://discourse-cdn.codinghorror.com/letter_avatar_proxy/v2/letter/f/8baadc/32.png) [@FyodorS](https://discourse.codinghorror.com/u/FyodorS)\
**Post date:** [October 26, 2012, 12:00am UTC](https://discourse.codinghorror.com/t/the-future-of-markdown/29/47 "2012-10-26T00:00:00Z")

</div>

In my opinion, Markdown has outgrown it’s original idea of “simpler HTML” and is becoming a universal document format. To serve this purpose it needs more than just a spec for the file format. It needs a good simple **object model for text** that can become a basis for implementations of parsers and formatters in several different languages.

Most of the existing implementations work one way, i.e. from Markdown to HTML and don’t have explicit model for text inside. Those who do, don’t preserve document structure on load-save (for example, references are renamed on conversion from Markdown to Markdown).

I’ve been working on a JSON-based model for Markdown for some time. It currently has PEG-based parser, several formatters and a set of language-indepentent test cases. It also integrates with Pandoc and MultiMarkdown to import documents in their formats.

[https://github.com/sheremetyev/texts.js](https://github.com/sheremetyev/texts.js)

---

<div class="post-metadata">

**Author:** ![AndrewP](https://discourse-cdn.codinghorror.com/letter_avatar_proxy/v2/letter/a/df788c/32.png) [@AndrewP](https://discourse.codinghorror.com/u/AndrewP)\
**Post date:** [October 26, 2012, 12:00am UTC](https://discourse.codinghorror.com/t/the-future-of-markdown/29/48 "2012-10-26T00:00:00Z")

</div>

Wow, what timing! I’ve experienced the same problems with MD, especially with regards to syntax confusion and Stack Overflow’s out of date implementation.

As it happens, the Markdown community is working on a central site to coordinate the various Markdown implementations:

[https://github.com/markdown](https://github.com/markdown)

Anyone interested in contributing is invited to connect to GitHub.

---

<div class="post-metadata">

**Author:** ![JonathanD](https://discourse-cdn.codinghorror.com/letter_avatar_proxy/v2/letter/j/7ab992/32.png) [@JonathanD](https://discourse.codinghorror.com/u/JonathanD)\
**Post date:** [October 26, 2012, 12:00am UTC](https://discourse.codinghorror.com/t/the-future-of-markdown/29/49 "2012-10-26T00:00:00Z")

</div>

I prefer org-mode. Unfortunately, only emacs understands it.

---

<div class="post-metadata">

**Author:** ![Chas\_\_Owens1](https://discourse-cdn.codinghorror.com/letter_avatar_proxy/v2/letter/c/ba9def/32.png) [@Chas\_\_Owens1](https://discourse.codinghorror.com/u/Chas__Owens1)\
**Post date:** [October 26, 2012, 12:00am UTC](https://discourse.codinghorror.com/t/the-future-of-markdown/29/50 "2012-10-26T00:00:00Z")

</div>

I find it hilarious that right after talking about making markdown “work in the same way across all web sites in the world when they begin typing.” you include an image that almost but doesn’t quite specify how a markdown icon should look (where is the down arrow supposed to reside horizontally and how long should the icon be?).

---

<div class="post-metadata">

**Author:** ![JosephM](https://discourse-cdn.codinghorror.com/letter_avatar_proxy/v2/letter/j/a88e57/32.png) [@JosephM](https://discourse.codinghorror.com/u/JosephM)\
**Post date:** [October 26, 2012, 12:00am UTC](https://discourse.codinghorror.com/t/the-future-of-markdown/29/51 "2012-10-26T00:00:00Z")

</div>

A formal specification for an extendible, human-readable Markdown-like language is a great idea, but something else is needed first. We need a specification for characterising and classifying text processing systems, including text formatting interfaces, mark-up languages, and the text being represented. A mark-up language may be characterised by its use of semantic mark-up (e.g. emphasis rather than italics), single new lines being treated as spaces (to allow formatting on non-wrapping displays), and other such qualities.

---

<div class="post-metadata">

**Author:** ![Jpyrat](https://discourse-cdn.codinghorror.com/letter_avatar_proxy/v2/letter/j/b4bc9f/32.png) [@Jpyrat](https://discourse.codinghorror.com/u/Jpyrat)\
**Post date:** [October 26, 2012, 12:00am UTC](https://discourse.codinghorror.com/t/the-future-of-markdown/29/52 "2012-10-26T00:00:00Z")

</div>

Hi,

Do you know [https://code.google.com/p/textwheel/wiki/TextWheel](https://code.google.com/p/textwheel/wiki/TextWheel) ?  
« This is a preliminary proposal for an interoperability layer for all the different text engines that have been floating for years now around the Web. »

TextWheel is in use with the CMS SPIP 3.0 : [http://contrib.spip.net/Presentation-de-TextWheel](http://contrib.spip.net/Presentation-de-TextWheel)

Might be a good start ?

---

<div class="post-metadata">

**Author:** ![Jeffio](https://discourse-cdn.codinghorror.com/letter_avatar_proxy/v2/letter/j/5daacb/32.png) [@Jeffio](https://discourse.codinghorror.com/u/Jeffio)\
**Post date:** [October 26, 2012, 12:00am UTC](https://discourse.codinghorror.com/t/the-future-of-markdown/29/53 "2012-10-26T00:00:00Z")

</div>

We recently added Markdown as an option in our hosted CMS (YikeSite) in hopes that some of our customers would choose it over the WYSIWYG editor.

You can play with it here: [http://www.markdowncms.com](http://www.markdowncms.com)

If there was a standardized Markdown, we would implement that for sure.

---

<div class="post-metadata">

**Author:** ![Gordonguthrie](https://discourse-cdn.codinghorror.com/letter_avatar_proxy/v2/letter/g/ac91a4/32.png) [@Gordonguthrie](https://discourse.codinghorror.com/u/Gordonguthrie)\
**Post date:** [October 26, 2012, 12:00am UTC](https://discourse.codinghorror.com/t/the-future-of-markdown/29/54 "2012-10-26T00:00:00Z")

</div>

I wrote the Erlang Markdown interpreter [https://github.com/hypernumbers/erlmarkdown](https://github.com/hypernumbers/erlmarkdown)

Real-life Markdown almost always requires that something be rendered twice:

- on the server
- in the client preview

The sane way to make this easy is for the javascript version to be the dominant one - and all the servers-side language version to test themselves the same way: _if I start from the same markdown do I produce the same whitespace compatible output as the javascript parser_.

When I wrote erlmarkdown I first implemented my take on the spec - then realised I needed to switch to tracking a reference javascript version - which didn’t exist/wasn’t maintained/etc, etc

Then I discovered that the whitespace output of the javascript parser was all over the shop, random linebreaks and stuff - and it turned out to be super-hard to backport that into my hand-written, look-ahead parser.

Most of the whitespace difference was just html-farts of no consequences - but the inability to produce whitespace equivalent meant I couldn’t write simple asserts like:

- =?equals(Got, Expected)

It was generally a real pain.

**PS** I also think that markdown implementations should accept all html and xml tags from an arbritrary implementation-time whitelist.

**PPS** They need to accept unicode input as well.

---

<div class="post-metadata">

**Author:** ![DaveP](https://discourse-cdn.codinghorror.com/letter_avatar_proxy/v2/letter/d/49beb7/32.png) [@DaveP](https://discourse.codinghorror.com/u/DaveP)\
**Post date:** [October 26, 2012, 12:00am UTC](https://discourse.codinghorror.com/t/the-future-of-markdown/29/55 "2012-10-26T00:00:00Z")

</div>

[http://www.w3.org/community/markdown/](http://www.w3.org/community/markdown/) The MarkDown community now exists. With your help its development can start.

---

<div class="post-metadata">

**Author:** ![Dleppik](https://discourse-cdn.codinghorror.com/letter_avatar_proxy/v2/letter/d/54ee81/32.png) [@Dleppik](https://discourse.codinghorror.com/u/Dleppik)\
**Post date:** [October 26, 2012, 12:00am UTC](https://discourse.codinghorror.com/t/the-future-of-markdown/29/56 "2012-10-26T00:00:00Z")

</div>

I agree on having a specification, and I don’t think you need Gruber’s blessing. In fact, it may be healthiest at this point for the community to diverge from its origins.

Extensions are a must-have in the specification. There are some sites that require source code, and other sites where source code markup makes no sense. If nothing else, extensions allow the core to remain fixed as new use cases pop up, and allow experimental changes that may ultimately migrate to the core. One of the things that has allowed HTML to age gracefully is that the behavior for unknown elements is well-defined, so new elements can be added in a manner that doesn’t break on older browsers.

---

<div class="post-metadata">

**Author:** ![Damonallison](https://discourse-cdn.codinghorror.com/letter_avatar_proxy/v2/letter/d/779978/32.png) [@Damonallison](https://discourse.codinghorror.com/u/Damonallison)\
**Post date:** [October 26, 2012, 12:00am UTC](https://discourse.codinghorror.com/t/the-future-of-markdown/29/57 "2012-10-26T00:00:00Z")

</div>

+1

I’m not a complete power user of markdown - but the idea of continued fragmentation would be really frustrating.

---

<div class="post-metadata">

**Author:** ![BoltBait](https://discourse-cdn.codinghorror.com/letter_avatar_proxy/v2/letter/b/71c47a/32.png) [@BoltBait](https://discourse.codinghorror.com/u/BoltBait)\
**Post date:** [October 26, 2012, 12:00am UTC](https://discourse.codinghorror.com/t/the-future-of-markdown/29/58 "2012-10-26T00:00:00Z")

</div>

Ugh. I absolutely HATE markdown.

I prefer UBB code instead. It is much easier to remember and use. Not to mention way cleaner and easier to implement.

---

<div class="post-metadata">

**Author:** ![Peter\_ajtai](https://discourse-cdn.codinghorror.com/letter_avatar_proxy/v2/letter/p/ba8739/32.png) [@Peter\_ajtai](https://discourse.codinghorror.com/u/Peter_ajtai)\
**Post date:** [October 26, 2012, 12:00am UTC](https://discourse.codinghorror.com/t/the-future-of-markdown/29/59 "2012-10-26T00:00:00Z")

</div>

One of the currently broken things, that seems easilly fixable is the code highlighting.

For example github uses sign posts.  
Stack overflow uses indentation (w/o ability to specify language)?  
Jekyll… which uses markdown, doesn’t use markdown for code highlighting but uses liquid templating.

I wish markdown would include sign posted code highlighting with the desired language specified (like in github)

---

<div class="post-metadata">

**Author:** ![Liam\_Quin](https://discourse-cdn.codinghorror.com/letter_avatar_proxy/v2/letter/l/b5a626/32.png) [@Liam\_Quin](https://discourse.codinghorror.com/u/Liam_Quin)\
**Post date:** [October 26, 2012, 12:00am UTC](https://discourse.codinghorror.com/t/the-future-of-markdown/29/60 "2012-10-26T00:00:00Z")

</div>

Maybe you could consider one of our new and shiny W3C Community Groups at [http://www.w3.org/Community](http://www.w3.org/Community) for starting this work?

Liam (W3C staff)

[Previous page](https://discourse.codinghorror.com/t/the-future-of-markdown/29.md?page=2)

[Next page](https://discourse.codinghorror.com/t/the-future-of-markdown/29.md?page=4)