Thoughts on Markdown
October 16, 2010 at 10:47 PM by Dr. Drang
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:
- Discount, the C implementation written by David Parsons and used in MarkdownMail.
- PEG-markdown, the C implementation written by John MacFarlane.
- Showdown, the JavaScript implementation written by John Fraser.
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.
- Tables, for example, have a long history in plain text documents, and the use of pipe characters (|) to separate the columns isn’t clutter if they’re nicely spaced. It’s true that plain text tables can look crappy when written in a proportional font, and maybe that’s why Gruber has kept them out of his version, but they’re perfectly readable when done right in a monospaced font.
- Definition lists don’t hold much interest for me, but many people find them useful. The syntax used by PHP Markdown Extra and MultiMarkdown doesn’t have any longstanding plain text antecedent, but it’s easy to read and not obtrusive in any way. (Discount’s definition list syntax, on the other hand, is awful.)
- Footnotes, as implemented by PHP Markdown Extra and MultiMarkdown, are a simple extension of the existing reference link syntax and are no more obtrusive than it is. (It was my recent messing around with footnotes and consolidation of Markdown processors that got me thinking about the future of Markdown.)
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.
-
Textile, Setext, RDoc, reStructured Text, POD, etc. ↩
-
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. ↩
