I'm a little surprised at the level of negativity in the majority of the comments here. I understand our cultural need for criticism here, but the critics here have touched almost everything (and note that the most insubstantial of claims have bubbled up to the top of the comments here):
Naming [2] [5]
Closed (initial) development [1]
Lack of formal grammar [3]
Lack of tables [4]
Just use another format (e.g. asciidoc) [6]
Ambiguity is a feature [7]
Can we please take a moment to appreciate the achievement here? As opposed to fulfilling our own sense entitlement?
Markdown is a popular language with an ambiguous, poorly specified spec and buggy default implementation (so buggy that the vast majority of Markdown users have probably never used it, if they even know it exists). Now, we have a much more well-specified English language spec that explicitly addresses the challenges of the grammar, with a test suite that does a much better job of covering the corner cases, and much better default implementations. These improvements are by no means perfect, but they are improvements.
Yes, we need a formal grammar. Yes, we need tables, and other features. Yes, the naming is unfortunate, though frankly I don't feel sorry for Gruber given that Atwood posted a public letter calling for change two years ago. Yes, these are all issues. But it is an achievement nevertheless, and let's celebrate that.
And then we can get back to work.
----
More generally, I think we have issues with entitlement here on HN. Frankly, we have no fundamental right to either the original Markdown or this new version. But when posts like this come up, we hack away at them as if we had a right for better, as if the authors should be working to please us personally. We need to stop acting like we have a right to sentence judgement over what others release as open source.
The problem is that there's no formal grammar and the spec of "Standard Markdown", while being more specific than John Gruber's, is still full of ambiguities.
Some examples of ambiguities:
1. It does not specify precedence. For example, if a line like "~~~" (or "[ref]: /url") is followed by a setext underline, is that a header, or is that the start of a fenced code block (or ref definition)?
2. The spec says: "Code span backticks have higher precedence than any other inline constructs except HTML tags and autolinks". It says as an example that "<a href="`">`" is a HTML tag. What happens for different placement of backticks, like "<a `href=""`>" or even "`<a href="">`" is left unspecified.
3. What is the precedence or associativity of span-level constructs? For example, does "<asterisk>a[b<asterisk>](url)" result in "a[b" being emphasised or "b<asterisk>" being linked?
Thing is, a specification-by-example like this would have to keep an ever-growing list of corner cases and give examples for each of them. To get completely unambiguous, the list needs to be very long, and when it gets very long, it becomes unwieldy to handle for an implementer of the spec.
Hence the need for a formal grammar, which is the shortest way of expressing something unambiguously. But it's not possible to write a CFG for Markdown because of Markdown's requirement that anything is valid input. So the next best thing is to define a parsing algorithm, like the HTML5 spec. (Shameless plug: vfmd (http://www.vfmd.org/) is one such Markdown spec which specifies an unambiguous way to parse Markdown, with tests and a reference implementation.)
So if "Standard Markdown" is NOT unambiguous and wouldn't be, then it's not a "standard", so calling it "Standard Markdown" is not quite proper.
So you equate criticism with entitlement. Too bad.
Criticism is valuable. If I release anything into the public, I expect criticism. Heck, I even look forward to being criticized because it means people care about what I did (even if I did it wrong!)
"Neither the name “Markdown” nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission."
It's a total breach of license, and on a fairly standard BSD too.
I'm seriously getting tired of copy-pasting this, and surprised that ya'll are defending this whole thing. but I guess I shouldn't.
Anyway, I better jet before I start trolling. In the end, I'm ok with making a better markdown, but completely opposed to breaking the law.
<em>Markdown is a popular language with an ambiguous, poorly specified spec and buggy default implementation...</em>
That never hurt Perl... :-) Sorry, couldn't resist.
Your sentiments are well-taken.
No one "owns" Markdown, and quibbling over words is unproductive.
There is a concept: "a simple in-line markup language that is easy to write and maps clearly to HTML". One instance of that concept is a specific, buggy, ill-defined language called "Markdown".
"Standard Markdown" is another instance of the same concept. This is the way English works: adding modifiers to words that designate one instance of a concept to designate other instances of the same concept.
Getting to an EBNF grammar from the spec would be awesome, but the spec is a great place to start. All spec generation is tendentious, and it is common to have multiple people highly invested in the generation of different specs for the same nominal standard. Politics, as Aristotle tells us, is the master art. This is why.
The important thing is that you managed to feel superior to both camps, that's what matters. Criticism is criticism, take it for it's merit, not because it hurts people's feelings.
This is really great, but I don’t understand why everything has been made privately. Following the first post [1], people were waiting for a move, and as far as I know, it was a complete silence during two years, not even a “we are working on it”.
A Markdown Community Group [2] has been created on w3.org, and people have started to push some effort in it [3][4][5], but it has been totally ignored since the beginning, despite the communication attempts.
Maybe I don’t have all the informations, but it looks like a waste to me, and I find it disrespectful for the people who worked on the project. All of this could have easily been avoided with a simple communication about the status of the project.
On the flip side, developing a spec---for something as popular and accessible as Markdown---out in the open is an extraordinarily difficult task. I think one can definitely make a case for it being the right thing to do (and I mean that in more than just the ethical sense), but I also think one can make a reasonable case for not wanting to travel down that road either. I think it can be so difficult that there would be a very real possibility that it would never get completed.
(I'm sincerely not trying to be combative. I know I'm not really addressing your point---that they didn't even provide a status update---but I just wanted to provide a tiny perspective on the other side of the coin.)
Since when competition has become disrespectful? This is simply a degree of fault tolerance, ensuring that at least one of the two working groups would succeed.
Is there a formal grammar defined? I don't see one here. They mention peg-markdown which does use a formal grammar - or at least, multimarkdown does, which is the one I've looked at.
It's littered with implementation code, but with this stripped out it would make a good basis from which people can write parser generators from (that don't depend on the specific implementation details of MultiMarkdown's internal representation).
As far as I'm concerned, a formal definition should be an absolute requirement for any official spec. The "spec" as presented simply looks like a large collection of examples, informally specified in prose.
What's really needed is a grammar you can use for parser generators, corresponding to a schema for an object model.
It's late here, I may have missed something, so feel free to correct me if if this is the case ;)
Nicely done, and needed! But pretty much everyone I know who has used markdown has wandered into the swamp that is known as 'tables of despair'.
Michael Fortin's syntax is pretty useful and quite close to the spirit of Gruber's original efforts. (who hasn't done ascii tables with | and - right?) Until tables are 'standard' I do not hold out a lot of hope for widespread adoption.
That said, I really love taking it Markdown to this next level. And am moderately amused by the recurrence of the themes over time. I'm a old RUNOFF user from back in the day.
I'm super excited that JGM (of Pandoc) is heading this and has some cooperation from Github and Reddit (both the largest users of Markdown that I'm familiar with). This is something I've hoped to happen for a long time.
To an interested outsider the appearance of MacFarlane's name in the list gave this instant gravitas. As the builder of pandoc he has to have the widest, most detailed knowledge of markup syntaxes of about anyone.
Given that, the lack of a formal definition is even more surprising: why did they not spec it in Haskell? Formal, unambiguous, and as a side benefit, executable.
Now if anyone can get the Facebook Phabricator Phriction wiki pholks to use it... They invented one just their own, differing on even the most basic things.
How about a minimal set of asciidoc markup that gives people whatever warm feeling they get out of markdown, but has the benefit of being pretty consistently specified, allowing you to set variables (like multimarkdown), and allowing you to create finished documents in the same style in which you created your scratch documents?
The warm feeling I get is that it's the syntax I use all day on reddit and GitHub. The syntax could be a mixture of Perl, non-printing characters, Emoji, and a Turing-complete sublanguage, and I'd still use it.
Familiarity trumps all other merits. The easiest language to learn and use is the one I've already learned.
The appeal is twofold: a lot of engines now understand it and it is (relatively) easy to write by hand. (Except for the bloody links, writing the HTML for them is much easier than the equivalent markdown, I do it infrequently enough that I always mix up the brackets or the order (or both...).)
Just look at the @markdown timeline, though. That is one of two tweets ever made. The last one was "23 May 2011". It is a bit passive agressive, IMO, to not stay in the conversation and then all of the sudden express your opinion. Not that he doesn't have a right to, but this project is at least a step forward. If he has specific vision for the project he is responsible for leading it.
Gruber also mentioned it recently on one of his talk show episodes. I cant remember which episode, but as I recall he was not a fan of the effort at all and thinks it is not necessary.
What’s Markdown™? it is nor hand, nor foot,
Nor arm, nor face, nor any other part
Belonging to a man. O, be some other name!
What’s in a name? that which we call a Standard
By any other name would smell of squeamish ego
It's amazing how similar this is already to the RSS/Atom format wars:
Widely read blogger independently develops a simple file specification that addresses a real world problem. Simple file format becomes a de facto standard. Developers gripe about ambiguities in the specification. Effort to create a formal, standardized specification is launched. This new effort is publicly denounced by the original specification author.
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.
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.
> 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.
The tags listed are not a complete list of section elements (missing `address` and `nav`), nor the grouping elements (missing `main`), nor the embedded content elements (missing `area`, `audio`, `iframe`, `img`, `param`, `picture`, `source`, and `track`), and doesn't scratch the form elements (but yet the "HTML blocks" include `form`, `fieldset`, `textarea` and `progress`).
So we have a list of arbitrary HTML elements that have been declared as "HTML blocks", some of these are not really "blocks", and some are clearly other things, and some things that perhaps should be included are not.
And reading through why this list exists creates a sense that the implementation difficulty (of having to produce a balanced tree) is dictating how Markdown must now be experienced by the users.
Example 99 is a great example of surprising a user by not doing what they think will happen and leaving them with a game of "Guess why it's not working.".
Okay, that came out wrong. While I understand why one would want any input to pass (web comment from non-technical users), I have experienced several failures (wrong emphasis, missing link, weird unintended brackets…) just because the original markdown.pl didn't warn me about some obvious mistake I made.
We need a strict mode, where paragraphs cannot be interrupted, where fenced code blocks must end by a fence (not just the end of the file), duplicate or missing references must be signalled… That, and many other precautions could turn Markdown into a serious and reliable document format.
Besides, this tolerance is complicating the grammar. I don't mind context sensitivity nor ambiguity (parser generators can now deal with both), but I do mind the sheer size. If you ask me, a formal spec (one that can be treated as a DSL and translated mechanically into a parser), should not take more than 300 lines. More than that is probably too complicated to implement, or even use.
So it seems like this spec covers a minimum implementation, "basic" markdown. I think extensions to (footnotes, tables, definition lists etc.) should also be standardized, even if their implementation remains optional.
> Extensions can come later. This project has the limited goal of standardizing “core” markdown features. There’s plenty to worry about there before we go to extensions.
Yeah, I'm going to just go ahead and say that Fletcher's MMD has been my "standard" for years. Yes, yes, Github flavored is fine. You can adapt it. But since Gruber doesn't want to set a more specific "spec," I default to what I grew up on. And in this case, the last 7 years of my life have been spent writing 95% of everything I publish (keep in mind, this is how I make my living) with MultiMarkdown.
What would they have to do differently for RTL languages? I thought that RTL is already abstracted by Unicode or something. Won’t something like the following just work automatically?
I thought the whole point of Markdown was to define a mixed-mode formatting that looked OK in ASCII and could be prettified in other contexts like HTML.
It seems like an obviously missing thing is a page that describes how users should write markdown, in a few sentences. Otherwise you are just going to get incorrect summaries of the spec.
You certainly can't point users to the spec, which is incredibly lengthy.
The most surprising thing in here is the ire toward Gruber. Even if you disagree with someone who writes a piece of software, they don't owe you anything. You use and benefit from their work, and you are angry when they don't agree with you? What a bunch of whiny, entitled nonsense.
Gruber has stated he wants to keep it ambiguous. You may disagree. But Gruber owes you nothing, and you are in his debt if Markdown has been useful to you. Draw inspiration from his project and make your own.
This reminds me of a similar issue that happened within the Scala community. David Polak, the creator of the Lift framework (which is used in production in many top sites), had originally worked hard to create the framework (along with others) and make it production worthy.
Later, he realized that the releases of the framework he had created were happening without his involvement. But, instead of accusing the community, he said something remarkable which only multiplied my original respect for him:
I never "left" the Lift community.
Yes, I have other project and work in different languages.
What I did was cease to be Lift's benevolent dictator for life.
Lift has grown way beyond one person and the fact that
the 2.5-M4 release was done without me is a strength, not a weakness.
[1]
Because, that's the spirit of open source. When you release something to the public, for public consumption, then you must understand that someone is eventually going to fork it up and assign it a different nomenclature, sometimes even a nomenclature that you may not like. In this case, this particular project had no standardization and a part of the community decided to just standardized it. If you don't like this standardization, then simply don't use it. Use what resonates with you. If you feel the standardization has some flaws, then fork it and fix what's wrong. IF people agree with you, eventually they will end up using your fork. It's as simple as that.
What is funny is to see John Gruber who appears to be butthurt about this, when his contributions have grown negligent (https://news.ycombinator.com/item?id=8266574), inconsistent and his recent focus has been more on other (personal) things.[2]
This reminds me of Luca Pasani[3], who released the much popular WURFL repository as open source in a liberal license first, then one fine day, cried foul because other people (including companies) were using it for profit (in accordance with the license), deleted all online repositories and instances of the project released under the old liberal license [4], then re-released the project with a comparatively restrictive license.[5]
In my opinion, releasing something for open, public consumption means you have to develop an honest mindset of accepting that other people WILL benefit from your creation eventually. If you don't get that right, then open source is probably isn't for you. (And crying foul later, is a double standard, if you do)
Thanks for this, you've pretty much said most of what I'd have to say on the subject. The only real question is the enforceability of the license clause on naming of derivative works. Though of course, a spec (which doesn't quote the BSD code itself) isn't a derivative, nor are other implementations based on that spec. Gruber is attempting to turn his copyright license into a trademark license, which given a decade of genericization and non-defense is fairly likely to fall if tested in court.
I forsee a possible recursive acronym of the form Foo is Not Markdown in the not-too-distant future.
Or a Mozilla / Phoenix / Firebird / Firefox contretemps.
Gruber really should put on his big-boy pants though, IMO, and thank those who've picked up his ball and run it further down-field from where he'd abandoned it quite some time back.
"Neither the name “Markdown” nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission."
it seems weird to have HTML as a non-optional part of the spec in two separate locations, and then "Because we might be targeting a non-HTML format"
it would make more sense to just have some way to dedicate a block of text to not be parsed in any form.
regardless, I'm 99% sure I'm intentionally missing the point here, as I can imagine reddit's, github's, stackoverflow's, et al.'s implementations would not support html tags at all (and anything for a personal site would have less restrictions on usable html tags). So in practice, it is going to be optional to some degree for implementers. but it seems weird to have that implied, when the handling of info-lines for codeblocks is explicitly left ambiguous
[+] [-] eslaught|11 years ago|reply
Markdown is a popular language with an ambiguous, poorly specified spec and buggy default implementation (so buggy that the vast majority of Markdown users have probably never used it, if they even know it exists). Now, we have a much more well-specified English language spec that explicitly addresses the challenges of the grammar, with a test suite that does a much better job of covering the corner cases, and much better default implementations. These improvements are by no means perfect, but they are improvements.
Yes, we need a formal grammar. Yes, we need tables, and other features. Yes, the naming is unfortunate, though frankly I don't feel sorry for Gruber given that Atwood posted a public letter calling for change two years ago. Yes, these are all issues. But it is an achievement nevertheless, and let's celebrate that.
And then we can get back to work.
----
More generally, I think we have issues with entitlement here on HN. Frankly, we have no fundamental right to either the original Markdown or this new version. But when posts like this come up, we hack away at them as if we had a right for better, as if the authors should be working to please us personally. We need to stop acting like we have a right to sentence judgement over what others release as open source.
[1]: https://news.ycombinator.com/item?id=8265469
[2]: https://news.ycombinator.com/item?id=8266370
[3]: https://news.ycombinator.com/item?id=8264828
[4]: https://news.ycombinator.com/item?id=8265299
[5]: https://news.ycombinator.com/item?id=8266073
[6]: https://news.ycombinator.com/item?id=8264895
[7]: https://news.ycombinator.com/item?id=8266121
[+] [-] roop|11 years ago|reply
Some examples of ambiguities:
1. It does not specify precedence. For example, if a line like "~~~" (or "[ref]: /url") is followed by a setext underline, is that a header, or is that the start of a fenced code block (or ref definition)?
2. The spec says: "Code span backticks have higher precedence than any other inline constructs except HTML tags and autolinks". It says as an example that "<a href="`">`" is a HTML tag. What happens for different placement of backticks, like "<a `href=""`>" or even "`<a href="">`" is left unspecified.
3. What is the precedence or associativity of span-level constructs? For example, does "<asterisk>a[b<asterisk>](url)" result in "a[b" being emphasised or "b<asterisk>" being linked?
Thing is, a specification-by-example like this would have to keep an ever-growing list of corner cases and give examples for each of them. To get completely unambiguous, the list needs to be very long, and when it gets very long, it becomes unwieldy to handle for an implementer of the spec.
Hence the need for a formal grammar, which is the shortest way of expressing something unambiguously. But it's not possible to write a CFG for Markdown because of Markdown's requirement that anything is valid input. So the next best thing is to define a parsing algorithm, like the HTML5 spec. (Shameless plug: vfmd (http://www.vfmd.org/) is one such Markdown spec which specifies an unambiguous way to parse Markdown, with tests and a reference implementation.)
So if "Standard Markdown" is NOT unambiguous and wouldn't be, then it's not a "standard", so calling it "Standard Markdown" is not quite proper.
[+] [-] kaoD|11 years ago|reply
Criticism is valuable. If I release anything into the public, I expect criticism. Heck, I even look forward to being criticized because it means people care about what I did (even if I did it wrong!)
[+] [-] ulisesrmzroche|11 years ago|reply
"Neither the name “Markdown” nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission."
It's a total breach of license, and on a fairly standard BSD too.
I'm seriously getting tired of copy-pasting this, and surprised that ya'll are defending this whole thing. but I guess I shouldn't.
Anyway, I better jet before I start trolling. In the end, I'm ok with making a better markdown, but completely opposed to breaking the law.
[+] [-] tjradcliffe|11 years ago|reply
That never hurt Perl... :-) Sorry, couldn't resist.
Your sentiments are well-taken.
No one "owns" Markdown, and quibbling over words is unproductive.
There is a concept: "a simple in-line markup language that is easy to write and maps clearly to HTML". One instance of that concept is a specific, buggy, ill-defined language called "Markdown".
"Standard Markdown" is another instance of the same concept. This is the way English works: adding modifiers to words that designate one instance of a concept to designate other instances of the same concept.
Getting to an EBNF grammar from the spec would be awesome, but the spec is a great place to start. All spec generation is tendentious, and it is common to have multiple people highly invested in the generation of different specs for the same nominal standard. Politics, as Aristotle tells us, is the master art. This is why.
[+] [-] verroq|11 years ago|reply
[+] [-] bpierre|11 years ago|reply
A Markdown Community Group [2] has been created on w3.org, and people have started to push some effort in it [3][4][5], but it has been totally ignored since the beginning, despite the communication attempts.
Maybe I don’t have all the informations, but it looks like a waste to me, and I find it disrespectful for the people who worked on the project. All of this could have easily been avoided with a simple communication about the status of the project.
[1] http://blog.codinghorror.com/the-future-of-markdown/
[2] http://www.w3.org/community/markdown/
[3] http://www.w3.org/community/markdown/wiki/Main_Page
[4] http://lists.w3.org/Archives/Public/public-markdown/2014Mar/...
[5] http://lists.w3.org/Archives/Public/public-markdown/2014Jul/...
[+] [-] burntsushi|11 years ago|reply
On the flip side, developing a spec---for something as popular and accessible as Markdown---out in the open is an extraordinarily difficult task. I think one can definitely make a case for it being the right thing to do (and I mean that in more than just the ethical sense), but I also think one can make a reasonable case for not wanting to travel down that road either. I think it can be so difficult that there would be a very real possibility that it would never get completed.
(I'm sincerely not trying to be combative. I know I'm not really addressing your point---that they didn't even provide a status update---but I just wanted to provide a tiny perspective on the other side of the coin.)
[+] [-] TazeTSchnitzel|11 years ago|reply
[0] https://twitter.com/justin/status/507304506007515136
[1] https://twitter.com/markdown/status/507341395137658880
[+] [-] ansgri|11 years ago|reply
[+] [-] cirosantilli|11 years ago|reply
[+] [-] 8ig8|11 years ago|reply
[+] [-] peterkelly|11 years ago|reply
Here's the link to MultiMarkdown's grammar:
https://github.com/fletcher/MultiMarkdown-4/blob/master/pars...
It's littered with implementation code, but with this stripped out it would make a good basis from which people can write parser generators from (that don't depend on the specific implementation details of MultiMarkdown's internal representation).
As far as I'm concerned, a formal definition should be an absolute requirement for any official spec. The "spec" as presented simply looks like a large collection of examples, informally specified in prose.
What's really needed is a grammar you can use for parser generators, corresponding to a schema for an object model.
It's late here, I may have missed something, so feel free to correct me if if this is the case ;)
[+] [-] ChuckMcM|11 years ago|reply
Michael Fortin's syntax is pretty useful and quite close to the spirit of Gruber's original efforts. (who hasn't done ascii tables with | and - right?) Until tables are 'standard' I do not hold out a lot of hope for widespread adoption.
That said, I really love taking it Markdown to this next level. And am moderately amused by the recurrence of the themes over time. I'm a old RUNOFF user from back in the day.
[+] [-] hayksaakian|11 years ago|reply
With the use cases for markdown, table seem inappropriate.
What I mean: tables are good at representing arbitrary data, particularly sets of data stored somewhere.
Maybe it would be better to simply describe the data with json embedded in markdown and delegate representation to something else.
[+] [-] xfalcox|11 years ago|reply
[+] [-] saosebastiao|11 years ago|reply
[+] [-] fernly|11 years ago|reply
Given that, the lack of a formal definition is even more surprising: why did they not spec it in Haskell? Formal, unambiguous, and as a side benefit, executable.
[+] [-] masklinn|11 years ago|reply
StackOverflow? (who're also on board via Atwood)
[+] [-] Terretta|11 years ago|reply
[+] [-] pessimizer|11 years ago|reply
http://powerman.name/doc/asciidoc-compact.html
I'm probably tone-deaf on something here, because I simply don't understand the appeal of the format.
edit - asciidoc talk: https://plus.google.com/114112334290393746697/posts/CdXJt6hV...
[+] [-] munificent|11 years ago|reply
The warm feeling I get is that it's the syntax I use all day on reddit and GitHub. The syntax could be a mixture of Perl, non-printing characters, Emoji, and a Turing-complete sublanguage, and I'd still use it.
Familiarity trumps all other merits. The easiest language to learn and use is the one I've already learned.
[+] [-] jacquesm|11 years ago|reply
[+] [-] jader201|11 years ago|reply
https://twitter.com/gruber/status/507305771265454080
[+] [-] andyfleming|11 years ago|reply
> “Standard Markdown” is neither.
Just look at the @markdown timeline, though. That is one of two tweets ever made. The last one was "23 May 2011". It is a bit passive agressive, IMO, to not stay in the conversation and then all of the sudden express your opinion. Not that he doesn't have a right to, but this project is at least a step forward. If he has specific vision for the project he is responsible for leading it.
[+] [-] tizzdogg|11 years ago|reply
[+] [-] rhythmvs|11 years ago|reply
[+] [-] edavis|11 years ago|reply
Widely read blogger independently develops a simple file specification that addresses a real world problem. Simple file format becomes a de facto standard. Developers gripe about ambiguities in the specification. Effort to create a formal, standardized specification is launched. This new effort is publicly denounced by the original specification author.
[+] [-] kuon|11 years ago|reply
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|11 years ago|reply
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.
[+] [-] danneu|11 years ago|reply
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.
[+] [-] buro9|11 years ago|reply
Such as this: http://jgm.github.io/stmd/spec.html#html-blocks
The tags listed are not a complete list of section elements (missing `address` and `nav`), nor the grouping elements (missing `main`), nor the embedded content elements (missing `area`, `audio`, `iframe`, `img`, `param`, `picture`, `source`, and `track`), and doesn't scratch the form elements (but yet the "HTML blocks" include `form`, `fieldset`, `textarea` and `progress`).
The tags listed also include child elements, rather than just the topmost parent elements that were listed in the original Markdown syntax: http://daringfireball.net/projects/markdown/syntax#html
So we have a list of arbitrary HTML elements that have been declared as "HTML blocks", some of these are not really "blocks", and some are clearly other things, and some things that perhaps should be included are not.
And reading through why this list exists creates a sense that the implementation difficulty (of having to produce a balanced tree) is dictating how Markdown must now be experienced by the users.
Example 99 is a great example of surprising a user by not doing what they think will happen and leaving them with a game of "Guess why it's not working.".
http://jgm.github.io/stmd/spec.html#example-99
[+] [-] loup-vaillant|11 years ago|reply
Okay, that came out wrong. While I understand why one would want any input to pass (web comment from non-technical users), I have experienced several failures (wrong emphasis, missing link, weird unintended brackets…) just because the original markdown.pl didn't warn me about some obvious mistake I made.
We need a strict mode, where paragraphs cannot be interrupted, where fenced code blocks must end by a fence (not just the end of the file), duplicate or missing references must be signalled… That, and many other precautions could turn Markdown into a serious and reliable document format.
Besides, this tolerance is complicating the grammar. I don't mind context sensitivity nor ambiguity (parser generators can now deal with both), but I do mind the sheer size. If you ask me, a formal spec (one that can be treated as a DSL and translated mechanically into a parser), should not take more than 300 lines. More than that is probably too complicated to implement, or even use.
[+] [-] pron|11 years ago|reply
[+] [-] roryokane|11 years ago|reply
> Extensions can come later. This project has the limited goal of standardizing “core” markdown features. There’s plenty to worry about there before we go to extensions.
[+] [-] filmgirlcw|11 years ago|reply
A for effort though.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] 01walid|11 years ago|reply
2 years of 'complete specs' without a mention for RTL and how it should be supported/written in markdown....
A bit disappointed tbh... even though it's a nice initiative...
[+] [-] roryokane|11 years ago|reply
> انا اسم [روري](http://roryokane.com/)
[+] [-] Terr_|11 years ago|reply
I thought the whole point of Markdown was to define a mixed-mode formatting that looked OK in ASCII and could be prettified in other contexts like HTML.
[+] [-] vjeux|11 years ago|reply
https://github.com/vjeux/markdown-react
[+] [-] smackfu|11 years ago|reply
You certainly can't point users to the spec, which is incredibly lengthy.
[+] [-] codinghorror|11 years ago|reply
See: http://talk.standardmarkdown.com/t/create-a-page-or-subdomai...
[+] [-] philoushka|11 years ago|reply
[+] [-] phren0logy|11 years ago|reply
Gruber has stated he wants to keep it ambiguous. You may disagree. But Gruber owes you nothing, and you are in his debt if Markdown has been useful to you. Draw inspiration from his project and make your own.
[+] [-] neya|11 years ago|reply
Later, he realized that the releases of the framework he had created were happening without his involvement. But, instead of accusing the community, he said something remarkable which only multiplied my original respect for him:
[1]Because, that's the spirit of open source. When you release something to the public, for public consumption, then you must understand that someone is eventually going to fork it up and assign it a different nomenclature, sometimes even a nomenclature that you may not like. In this case, this particular project had no standardization and a part of the community decided to just standardized it. If you don't like this standardization, then simply don't use it. Use what resonates with you. If you feel the standardization has some flaws, then fork it and fix what's wrong. IF people agree with you, eventually they will end up using your fork. It's as simple as that.
What is funny is to see John Gruber who appears to be butthurt about this, when his contributions have grown negligent (https://news.ycombinator.com/item?id=8266574), inconsistent and his recent focus has been more on other (personal) things.[2]
This reminds me of Luca Pasani[3], who released the much popular WURFL repository as open source in a liberal license first, then one fine day, cried foul because other people (including companies) were using it for profit (in accordance with the license), deleted all online repositories and instances of the project released under the old liberal license [4], then re-released the project with a comparatively restrictive license.[5]
In my opinion, releasing something for open, public consumption means you have to develop an honest mindset of accepting that other people WILL benefit from your creation eventually. If you don't get that right, then open source is probably isn't for you. (And crying foul later, is a double standard, if you do)
[1] http://stackoverflow.com/questions/12424617/comparing-lift-w...
[2] like writing controversial Apple articles at daringfireball.
[3] http://en.wikipedia.org/wiki/Luca_Passani
[4] http://en.wikipedia.org/wiki/WURFL#License_update
[5] http://yro.slashdot.org/story/12/01/09/169216/wurfl-founders...
[+] [-] dredmorbius|11 years ago|reply
I forsee a possible recursive acronym of the form Foo is Not Markdown in the not-too-distant future.
Or a Mozilla / Phoenix / Firebird / Firefox contretemps.
Gruber really should put on his big-boy pants though, IMO, and thank those who've picked up his ball and run it further down-field from where he'd abandoned it quite some time back.
[+] [-] ulisesrmzroche|11 years ago|reply
"Neither the name “Markdown” nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission."
No ifs, and, or buts. It is what it is. It didn't meet that condition. It's in breach of copyright. http://daringfireball.net/projects/markdown/license
[+] [-] RubyPinch|11 years ago|reply
it would make more sense to just have some way to dedicate a block of text to not be parsed in any form.
regardless, I'm 99% sure I'm intentionally missing the point here, as I can imagine reddit's, github's, stackoverflow's, et al.'s implementations would not support html tags at all (and anything for a personal site would have less restrictions on usable html tags). So in practice, it is going to be optional to some degree for implementers. but it seems weird to have that implied, when the handling of info-lines for codeblocks is explicitly left ambiguous
[+] [-] jaredmcateer|11 years ago|reply