I can't has cheezburger

So, after watching the Markdown standardization shitshow play out, some more substance is starting to come out of the woodwork.

First off, I was right in that people weren’t pissed about the name. Jeff Atwood changed the name to Common Markdown, then changed it again.

In the original renaming blog post, it was revealed that Gruber was emailed about the name Standard Markdown two weeks prior, and just never bothered to respond to that email. Instead, he approached the problem by publicly taking potshots at the project, and allegedly told Atwood that the name was “infuriating.” They tried another name, Common Markdown, but this was also a bust, and finally landed on CommonMark.

Case closed, right?

As of right now, Gruber’s still harboring ill will toward Atwood and others. It’s obvious that this isn’t about the name at all, but Gruber has yet to really articulate why; he seems to just be content to be an asshole about the project (and he invented it, so he certainly is entitled to be as big an asshole as he wants when people take his project and run with it, but I’m still calling him out on it).

Over the last couple of days, though, more context started to surface. Unfriendly exchanges between Atwood and Gruber date back many years, and there’s a great post indicating Gruber’s stance, which is essentially that he has a vendetta against standards.

That stance still wasn’t very satisfying to me. I figured there’s got to be more do it. Dr Drang posted a really solid case against what Commonmark is trying to do:

In other words, Standard Markdown isn’t a solidly built Core Markdown. Nor is it a Comprehensive Markdown with a bunch of helpful features that ol’ bastard Gruber refused to add. What it is is Yet Another Markdown Flavor, with a feature set tied to the needs of Meteor, Reddit, Stack Exchange, and GitHub. There’s nothing wrong with that, but it isn’t setting a Standard. It’s what everyone else does—some better, some worse. And in John MacFarlane’s case, he’s done it better at least three times.

Now we’re getting somewhere.

It would have been one thing if Commonmark took a hard stance and said “we’re just standardizing the core features of Markdown.” But they didn’t. They took that stance selectively, as evidenced by the GFM-inspired support for code fences, yet the lack of core support for things like tables. That seems hypocritical to me, and it’s a really valid complaint.

There are also objections to the fact that the spec was so full of really crazy edge cases and definitions of how to make the parser behave in those edge cases. After all, the spirit of Markdown is about the source being highly readable on its own pre-HTML conversion, and cases like this are are really fringe:

And yes, it’s all well and good that the philosophy of Markdown is to not write weird markup, but if you want to write a robust parser for a language you don’t get the luxury of pretending edge and corner cases don’t exist. Gruber chose to write a parser that didn’t cover all these edge cases. As a Markdown user that’s not usually a big deal, but as someone who wants to write software that supports Markdown it starts to make things messy. What Commonmark created for programmers is a Markdown standard that unambiguously defines all possible input.

Here’s what I hope happens:

• Commonmark should do one of two things: 1) drop the extras from Commonmark standard, or 2) incorporate the extras from other people’s Markdown forks to make an inclusive Markdown dialect. I personally would prefer the latter, assuming that the standard allows for a lot of flexibility on these extras. I personally love how Pandoc supports four ways to make tables
• Gruber moves on and stops bringing it up, and either participates in the Commonmark community to help shape it, or follows his current strategy of being happy with what he initially created and sticking with that.
• Commonmark becomes a de facto standard for Markdown formats, and when people are building their own Markdown forks, start off using Commonmark as their baseline, and extend from there.