View profile

Who Owns Markdown? ✍️

Who Owns Markdown? ✍️
By Ernie Smith • Issue #167 • View online
Writers do, not developers. If your argument against Markdown starts with the needs of developers rather than content creators, you’ve already missed the boat.
Sponsored: Like smart morning reads, but not so much into bias? The daily digest 1440, which counts a million folks among its readership, is for you. It covers the news like you remember it growing up: Down the middle. Subscribe here.

I had a whole piece written for today’s MidRange, all ready to go, completely knocked out, but then I saw this:
Christina Warren
It’s sort of amazing that someone wrote a whole takedown of Markdown (and a secret ad for their headless CMS aimed at agencies) without seeming to understand what Markdown really is.
And here I am an hour before publish time, with a take being bashed out in real time.
My take is this: Please, please, please, please, please, please, please, please stop pretending that Markdown is a developer format first. It’s not. You’re deluding yourselves otherwise.
Yes, it might be inspired by programmer-style thinking. Yes, developers have found lots of reasons to make use of Markdown as a way to implement some structure into the content they create. Yes, whole genres of content-management platforms have been built around the rise of Markdown. But writers and editors, who actually do a lot of the work in the format, get lost in a discussion when it’s being led by someone who works for a company with the tagline Content is Data.
(The hell it is. Data implies a methodical nature to the process of creation. It implies that creative output should be treated in the same context as programming. And you know what? That is the wrong order of things. Data serves content. If I was looking for a CMS and I saw that “Content is Data” tagline, I would close the tab.)
Anyway, to the piece itself: When you write a piece that literally embeds a John Gruber and Dave Winer exchange in which they both say, hey, this is a tool primarily for writers, don’t write 6,300 words attempting to prove them wrong.
The thing is, whether the use case is documentation, or you have a folder full of files that you bash out with a quickness and intensity that avoids all the extra crap that comes with a word processor, it’s important to keep in mind that this all starts with the content, and the tools, and the way that people create things.
In my case, I prefer Markdown for three reasons:
  • It simplifies the interface. I don’t have to worry about fonts or typography or anything like that. And unlike with HTML, it doesn’t get in the way by adding a lot of weight to the original words.
  • It is portable. Markdown can be converted into anything, and it can be extended to your specific needs. For my use case, I add shortcodes. You may hate that! But removing the shortcodes is easy and can be totally automated.
  • It allows a siloing off of the creative parts of the process. I like design, I like editorial. I don’t think those two parts should touch.
So to treat Markdown as a pure data-delivery mechanism sort of misses the point for Markdown’s value. It’s a way to build content without all the extra crap that usually comes with building content. Nothing more, nothing less. Not everyone uses it. Not everyone should.
(And just because not everyone uses it doesn’t mean that it’s bad for editors, as this piece says. Actually talk to some freaking writers sometime—we have different creative processes!)
To treat it as a pure vessel for complex content management structures inflates what it should be and who it’s for. (Side note: I wrote one of the takes around Slack and Markdown support, a general topic that the author highlights in this piece, and I will tell you it was not a purely developer-driven discussion. As Gruber would inform you, and he did me, Slack Markdown is not really Markdown.)
Data should be in service of content. Data-organization formats should be in the background, helping to organize the process of creation. If we let data organization define the way our content is built, we run into the very same problems that led a lot of professional writers to move away from bulky word processors in the first place.
Ernie Smith
Don't come for Markdown unless you are ready to deal with a community of rabid writers who don't care about your headless CMS
So yes, while Markdown is a great format for parsing content into a database, it gained that superpower the old-fashioned way: By being well-suited for writing, first.
Block-based editing has in many ways won out within the modern CMS platform. For example, Ghost, while still being Markdown-friendly, gave into blocks many years ago, despite being originally designed around a Markdown-driven interface. (I disagreed with this stance, so I moved to Craft CMS and structured my content around a Markdown-driven approach.)
But the block-driven interface shouldn’t usurp the creative process entirely. If I write in Markdown, the CMS should accept it. If I write in Word, the CMS should accept it (and spend a lot of extra time cleaning the code).
The CMS should serve the goals of the content, not the other way around.
Related Reads:
Bare-Metal Writing: What Our Word Processors Are Missing
The Future of Word Processors: What's Next for Text?
Time limit given ⏲: 30 minutes
Time left on clock ⏲: 40 seconds
If you like this, be sure to check out more of my writing at Tedium: The Dull Side of the Internet.
Do you own a newsletter? Want to try your hand at writing an entire article in 30 minutes or less? If so, let’s do a swap—reply to this email to see about setting something up.
Dig this issue? Let me know! (And make sure you tell others about MidRange!)
Did you enjoy this issue?
Ernie Smith

Hot takes in 30 minutes or less. A newsletter with an unforgiving deadline, written by Ernie Smith—who’s best known for another newsletter, Tedium.

Three times a week (Monday, Tuesday, Thursday). Hope I hit the 30-minute deadline. ⏲

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue