Hacker News Reader

Except it sucks when I have to go to the docs for the 10 different flavors of markdown 10 different sites I go to use (assuming they have docs). I also have to spend time documenting my own site when I incorporate markdown.pl versus markdown.py versus some other markdown implementation.

Markdown has become popular enough that a complete, unambiguous spec is good for end-users. If you are building a little text entry thing for your mp3 catalog app, sure, it's nothing to worry about. But when you are github and stackoverflow and google, and end-users are authoring documents, knowing the behavior matters.

Yeah, but it doesn't define how markdown will be rendered.

For example, on github, to get a decent paragraph title, I must use #### (h4), on some other site that might be h1 or h2 to get the effect I want.

I understand the need to define the grammar precisely, but for me Markdown is highly tighten to the site it will be rendered to.

I'm not against a specification, but I feel this is a lot of work (and again I'm not saying it's badly done) that feels unnecessary.

Taking your google example, they might deviate from the syntax because their comment box is too small. I really don't want to argue, it's just some feeling, it might not be rational, and by all means I'm not saying I'm right. I was expecting (and waiting for) specifications for tons of things, but not markdown.

    > I mean, who cares of those little differences? 
    > When I edit a comment or something, I just hit 
    > the preview button (or see the preview real time).

That's actually a common example of when those little differences matter: when the client-side markdown implementation (preview button) doesn't line up with the server-side implementation (render).

There's nothing to lose by having a standard. Most markdown libraries I've used let you configure between various flavors of markdown. I'd love to enable "Standard Markdown mode" on two different implementations that need to produce the same output and be done with it.

You're assuming you would never want to use the same markdown on different sites. As soon as that happens you discover all sorts of weird cases and ambiguities.

I don't think this standardization is meant to stop sites from adding their own extensions, it is to make sure that the core markdown always looks the same, no matter which site/parser is being used.

Actually I think there are some reason to have slightly different markdown flavors depending of the context. Take the "indent 4spaces for code" thing, on a social website this might have a completely different meaning.

You will say, OK then, but this is not markdown, you'd be right, it'd be some markdown inspired markup, and that's my point, this specification might be relevant to github, and it is, but don't call it standard markdown, call it anything else.

Markdown wasn't designed for the purpose "standard markdown" is giving to it now. Alright, do something new, get traction, but putting markdown in a box doesn't seem to be the best approach to me.

There's room for extensions, but as for base functionality, I for one do not enjoy trying to remember whether a given site uses [links](http://like.this) or [links|http://like.this] or preformatted text ``like this`` or {{like this}} or <pre>like this</pre>...

think of standard markdown is an interface. you still can `implements` it and add more specific feature.

I was a bit harsh, let's see what it becomes.

I still feel that if you write a standard, you should cover some important missing features, like:

- Referencing other parts of the document - Image caption (figures), and figure references

Of course, this list should be discussed, but there is room for improvement.