The purpose of XHTML and CSS is two-fold.

Firstly, to allow the developer or designer to control the structure and layout of a site, and secondly to style or format content.

The structural bit is the responsibility of XHTML and the job of formatting and style falls to CSS.

The past several years have seen a lot of work in this area. From those efforts we have the emergence of standards based on CSS and the formalization of HTML as an application of XML. Combined, these technologies make a solid architecture for publication, they're terrible authoring or writing tools. They're just not simple enough for the job.

• The syntax is (necessarily) formal which results in a lot of overhead. Far too much for efficient writing.
• While complexity helps a markup language to be expressive and precise it leads to a laborious and error-prone writing experience.
• Syntax errors break the interpretation of the markup and detract from content.
• The burden of slogging through syntax discourages content creation.
• Mistakes in syntax with XHTML tend to cascade through documents in odd ways causing unexpected and often difficult to diagnose problems.
• Noisy markup distracts from and complicates writing and editing. Working with XHTML directly, it is not unusual for the amount of syntax to exceed the content itself!

For these reasons various lightweight markup languages have been developed for the purpose of presenting a minimal syntax intended to facilitate a more natural style of writing. These languages are typically implemented as both a syntax and a program capable of translating between its own grammar and XHTML.

These are intended to address many of the problems associated with writing on the web by:

• Simplifying plain-text formatted (source) documents so that they are as readable as possible, even without being converted.
• Encouraging the appropriate use of formatting to improve the readability of the resulting XHTML as displayed in the browser.
• Avoiding the problem of mistakes cascading through a document. Broken syntax simply does not translate and does not disturb the rest of the document.

The unofficial but preferred syntax for Ode is Markdown. There are a few alternatives, most prominent among them, Textile, which is another very nice implementation of a lightweight language.

So why Markdown?

Because more than the others, Markdown emphasizes readability of the plain-text document and that seems very much in agreement with Ode.

The other reason to choose Markdown is that it is written first in Perl and Ode is itself a Perl app.

Is this a big deal? Are we limited only to Perl when working with Ode?

No, but keeping as much of what is distributed with Ode in Perl will simplify things for new developers (more on development later).

I'll let the author of Markdown explain its advantages and raison d'être:

Markdown is a text-to-HTML conversion tool for web writers. Markdown allows you to write using an easy-to-read, easy-to-write plain text format, then convert it to structurally valid XHTML (or HTML).

Thus, “Markdown” is two things: (1) a plain text formatting syntax; and (2) a software tool, written in Perl, that converts the plain text formatting to HTML. See the Syntax page for details pertaining to Markdown’s formatting syntax. You can try it out, right now, using the online Dingus.

The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. While Markdown’s syntax has been influenced by several existing text-to-HTML filters, the single biggest source of inspiration for Markdown’s syntax is the format of plain text email.

Does that mean that you're stuck with Markdown?

No, Markdown is implemented as an addin. You're free to replace it with some other syntax using Ode's addin architecture (more on addins and development later).

It does mean that Markdown will always be distributed with Ode, that you should expect Markdown to work, and discussion of Markdown is considered relevant to this project.

In addition to Markdown, posts support HTML. Just keep in mind that they are contained within a larger page structure. So for example a body tag () should never find its way into your posts.

Next (Simple Content Management)