I had a whole piece written for today’s MidRange, all ready to go, completely knocked out, but then I saw this:
https://twitter.com/film_girl/status/1495721258029363203
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.
(othree/Unsplash)
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.
https://twitter.com/ShortFormErnie/status/1495729339702333440
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.
Time limit given ⏲: 30 minutes
Time left on clock ⏲: 40 seconds
