Strong opinions, weakly held

Why not just support HTML?

Seems like there’s a little discussion percolating about whether it makes sense to support wiki-like markup languages for formatting text fields in your Web applications or to just support HTML. I took a position in this debate last year. That position was to favor supporting Markdown.

Here’s what I said:

I’ve basically decided at this point that whenever I write applications that allow users to enter blocks of text to be displayed on a Web page, I’m going to provide Markdown support. It follows conventions that people have been using in text-based email for years, it’s unobtrusive if you don’t know what it is, it plays nicely with embedded HTML markup, and it takes care of turning line feeds in text into paragraph tags in HTML. Best of all, text with Markdown in it is not only readable, it’s eye pleasing. What’s not to love? I’ve been using Markdown when posting to this site for a long time now, and have included it in some applications, but my thought at this point is, why not include it everywhere?

I’d stick by all of those arguments today. I like the idea of the raw content of the text fields in my database being readable before and after rendering, which HTML does not provide. Also, Markdown is not incompatible with HTML, so if you want to use HTML you can.

Also, for any sort of text field, you need to convert line breaks into paragraphs anyway, otherwise users who just want to enter a couple of paragraphs of text are forced to bring their own paragraph tags to the party, and that’s never fun.


  1. HTML requires all sorts of finger-contusions to write and rarely looks like what it is, and that’s where Markdown/Textile and the like comes into their own. But I don’t agree with what they render how, and wrote my own text converter following similar, but subtly different, conventions the way I like them. The only advantage of HTML is that it’s a standard – a horrible, horrible standard to write, but there’s a big crowd that knows it.

    Text formatters need to be aware of their audience. Something like Markdown is far far easier to learn and remember, because, for the most part, it makes sense, but if web geeks are your crowd, HTML could be lingua franca enough to be the language you use. And that is, I think, why Spolsky and co. are using it on that website thingy of theirs.

  2. I think you make a fine case for Markdown, readable input is unreasonably overlooked by many other markups. My intuitions only diverge slightly, in how I might convey *bold* and /italics/ in plain text.

    On this site it seems like there’s also some trouble with the title attribute in inline links, and maybe backslash-escaping things, like the asterisks above. But this is hardly a problem so long as your commenters bother to preview their posts.

  3. We’ve used “structured text” in our CMS for years, but I wanted to see if we were missing anything by not using one of the Javascript WYSIWYG editors. While some of them are pretty amazing at what they do, it struck us that by hiding the hypertext attributes behind dialog boxes they made editing that dimension much more difficult.

  4. I agree with no above: Text formatters need to be aware of their audience.

    We use a wiki as the intranet for our entire (~1000 employee software dev) company. I can’t imagine forcing the non-technical folks–HR, payroll, etc.–to learn HTML.

    Anyone can enter basic information on the wiki by using no or little markdown, or by using the WYSI(more or less)WYG editing mode.

    I’ve also noted that one or two people in every department take an interest in learning more advanced formatting. These people become the de facto departmental experts on the relatively simple markdown syntax.

    I’ve seen several instances where one person entered the basic information and then asked the other to spiff it up for them. That seems a nice compromise in cases where the author wants better formatting, but doesn’t want to or can’t learn it himself.

Leave a Reply

Your email address will not be published.


© 2024 rc3.org

Theme by Anders NorenUp ↑