Can Markdown Supply All Your Text Formatting Needs?

Can Markdown Supply All Your Text Formatting Needs?

"It's simple: I'll use Markdown! My (all) text formatting problems solver!"

Is this pretty much the way you perceive this text editor whenever you feel “lazy” and you hate writing all those HTML formatting instructions and tags? Whenever you just want to speed up your text formatting tasks? Well, guess what: it's not that simple!

Moreover, things do get riskily “entangled” and (how ironic!) unnecessarily complex if you venture using the Markdown editing system on more complex document structures! For then what starts like “a solution to all the word's problems” can soon turn into a never-ending source of problems!

And instead of you (or your team of content editors) focusing more on creating content and less on coding, as planned, you end up facing all sorts of unforeseen Markdown-specific challenges.

But What Is Markdown?

Another WYSIWYG-style text editor, used for structuring content according to its content elements' semantic value. And which has been quickly turned into an “all text formatting problems solver” thanks to its ideally easy to read syntax”. This is the very first definition that comes to my mind.

Basically Markdown is the text formatting syntax serving a quite bold goal: to simplify the editor's text formatting work to such extent that he/she can quickly distinguish, on a quick eye scan, all its component parts (heading, paragraphs, lists etc.).

A Markdown-formatted text looks “ready to go live” even before it gets turned into visual formatting.

Here's an “enlightening” example:

  1. HTML-formatted text:
    The little <i>mouse</i> <b>runs</b> <i>past</i> the chubby <b>cat</b>
  2. Markdown-formatted text:
    The little *mouse* **runs** *over* the lazy **dog**  


Which one do you find it easier to read? Well, this is precisely what the Markdown text formatting language tries to solve. And it does... up to the point where you start choosing this type of format for all the “wrong” use cases.

Allow me to me detail:

And Why Precisely Isn't Markdown The Best Format To Use In Most Cases?

Because this often means pushing this format beyond its proper use cases”.

And by “proper usage” I'm referring to using it for formatting text in basic documents, such as README documents for Github. This is why Drupal developers love it: once they're familiarized with its syntax they get to speed write their basic human-readable REAME docs for Github with bullets, lists, bold, blockquotes etc.! Efficiency at its best!

But if you get daring and reckless enough to start using it as a one-size-fits-all-docs type of formatting solution, then... that so very easy to read syntax falls apart in no time!

As soon as you start using them in more complex projects, with body fields that require micro-formatting, captioning, embedding and not just the basic formatting stuff like italics, headings, bold & emphasis, things start to get messy.

... and as prone to error as if you were using the good old HTML for formatting your content!

And, besides using it for all the wrong purposes, in complex structures that call for extensions (which are as “needy” for fine-tuning as raw HTML), here are a couple of other reasons why Markdown is just a bad idea:

1. Markdown Is a Non-Standardized Text Formatting Syntax

So, let's say you'd want to build your own Ghost-powered blog. Then knowing the Markdown specific syntax is not nearly enough. You also need to get yourself familiarized with the specific Ghost markdown.

And all this because the Markdown format is not standardized...

2. Its Overriding Design Goals Don't Include Writing HTML

In other words: don't let yourself swept away by this major “trend” to use Markdown for writing HTML. It's not designed for that!

And here's how you can tell that it's not intended for creating HTML:

  • in order to get nicely formatted written content in your browser you first need to install a tool for converting your .MD into HTML 
  • there's no tool in Markdown for you to use for coloring up your text if you want to

... plus other formatting shortcomings you'll need to overcome as soon as you start using Markdown to create HTML 

And this is anything but “streamlining your content formatting workflow” or focusing more on content creation and less on coding it, right?

3. Codified Text? No Thanks!

So we've got this thing sorted out: the Markdown format isn't meant to help you write HTML.

So what do you do when you're dealing with Markdown formats that incorporate extensions especially for overcoming this shortcoming: writing HTML?

Well, you're faced with some super weird situations like this one here: Ghost Markdown tying to inject image formatting into Markdown. So, in order to do that you need to write this piece of code here:


And there goes the readability advantage down the drain! Imagine that you first need to decode the text and it's just then that you get to actually use it!

In Other Words...

Using Markdown (or empowering your content editors to use it) isn't a bad idea in theory. If it's just plain text that your content creators' editorial workflow includes, then go with it!

Yet, not before:

  • you've pre-configured a nicely deigned appearance (whose settings the editors, too, can control)
  • you've taken your time to properly configure it so that it should fully cover their (the editors') needs instead of being just a “restrictive” vocabulary “hiding away code”
  • you've turned it into a clean semantic editor 

Markdown becomes a bad idea when you're extending its basic role, which is speed formatting basic documents. Then its effectively simple syntax will cause nothing but trouble!