12.12.11

Markup

This is the second in a series of articles that expand upon my essay in Issue No. 1 of Contents. Read the first.

In the second part of my Contents article, I argued content people (editors in particular) need to know markup. If you’ve been designing or developing websites for a while, then you’re already familiar with web standards’ key tenet: the separation of content from presentation. If you are coming from other fields (say, journalism or old-school publishing), let me explain.

In print, the designer has a certain tyranny over the page. She sets the text, and the reader has no choice but to accept that design. The content (i.e., the text) and its presentation (the typefaces and layout) are inextricably linked.

On the web, the designer again sets the text, but this time her choices are not immutable. The reader (or his device) can modify those designs as needed. For example, he can set the font size to be larger in his browser, or he can specify a font that he feels is more comfortable. He can load the page on an iPhone where the text is reformatted for a smaller screen; or he can use a screenreader to read the words aloud, ignoring the visual styles entirely. The content and its presentation are related, but that relationship is tenuous, easy to break.

This is what we might call a very, very good thing. It means the text is more accessible—to different devices and (most importantly) different kinds of people. It means the reader has more power over the text than the designer has (as it should be). And it confers a great deal of flexibility on the text itself: freed from presentational concerns, it can be read in any number of contexts or devices. The design can change, and the content will continue to work as intended.

This marks a shift in what an editor’s markup does: because a lot of pen-on-paper markup was presentational. Noting wrong fonts, inserting hair spaces, setting in bold, etc., were common reasons to markup a text when working in print. Now that content and presentation are separate, however, markup takes on another dimension: not instructions for style, but defining the underlying semantic meaning of the text, such that any number of visual styles can be intelligently devised.

What does this mean in practice? It means instead of noting that a heading should be larger, you mark it as an <h2>—a second-level heading in the article’s hierarchy. Instead of requesting that some text be indented, you mark it as a <blockquote>, indicating the text is an excerpt. And so on: in every case, you concern yourself with the meaning of the text, not how it looks.

Think about that for just a minute, and it becomes clear that this is a much better way of doing things. Visual styles (as important as they are) are always in service to the meaning of the text. Working with markup on the web brings you closer to that meaning.

Alas, many of the tools we use to author content for the web continue to reflect the old, print-based perspective. WYSIWYG (“what you see is what you get”) document editors impose a presentational view of the text, with little regard for its meaning. Worse, they frequently produce sloppy or incorrect markup (often hiding this dirty work from you), preferring the facade of visual styles to the underlying reality.

It’s time content people of all stripes recognized the WYSIWYG editor for what it really is: not a convenient shortcut, but a dangerous obstacle placed between you and the actual content. Because content on the web is going to be marked up one way or another: you either take control of it or you cede it to the software, but you can’t avoid it. WYSIWYG editors are fine for amateurs, but if you are an editor, or copywriter, or journalist, or any number of the kinds of people who work with content on the web, you cannot afford to be an amateur.

Fortunately, there’s a plus side to all this: HTML is easy to learn. Even if you never peeked at the source for a website, never so much as authored an anchor tag, you already know most of the principles behind it, because they emerged from the texts themselves. You do need to learn a new syntax—a new way of expressing what the text means. But syntax is where editors excel.

One of the principles of HTML’s development as a language is “pave the cowpaths”; meaning, look at how people are already doing things, and adopt those methods, rather than trying something wholly new. Many of HTML’s original cowpaths were paved by writers and editors, long before the web arrived. Paragraphs, headings, blockquotes, articles, ordered and unordered lists, and so on, all emerged from age-old ways of working with text. Now new cowpaths are being paved on the web itself, and we need the people who love the text the most to get involved in where we go. We need you.