Strong opinions, weakly held

Married to Markdown

Movable Type supports multiple Text Formatters, which convert the entries that you type in to HTML. It comes with a simple one that turns blank lines into <p> tags, and you can add others, like Markdown and Textile, which enable you to use a Wiki-like syntax to add markup to your entries when you’re typing them in.

I’ve installed the Markdown plug-in, and the first thing I discovered when I typed a weblog entry and told Movable Type that it was formatted using Markdown was that my dynamically generated pages wouldn’t work because I hadn’t installed the PHP version of markdown. What I find interesting about this is that Movable Type transforms your entries when they’re presented rather than when they’re saved.

I think my first instinct would have been to do the opposite and add the HTML when the entries are saved. The way it works currently, you’re married to those text formatters. If I want to pull my entries out of the database and use them in some other way, I have to look up the text formatter that’s being used and then run that transformation on my text to turn it into HTML. On the other hand, by transforming your text only on presentation, the tool preserves it the way it was entered so that you can easily go back and edit without wrangling with the HTML that was inserted. Interesting design decision, but upon reflection I think I agree with it. Most people want their input preserved more than they want to futz with the contents of their Movable Type database.


  1. We made the same decision when we added Textile (and JSPWiki, and Radeon) support to Roller: you “preserve” the ease of editing by postponing translation to display time.

    Note that this also makes it possible for you to switch translators if you like; Markdown/Textile/JSPWiki all overlap at some points (dunno about Radeon myself).

  2. My recommendation would be for MT to store entries twice in the database — once in editable form, and once in output form.

    User -> Editable Form -> (Translation) -> Output Form -> Page views

    That way you’d only have to translate to HTML (from Markdown, or Textile, or whatever) once, each time you create or save an entry. Whereas in the current setup, you end up translating once for each page view (with dynamic publishing), and you need to have both Perl and PHP versions of each translator (if you want to use dynamic publishing).

    The only downside is that you’d be using about twice the space in your database for each entry body, but, so what? Disk space is cheap, CPU time is expensive.

  3. There’s of course always the alternative of just saving both. One – for when the users wants to go back and edit the entry, and the other for display. The greatest benefit for fully dynamic weblogs (serving dynamic pages) is speed, but for MT I guess it doesn’t really matter all that much.

  4. Does Moveable Type support larger typefaces? 😉

  5. Yes, it definitely supports larger typefaces. The tiny default font associated with these templates is a great annoyance to me, and I promise to fix it soon.

Leave a Reply

Your email address will not be published.


© 2019 rc3.org

Theme by Anders NorenUp ↑