What It Is, Not What It Looks Like

Web-based Text Editing

Website owners and managers need a simple way to edit the text within their websites. They need to add headings, make bold text, bulleted lists, and so forth. It's a fundamental need in Content Management implementations, and perhaps the most used feature of any CMS.
In spite of this, the solutions widely available today are horrible. JavaScript editors tend to be buggy, generate bad HTML, and produce inconsistent results between browsers. Requiring clients to learn HTML doesn't work. Often, they'll just say no... and even if they're up to the task, the website will almost certainly end up with broken code. Asking the marketing manager, department head, or whoever to learn HTML is a bit of stretch in the first place -- they just shouldn't have to.

Promoting Poor Habits

Even when JavaScript editors work well, they allow -- even encourage -- bad practice. Clients start thinking that a line of text needs to be just a bit bolder, or a slightly different color, or have more padding. With JavaScript text editors, they can make those changes. Moreover, the fact that the text editor is a WYSIWG, and visual in nature encourages those changes. Clients start focusing on what the text looks like, more than what it is. What starts as an exception or two often becomes widespread inconsistency. Extraneous tags (extra line breaks, span tags, or even font tags with color attributes) creep in.
And this, of course, impairs the quality of content. When tags are added to a particular piece of content to solve specific, isolated design goals, that content looses its ability to be used in broader applications. Then there is the issue of future redesigns. A few years ago, we were looking with a client at a simple redesign for a website and CMS upgrade; the biggest hurdle (and demise of the project) were the countless pages of text littered with font tags, extra paragraphs, and left-over classes pasted in from desktop word processors.

Example

A recent example involves a Drupal CMS multisite implementation providing a centralized admin environment for two distinctly different websites. We originally used TinyMCE, a JavaScript text editor, that was configured to use the visual style from the first website long before the second was ever launched. Headings are Georgia, and blue. Sub-headings are Arial, also blue. Bullets are simple discs
In the second website, though, the styling is different. We used background gifs for ornate bullets, and sub-headings are Georgia and gray.
We discussed the option of styling the editor to match the second site when content was published there -- but what about cases where content might be used in both places? What if the contributors had no idea where their content would be published, and were simply given a subject and tasked to write?
The problem became clear. Using the JavaScript WYSIWYG editor, contributors focussed on appearance rather than structure. This was confusing, particularly with the introduction of the second website.
So we began talking about thinking of content in terms of what it is, not what it looks like.

The Solution

As I mentioned above, requiring clients to learn HTML isn't realistic. And I've explained our problematic experience with WYSIWYG editors. We wanted a tool that doesn't require HTML experience and allows clients to edit text easily and perform simple formatting, while maintaining an emphasis on structure rather than presentation. So we've moved to a solution that uses simple formatting codes to add structure to text.
We use Markdown.

What is Markdown?

According to Wikipedia:

• Text with Markdown formatting
  Headings read like headings, lists like lists.
• Same text, transformed to HTML
  Markdown transforms perfectly to semantic XHTML. Additional formatting can be added where it should be, in a CSS file, and can be easily altered for various unique applications.
• HTML output, showing HTML source code
  Notice that HTML code doesn't improve the legibility of the text. It doesn't read well, doesn't add meaning - or structure - to raw text input.

Markdown was originally developed by Gruber and Swartz as a software tool written in Perl, and can be downloaded from John Gruber's widely read website, http://daringfireball.net. An excellent PHP port was written by Michel Fortin, and is available for download at http://michelf.com/projects/php-markdown/. The Drupal module, built on Michel's PHP port, is available at http://drupal.org/project/marksmarty. Many other publishing tools have their own implementations.

What Clients Think

We have used Markdown in most of our CMS implementations. So far, there has been very little resistance. Those clients that may have resisted the idea at first typically embrace it once they actually use the syntax. Several clients have actually opted to switch, even in cases where we started them with a JavaScript WYSIWYG editor. Markdown is incredibly simple to use, helps avoid the problem of broken (or just bad) HTML creeping into content, and offers flexibility when it is needed.