Hacker News Reader

Comment by ams6110 | Hacker News Reader

I don't like any of them. Markdown, ReST, various wiki/forum dialects of "simplified" text formatting. They are all as complicated if not more complicated than just writing HTML. They all have a bunch of rules and special cases. I'd rather just write in HTML which I already know.

I don't understand the motivation for any of these "alternative" markup formats. Normal non-technical people want Word (or at least, some kind of WYSIWYG text entry). I've been on projects where they tried to get non-developers to use ReST and it was an abject disaster. The tech writers revolted and refused to use it. So then a developer had to be sidelined to convert their Word documents to ReST so that we could produce HTML.

Yeah HTML is not perfect, but neither is any of these other markup languages. If you like one, fine, but don't wonder why none of them has really caught on outside of small niches of highly technical people.

View on HN

> They are all as complicated if not more complicated than just writing HTML. They all have a bunch of rules and special cases. I'd rather just write in HTML which I already know.

I find that Markdown is significantly easier/faster to write than HTML and, more importantly, easier to read in its un-rendered form. To me (and presumably lots of other people, given Markdown's ubiquity) it's well worth learning the relatively small syntax.

Edit: Here's a quick comparison with a README.md from one of my projects:

Rendered: https://github.com/cespare/reflex/blob/master/README.md

Markdown: https://raw.githubusercontent.com/cespare/reflex/master/READ...

HTML: https://gist.githubusercontent.com/cespare/ad6c41aa28583cac8...

Three things I notice from this example:

- The verbosity of an XML syntax with HTML is annoying, particularly the need for closing tags. <code>xyz</code stands out as particularly verbose (compared with `xyz`).

- Having to escape certain characters like & makes this HTML sample harder to read (this is more of a problem with technical/code documents).

- Automatic linkification prevents stuttering: <a href="http://example.com">http://example.com</a>

I haven't seen it used outside of Rails apps, but have you ever tried Slim? I understand there's a similar tool for Node.js called Jade.

http://slim-lang.com/

  table
    tr
      th Col1 Header!
      th Col2 Header!
    tr
      td Col1 Value...
      td Col2 Value...

Renders to HTML.

Slim/Jade/HAML etc are templating languages, they're not designed for writing text at all - they're almost the opposite of markdown et all.

I wouldn't say they're the opposite of Markdown, but that's not really the point I was getting at anyway. The poster I was replying to was saying that two of his issues with using HTML to write documents were the verbosity and the escaping. Slim solves those two issues.

Ah, apologies, point taken. Note that most of that style of templating language include markdown filters as well - so you drop :markdown in, then just write a block of text, works really well.

Not all markdown text is written with the intention of being converted to HTML. Pandoc can convert markdown to .pdf (via LaTeX), .doc, a slide-deck (using either LaTeX-Beamer or one the HTML presentation tools) etc.

Compared to LaTeX, markdown markup is less obtrusive: a single asterisk/double asterisk/double backtick interrupts the flow of text less than an \emph{} or \textbf{} or \textit{}. Since there's less noise, it's easier to proofread and edit the source document. [The same is true for HTML vs. markdown]

Compared to LaTeX, markdown markup is less obtrusive:

Indeed, I use pandoc for making LaTeX beamer presentations and it generally provides the goodness of Markdown and LaTeX combined. Slides can be made far more quickly than in LaTeX. E.g.

    # Some section slide

    ## Slide title

    * Bullet point one
    * Some math: $a^2 + b^2 = c^2$

At the same time, one can e.g. immediately insert fragments of TikZ using the relevant \begin{...} \end{...} block and it just works.

~10 years ago I introduced Textile markup at our student newspaper and they're still using it. Nobody complains about it. Some people write in Word first and then add the tags, but most writers just use the tags right away.

You're free to argue that these markup languages all suck, but this idea that it's impossible to get "normal people" to learn even a little bit of syntax, is preposterous – what about twitter #hashtags and @replies?

I'm a software developer, that is to say a technical person, but I don't really know HTML (well, other than a few basic tags) because, like most developers in the world, I don't do web development, and what I do know of HTML, I don't particularly like, certainly not for writing.

On the other hand, I find Markdown (or ReST) easy to learn, to write and to read.

As to being a niche, there are probably around 20M software developers in the world (probably only 10-20% of them doing web), and several times over of other kinds of technical people. So even a markup language that only targets technical people who are not web developers would be addressing a few tens of millions of people. A niche for sure, but far from a small niche. These markup formats certainly cater to many more people than, say, Ruby or Python.

I agree, I beauty of markdown is any layperson can read it while HTML in-spite being easier for web-developers is not the best tool to write documentation.

So much this.

Normal non-technical people understand that you click a bold 'B' and you get bold text, you click an italic 'I' and you get italic text, you click a little list icon and you get a list, and so on.

contenteditable has its quirks, sure, but modern browsers mean it's no longer the brainmelt it once was. Real WYSIWYG entry is achievable and almost easy. Markdown has one great usecase (producing documents that are viewable both as plain ASCII and as 'compiled' rich text), but it's not a tool for Joe Normal.

Non-technical people learned WYSIWYG and they can learn something else too.

1. Users don't have the manual, and if they did, they wouldn't read it.

2. In fact, users can't read anything, and if they could, they wouldn't want to.

http://www.joelonsoftware.com/uibook/chapters/fog0000000062....

Reply on news.ycombinator.com