8 ms·

I don't really see the point of this. Being vague is one of the biggest strength of Markdown. Markdown is being used by very different products to fulfill diff

by kuon 12y ago

I don't really see the point of this. Being vague is one of the biggest strength of Markdown. Markdown is being used by very different products to fulfill different requirements. Having no specification means you can inspire yourself from Markdown and just do your own thing, which is what is relevant. Markdown is being used by comments systems, issue trackers, documentation programs. Those have very different needs, and having a liberal non-specification is what helped Markdown to be popular. Coming with a new standard, not called "Standard Markdown" (which I think is very presumptuous, even for a big company) and providing new features (arranging/aligning images, variables, include, mathematic notation...) would have been much more productive. 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). I'm not going to learn a specification, and if markdown has to look different on stackoverflow or github or <insert doc system>, so be it. Markdown is also mean for people who have no idea what a "syntax error" is, I know the specification is meant for implementations, good, but if I want to write an implementation, I want it to be fast and this kind of complicated spec is exactly what prevent me from writing something lighting fast. I'm really sorry, I don't want to insult your work (which is great), but it looks like a waste of energy to me.

SoftwareMaven 12y ago
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.
- kuon 12y ago
  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.
njr123 12y ago
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.
- kuon 12y ago
  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.
  - pimlottc 12y ago
    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 http://like.this) or [links|http://like.this http://like.this] or preformatted text ``like this`` or {{like this}} or <pre>like this</pre>...
danneu 12y ago
> 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.
tuananh 12y ago
think of standard markdown is an interface. you still can `implements` it and add more specific feature.
- kuon 12y ago
  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.

by kuon 12y ago

SoftwareMaven 12y ago

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.

kuon 12y ago
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.

njr123 12y ago

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.

kuon 12y ago
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.
- pimlottc 12y ago
  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 http://like.this) or [links|http://like.this http://like.this] or preformatted text ``like this`` or {{like this}} or <pre>like this</pre>...

danneu 12y ago

> 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.

tuananh 12y ago

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

kuon 12y ago
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.