Thoughts on Markdown

At the end of last year, Jeff Atwood wrote a post in which he criticized John Gruber for abandoning Markdown and begged him to take a more active role in it development. There were responses both pro and con (Daniel Jalkut’s post was an archetype of the cons), but none from Gruber himself. I had vague plans of writing down my own thoughts on Markdown’s direction, but didn’t want to finalize them until I’d heard what Gruber had to say.

Well, it’s been 10-11 months now, so I think it’s fair to say Gruber has no intention of responding. The Markdown world has changed in the past year, and I think it’s on the verge of changing much more rapidly. It’s worth revisiting Atwood’s post and thinking about Markdown’s future.

I suspect Markdown is on the verge of rapid expansion because it’s being taken up by iOS writing apps. MarkdownMail, TrunkNotes, and Edito are already using it; Elements may be following suit soon. I suspect it’s the recent popularity of “plain text editing” on iOS that’s driving the Markdown surge—among the lightweight markup languages,1 Markdown has always looked like the most like plain text. It fits the aesthetic of these apps.

But as I mentioned in my post about MarkdownMail, Gruber’s canonical Markdown implementation cannot be used in iOS because it relies on Perl. In fact, none of the big three2 Markdown implementations—Gruber’s original, Fletcher Penney’s MultiMarkdown, and Michel Fortin’s PHP Markdown (with or without the Extras)—are usable in iOS because of the scripting languages in which they’re written.

Of the standalone Markdown processors I know about, only three can be incorporated in a native iOS app:

I suppose anyone could come along and write his own Markdown processor for inclusion in an iOS editor, but as these are open source, they’ll probably be the processors of choice. And I would guess it’s the C implementations that will be the most popular.

Interestingly, both Discount and PEG-markdown (especially Discount) extend the Markdown syntax with features that are not in the canonical Markdown; features that Gruber probably actively dislikes because they clutter up the text. But if these iOS-ready implementations take off, their features are likely to become standard.

A few of these features are in other Markdown implementations and are, I think, perfectly in keeping with the original Markdown aesthetic.

Gruber obviously disagrees with me on these points because, as Atwood pointed out, the official Markdown hasn’t changed in years.

Overall, I think Gruber’s reluctance to add features to Markdown is a good thing. If you look through the Markdown mailing list, you’ll see all kinds of suggestions that are simply not in keeping with the Markdown aesthetic. If they were incorporated, Markdown would be a huge mess: HTML without angle brackets.

However…

An occasional word—or just a single definitive word—from the project leader would be helpful to the Markdown community. My suspicion is that Gruber considers Markdown finished; it has all the features he thinks are appropriate, and he has no intention of extending it. That’s a perfectly valid position for him to take. It’s Don Knuth’s position on TeX, and no one bitches about him being a “bad parent.” But that’s because Knuth has made his position clear—Gruber hasn’t.

If John came out and told us all that his Markdown was feature-complete, other Markdown programmers would know where they stand and could work together on a common syntax for extensions without worrying that one day Markdown.pl will sprout a new feature they’ve implemented, but with a different syntax.

I don’t expect all the Markdown programmers to agree on an extension syntax. There may be two or three extended Markdowns, just as there are a few extended versions of TeX. But I do think things would shake out quickly into a small number of extensions, each implemented in several languages. A “LaMarkdown” in PHP for WordPress and one in Perl for Movable Type. A “ConMarkdown” in Ruby for Instiki and one in Objective C for iOS. A “PlainMarkdown” syntax that’s unchanging—and known to be unchanging—would make that easier.

I’m not saying Gruber owes us anything. He doesn’t. But Markdown is changing, with or without him. A word from him could make the change more orderly and, perhaps, more in keeping with his wishes.

Update 10/17/10
Another note-taking iOS app that uses Markdown is Note & Share, which uses a third C implementation of Markdown: the unfortunately named libupskirt.


  1. Textile, Setext, RDoc, reStructured Text, POD, etc. 

  2. It’s just my sense that these are the most used implementations—I don’t have any data. I’ve been in and around the Markdown community for about five years, so I think I have a handle on what’s popular, but I could be dead wrong. BlueCloth, for example, could be more popular than what I call the big three. 


4 Responses to “Thoughts on Markdown”

  1. Jiii says:

    You sure that you couldn’t include a perl interpreter in a native iOS app now with the relaxation of the developer guidelines?

    See: http://toucharcade.com/2010/09/12/manomio-adds-basic-to-c64-in-light-of-apples-sdk-agreement-update/

    Not that it would be worth the effort

  2. Jiii says:

    also http://daringfireball.net/2010/09/app_store_guidelines

  3. Dr. Drang says:

    Jiii, I knew about the change to the developer guidelines but didn’t think developers of plain text editors would want to add an interpreter just to get Markdown. Maybe I’m wrong about that.

    If someone did add an interpreter, though, I have a hard time believing it would be Perl—too big and tentacular. Lua seems a more likely candidate and there are at least two Lua Markdowns: one by Niklas Frykholm and the other by the absurdly prolific John MacFarlane. We’ll see how things shake out.

  4. jii says:

    I agree, I don’t think it would be worth it when the C implementations seem adequate