Friday, October 28, 2011

Don't be such a lightweight

I like the concept of lightweight markup languages. All of them tend to have the same goals:
  • Ability to edit with any text editor
  • Human-readable without a special program
  • Easily convertible to other formats (HTML, etc.)
These are theoretically laudable targets to aim for in terms of maximum interoperability and ease of creation.

But...

I just can't find one I like. Each has something that bugs me, but in general all of them fall down in the following ways:
  • No support for underlines - they all support emphasis and strong emphasis (or italics and bold, as most humans think of it), but few seem to support underlining. It is not like _underlining_ could not be represented in plain text.
  • Weak support for hyperlinks - or more accurately, all of them require special syntax to associate a URL with a block of text to be used as the description of the link. I could go into why I could call their bluff on this point alone, but will leave that for another post.
  • There sure are a lot of them - and all of them have different syntax, although a few of them are a bit alike...as long as all you want is a couple of levels of headers, simple lists and no hyperlinks or anything else.
  • "Simple" syntax only goes so far - even the simplest of lightweight markup languages end up having quite a bit of syntax. A lot of syntax, actually, if you are a non-technical person.
But that last point's a red herring because let's face it - a non-technical person is going to use Microsoft Word and be done with it. Arguments about "open source," "text editors," "maximum interoperability" and the like are not going to make any sense to them. If they want something to be bold they simply hit Ctrl-B and it's bold. How simple is that?

In the end while I like the idea of lightweight markup languages, if I am going to have to learn yet another markup language then I am at least going to learn one that is directly usable by most WYSIWYG editors. And if I am in a WYSIWYG editor, since I am not so much a purist about open source as much as I am something like widespread interoperability I am probably not even going to expend that much effort. Instead, I will choose something like RTF, which has plenty of open source implementations even if the spec itself is proprietary, and be done with it.

In fact, the more I think about it, the more I think most lightweight markup languages are simply an affectation by coders who live all day in emacs or vi and seem to think that since they program in that environment they should do all writing there, too. Because they're too proud to Alt-Tab or ⌘-Tab into a real word processor, I guess. If this were still the era of punched cards they'd be arguing we should be writing our letters to Grandma with Hollerith codes as well.

Me? I think I'll stick with Ctrl-B, Ctrl-I, Ctrl-U and the likes and be a mere mortal because I like to see the text formatted the way I want it to look now, and not in some intermediary form that then has to be run through yet another program to be made presentable. That smacks of SCRIPT/VS, the first markup language I learned in 1983 or so. But I'm lazy, I know. If you're happy creating tables using | and + and - in vi, go for it. The world has room for both of us.
BlinkList Delicious Digg Facebook Furl Google Bookmark LinkedIn Mixx Reddit StumbleUpon Technorati Yahoo

2 comments:

ccjjharmon said...

We have a few internal things built around using custom wysiwyg editors (our intranet has it), but problems arise when users write up copy in Word, and paste in the content ... because Word generates such horrendous HTML. Every once in a while (e.g. every few months), we have to manually fix the HTML because there's just no way for them to do it.

Ug.

Jim said...

Chris,

I understand completely. Is that including with Word 2010s new "simplified HTML" (which still isn't that "simple")?

I think in the end the issue I have is that some sort of nod has to be made for the ultimate medium or media, and depending on what that is, then the appropriate tools should be used. I note that almost none of the lightweight markup languages are that well suited for print (not if you care about ultimate layout), and most of them aren't really that much better suited for the web (in anyway way that ends up making them better than HTML itself).

I found one post, I am going to have to dig it up, of someone documenting "lightweight HTML," and that really resonated with me. In other words, use something that already exists, is already useful, already has widespread tools support, already has widespread format conversion support, and be done with it.

But that's just me. :)