It’s becoming increasingly difficult to divorce Web content from the tools used to create it. Writing for the Web in particular has started to rely more on a basic knowledge of HTML, the mark-up language that tells a Web browser how to present a Web page. Writers want their text to do something, and the best way to make that happen is learning how to write for both humans and machines. Some tools, like the popular Markdown syntax and the freshly-released CriticMarkup, aim to make it easier for writers to serve both audiences at once.
Asking another person to read HTML probably doesn’t violate the Geneva Convention, but that doesn’t mean it isn’t cruel and unusual. The language was specifically written for computers, and has become more complicated as the Web evolved beyond basic Web pages and into a place that allows things like Tweetping to exist. Most people don’t have to know how to create a tool like that, but it’s only marginally easier for laymen to understand what a line of code does and why it broke up an otherwise perfectly fine sentence.
Writer, editor, and designer Mandy Brown wrote on this subject for Contents Magazine in a piece titled “Babies and the Bathwater,” which explored how writers, editors, and content have changed and must change with the rise of the Web. Writes Brown:
Content people are fond of leaving the code to the geeks while we debate the merits of the Oxford comma, but there is a difference between programming and markup. HTML, whose own name comes from the editor’s act of “marking up” a text, is an element of the text itself—a machine- and human-readable expression of the text’s underlying semantic structure. This is a language that we can and must speak, because it not only determines how the text looks but what it means.
Which brings us to more bathwater: WYSIWYG-style document editors that ignore the principles of semantic markup or prevent us from engaging with the text completely deserve a path down the drain. We need to adopt the mindset that markup—HTML, in particular—is part of our job, and we need to demand tools that let us do it.
Markdown, the more capable MultiMarkdown, and CriticMarkup are just a few tools working to do exactly that. Each tackles different issues — Markdown is focused on the basics, like adding links, headers, or blockquotes; MultiMarkdown adds footnotes and other high-level wizardry; and CriticMarkup makes it easy to add comments or suggest changes when passing documents back and forth — that would be tedious to add to a document with HTML and makes them easier to incorporate into an article.
Take, for example, that quote from Brown’s article. Written with HTML, that section looks like this:
Here’s the same section, which would look the same to readers if WordPress had native support for Markdown:
Which would you rather read — or write? Neither are particularly complicated, as there isn’t any fancy HTML wizardry going on, but it’s much faster to read and write the section formatted with Markdown than it is the one formatted with HTML.
Most people won’t write either HTML or Markdown (or MultiMarkdown, and so forth). They’ll write in the software of their choice — often Microsoft Word or Pages, from the iWork suite — and, when they want to change the text, push the corresponding button. These tools add a layer of abstraction between what is actually being produced, in many cases (the HTML read by a Web browser and the resulting text read by a human) and, as anyone who has taken a document from Word and opened it in another app can attest, create odd inconsistencies between platforms.
Put another way: Using a WYSIWYG editor to format your content is only “guaranteed” to work with that particular editor. Using Markdown, MultiMarkdown, or CriticMarkup to format your content allows ubiquity, as there are countless apps and services that support the syntax. And even if your preferred text editor doesn’t support Markdown out of the box, it’s non-destructive — at worst you’ll have a few punctuation marks that you’ll need to delete.
Writing isn’t a strictly human experience anymore. Content is “read” as much by a Web browser or application as it is by its intended human audience, and learning how to “speak” to the machine is just as important as learning how to communicate with another human being. Hell, it may even be more important, as a single “>” out of place can wreak havoc on an entire Web page. (Anyone who has seen the PandoDaily homepage when a <b> or <i> isn’t closed knows what I’m talking about.)