I found this scathing denunciation of wiki-markup via Mark Pilgrims' b-links. Seeing as I've spent the last few months writing a product that uses Wiki markup as its basis, I thought I might come to the markup's defense.

Thanks to a worldwide effort that could have built the Great Wall of China at least once over, there is a single system for text markup [HTML + XML] that is regular, full-featured, and mature.

Well, that's my first objection. HTML is only regular if you stick to a single browser (and avoid points of contention like the <q> tag), only mature if you ignore the fact that the various XHTML working-groups are busy uprooting large parts of the spec because they're considered dead-ends, and only full-featured if you define "full-featured" as "doing all those things that HTML allows you to do."

How do you write a magazine-style multi-column layout in HTML? You don't. Do you miss it much? No, not really, because the web really isn't that well-suited for that kind of markup. In a similar way as a wiki really isn't suited for most of the more complicated things you can do with HTML.¹

Wiki markup solves a set of problems that are important for Wikis to solve:

1. Pages are editable solely in the web browser, not requiring any additional software to be installed or called up for editing.
2. The page in the text area gives visual clues as to what the finished page will look like: bullet-points look like bullet-points, and the various kinds of inline emphasis look like the sort of thing we've been using in email for years.
3. The markup is simple enough that it can be described very quickly. The important parts of Confluence's markup can be described succintly in a side-bar on the edit page.
4. The Wiki doesn't have to worry about defending itself against the latest Cross-Site Scripting technique or whatever markup crashes Internet Explorer today.

These are important. The point of a Wiki is to reduce the barrier between viewing a page and editing it. Wikis are about ease of contribution. The more obstacles you put between viewing and editing, even small ones like having to fire up an editor, the less likely people are to edit. You have to enable editing in the same application that is being used for browsing, and since people already grok and enjoy browsing their hypertext in a web browser, that's where we have to be.

Sure, you end up with something that's significantly less powerful than HTML. This is a feature. A wiki page isn't a place for complicated markup, it's for writing stuff down. The more power you put in the markup language, the more people are going to be wanking around with the precise arrangement of angle-brackets that will make their paragraphs step from left-to-right in pixel-perfect harmony... in lieu of saying something.

HTML is a language designed for machines. It sucks for people to read, and sucks for people to write. This page contains a good sample of the HTML source for some content side-by-side with the Textile-based Wiki markup. The latter is far easier to read, and believe me it was far easier to type.

The real answer, as far as I can tell, is that when dumb textareas are the only user interface a Wiki provides, then the expressiveness of full HTML is too much for the average user, or even the lazy advanced user. Somehow that doesn't lead me to believe that the answer is to twist the world to fit into a textarea. Look at SubEthaEdit. All over the world Mac weirdos are editing the same document simultaneously. The magic isn't found in using some broken punctuation-based markup. (And, no, the magic wasn't within you all along, kid.)

"The expressiveness of full HTML is too much..."? I would say that the verbosity is too much, the complexity is too much, and the way it obscures what you're actually writing in a mess of angle-brackets is too much. And GUI editors don't help. The only GUI HTML editors that are fully-featured enough to harness "the expressiveness of full HTML" are authoring applications firmly targeted towards professional web designers. The ones that are simple enough for Joe Word User to get into are either on the same level of expressiveness as wiki-markup, or they produce something that doesn't remotely resemble HTML, or both.

We've had dedicated, specialised networked collaboration software before, albeit not with SubEthaEdit's immediacy. Interestingly enough, it's exactly that sort of software the people are moving to wikis from.

Against a collaboration software that combines the expressiveness of HTML, simple, intuitive WYSIWYG, the seamless networking of SubEthaEdit, all wrapped in a package that people actually want to use regularly, we have wikis. Wikis have the advantage of... well... existing. They also take advantage of the fact that most people already have a web browser¹, know how to use it, and with a minute of pointing can be shown enough markup to make a meaningful contribution to a document.

¹ And how about footnotes? Or image captions? Or a combo-box control? Or all the other things missing from HTML that have to be retrofitted through obscure CSS hackery, if they can be retrofitted at all. Full-featured my arse. Reasonably full-featured, I'll accept. For its domain. Mostly.
² Of course, if you want to install additional software to get a better editing/navigation experience, you can.