Slack just updated its longtime editor for its primary interface—and the rich-text result hints at a longstanding tension over how much of a helping hand users need from their text editors and communication programs.
Power users, like programmer Arthur O’Dwyer, make the case that they don’t really need any—and the rich-text interface they added just gets in the way. “I wish Slack would provide a way to disable the WYSIWYG rich-text-input box,” he wrote in a viral blog post. “I don’t think it’s useful, and it’s extremely annoying to have to keep backspacing to fix mistakes.”
If the What-You-See-Is-What-You-Get editor is ticking off so many people, why change it?
At the center of the conflict is a question: Can we ever truly accept Markdown formatting—which Slack used before this—in the mainstream?
Startup Roots, Mainstream Growth
In the roughly 15 years since old-school blogger John Gruber created it for his own purposes, Markdown has become a lowkey important way of writing markup, or text in a standardized format.
Coming about in an era when the most common tool for writing was a rich text editor, it brought a programmer’s mindset to standard writing.
At its root, it simplifies HTML into something that can be easily parsed as necessary. To create a header, for example, you put a # hashtag in front of a line, which then gets parsed as an tag in HTML; and **by putting two stars around a block of text**, it bolds it. [And adding a link](https://google.com) often requires just a handful of brackets. The result of these techniques is that the text is readable—even if it’s not formatted as HTML.
This felt like a useful response to a problem that was fairly prevalent at the time—the fact that, when using a rich-text editor to edit HTML, it really messed up the code, which could result in all sorts of problems.
Since Gruber developed the original spec (which was left open enough that lots of variants have appeared), Markdown has become a key tool for writing in all sorts of contexts—with dedicated editors such as iA Writer (which I’m currently writing on), Bear, and Ulysses gaining popularity.
This bled into the startups of the period. Markdown was a favorite of programmers writing documentation, which led them to include the functionality as an input option in their apps. Tumblr, when it was still a fancy blogging tool, supported it as far back as 2008, and massively successful programmer favorites such as Github and Stack Overflow have supported it for about as long. Jeff Atwood, the cocreator of Stack Overflow, characterized Markdown as one of three “key technology bets” the company made during the time of its launch. It’s in that general spirit that later tools have included elements of Markdown baked in, most notably the word processing tool Dropbox Paper, the content management system Ghost, and Slack.
Why Markdown? Why not?
Markdown had a few advantages over the rich-text editors of the time, including better quality control over the resulting HTML. In Slack’s case, you didn’t really need to use it if you didn’t want to.
But Markdown has always been controversial with some, because while it’s much simpler to learn than even markup tools such as HTML or CSS, it’s always been considered a power-user tool, meaning that when given a choice, many regular users prefer WYSIWYG rich-text editors. Why put stars around your text when you can simply hit command-B?
To be fair, rich text editors have gotten much better in recent years, with next generation tools like Quill.js, which Slack uses, helping to get around some of the primary weaknesses rich text has with HTML. (A counterpoint to this: Microsoft Word’s editor, also used in places like Outlook, is rough enough in terms of its HTML support that it’s the main reason why email is still developed with HTML tables.)
A Tough Sell in the Enterprise
I would argue that Markdown is a great tool and reflects the ways plain text can remain useful in a dynamic world. But try selling that to a CEO or Chief Technical Officer, as I’m sure Slack, as a public company, does.
This belies the fact that Markdown has became a major element of some major content management trends in the enterprise, such as static site generators and “headless” CMS platforms, which may have rich text interfaces but often save their data … in Markdown.
Rich text editors are easy to use and easier to embrace, but for people who don’t need them, they just add extra junk in front of the process. On top of that, it could make an already heavy web app that gobbles up RAM even more resource-intensive.
I’m a Markdown stan—and I make no bones about it. All of my writing since at least 2012 has started in a Markdown editor. I think it solves a lot of problems for writers, and it could solve just as many for editors if our editing tools were built around it. It’s easy to use and it’s thoughtfully limited in ways that make it more efficient than rich text in many contexts.
But we’re in a world where Markdown doesn’t look mainstream, despite the fact it’s in so many contexts that it’s already everywhere. Good luck selling that to the boss, though.
This article originally appeared on VICE US.