As Gruber said:<p>> If you liked the original, which I created dictatorially, what makes you think you’d like a sequel from by a committee?<p>What dictator ever accepted that a group of people could do a better job?<p>The best thing for this new effort is to now embrace the new name (tentatively Rockdown), create the test suite and move on.<p>Markdown becomes one of the influencers in the footnotes, and hopefully we all get a highly consistent and implementable syntax and set of parsers that we can use.<p>My hope is that the "committee" isn't open to anyone joining it, or open to too much external influence. dgreensp (from Meteor) seemed to hope that too, and was reaching out to just the right people who could make a difference and whose views were valuable.<p>It's a shame Jeff felt the need to create such a spectacle when this could've just been presented fait accompli without having such a distracting spectacle.<p>dgreensp had it right though, but just didn't account for Jeff's character (although he clearly did account for Gruber's by not CC'ing him originally). Here's hoping that he now ignores both of them and pushes forward anyway.<p>Consistent tests that lead to consistent and implementable parsers... these are good goals.<p>If Markdown has to have a 5% change in it's DNA to make this work, then this is also a good thing.<p>I hope dgreensp isn't feeling too disheartened by the clash of personalities of Gruber and Jeff.
Sorry, creator and maintainer of marked here ( <a href="https://github.com/chjj/marked" rel="nofollow">https://github.com/chjj/marked</a> ). Is a repo for this spec up on github yet? I have a few obscure cases across multiple markdown engines that I've documented over the past year or so. Are only the top dogs (reddit, stack, github, etc) invited to join the development? A spec for markdown should be more than just what features are included (GFM tables, code fences, etc).<p>I hope development of this spec will be perpetual, similar to the WHATWG's HTML(5), if it happens at all. I've been dealing with markdown edge cases for more than a year now and I'm always finding new things I missed. It's really amazing how markdown is just a giant string of special cases and exceptions (this is probably due to the way it was initially written). The post by Jeff Atwood lead me to believe it's supposed to be geared more toward features as opposed to exact specifications. (I could be wrong about this).<p>Although I agree Gruber seemed kind of impolite and dismissive here, I think we should take things slow, and not rush into making a "spec" right away. The closest thing there has ever been to a markdown spec was Gruber's original test suite (on top of the markdown docs). It is actually kind of hard to track down since you can't find it on his website (I don't think I saw it mentioned in these articles either). My test suite is based on a fork of it ( <a href="https://github.com/chjj/marked/tree/master/test/tests" rel="nofollow">https://github.com/chjj/marked/tree/master/test/tests</a> ). That test suite covers no where near enough to demonstrate everything. I have a feeling this spec would take a long time to complete, especially if it's including more compex features like GFM tables and whatnot. There will also probably be a ton of arguing over which features should be included.
Wow. I think that Atwood’s proposal was an honest and good move, and a needed one. If Gruber feels like someone is twisting his hands by asking publicly, why not say so in a decent, grown-up manner? “OK, this makes sense, but I would have preferred you to write in private and not force me by writing an open letter.”<p>It’s a shame that so many technologies get shaped by egos instead of rational thinking. Good engineers should know better than that. If someone thinks the proposal for a spec plus a test suite is somehow technically flawed, say so and state the reasons. If not, let’s put the egos aside, take an extra dose of tolerance and work towards a common goal.
The spec. The spectacle. This fall, only on Twitter!<p>I see the assertion that:<p>><i>MMD has a very clear specification. It also has an openly available test suite.</i><p>But the specification link goes to the help page [1] which as far as I can tell has no <i>spec</i>, just links to descriptions (Gruber's canonical blog post) and examples. Is there an <i>actual</i> spec for MMD, or are they claiming examples <i>are</i> specs?<p>[1]: <a href="http://fletcherpenney.net/multimarkdown/help/" rel="nofollow">http://fletcherpenney.net/multimarkdown/help/</a>
> On Macdrifter Gabe Weatherhead said:
>
> > Nowhere does he mention MMD and it seems very unlikely that he does not know about it. [<a href="http://stackoverflow.com/questions/tagged/multimarkdown" rel="nofollow">http://stackoverflow.com/questions/tagged/multimarkdown</a>]<p>Wow. Just because there’s a Stack Overflow tag for it doesn’t mean that Jeff knows about it. It’s a community-driven site.
Am I the only one who thinks Jeff Atwood is completely without the necessary credibility to spearhead an effort like this?<p>To say nothing of the time-tested idiocy of designing a spec by committee? IEEE telco protocols being the canonical example?<p>The whole effort seems like a terrible idea. Gruber's responses seem to me to be completely appropriate.
For those who are saying Jeff Attwood posted this publicly out of nowhere, please read this from 2009:<p><a href="http://www.codinghorror.com/blog/2009/12/responsible-open-source-code-parenting.html" rel="nofollow">http://www.codinghorror.com/blog/2009/12/responsible-open-so...</a><p>Now I don't know if he privately mailed Gruber prior to writing that, but to say it came out of nowhere is to forget several years of Stack's history with wanting Markdown to work like one would expect of a living open-source project.
><i>Nowhere does he mention MMD and it seems very unlikely that he does not know about it.</i><p>I would hardly expect Jeff to keep track and know of every topic in StackOverflow, let alone one with only 11 questions. Give the man some room to err.
An ideological debate between <i>collaborative</i> vs <i>dictatorial</i> approaches, misses the point entirely.<p>Markdown was a good effort, but I've been feeling for a while now can do better. It's rather encouraging, that there are others attempting to design a new standard. Ideally it would be one that's easier to work with, and less idiosyncratic. ('new' of course, does not automatically equate to 'better' in this instance).<p>Furthermore, developing this should not require anyone to <i>'be someone'</i>. While it may help adoption, if it's great, then by it's own merits, it could have a decent chance of succeeding.
Open letter to Jeff: SO is awesome, but long-in-the-tooth. What it really needs is an open spec for federated, gamified Q&A. What say you? I eagerly await your enthusiastic embrace.<p>FAQ<p><i>Are you asking for Jeff to open the SO service?</i><p>No, we only feel that the structure of Q&A and reputation management be federated and openly specified. But we do feel that <i>StackExchange</i> would be the perfect name for the protocol.<p><i>Are you making an analogy?</i><p>No, though we might be modeling behavior.
I think of the MediaWiki wikitext specification and how that started as a simplification of HTML and was incrementally extended into a barely-computable disaster that, quite literally, put back a Wikipedia visual editor about six years.
We all have pandoc, and <3, and we can all choose between RST and Markdown, and we all know RST is a better spec (as in, there is one), but we keep on coming back to MD.<p>I suspect the reason is that MD does conform to the end-to-end principle. Having a spec is, itself, putting too much intelligence in the pipes. Not having a spec leaves all the intelligence into the ends: The person who's writing (which is very bad at following rules and specs) and the parser program (which can be as elaborate as needed).<p>That is why no spec (and Gruber's attitude) is a feature.
Let's imagine the worst happens: John Gruber explicitely refuses to give up the name "Markdown", and to bless any standardization process. Which would then need another name.<p>Ideally the name should be clearly different than the original one, and clearly signal the underlying spec is the same, only <i>better</i> (of course, the actual spec better live to that expectation).<p>"Rockdown" sounds cool, but it doesn't work. Sure, it <i>rocks</i>, but it's doesn't say "you should use me, not my obsolete father".<p>An obvious choice is "<qualifier> Markdown". For instance, "Clean Markdown", or "Standard Markdown". We may think that's cheating, but we already talk about "<website> flavoured Markdown". There will soon be another one, that explicitly pretends to be <i>the</i> flavour. Better let the name reflect that. As for the actual Markdown, I guess people will start calling it "Original Markdown".<p>Now there's little chance, but maybe, maybe John Gruber will still shout that his original version is <i>the</i> standard no matter what. If monsters like Stack-overflow, Reddit, and GitHub make a good "std Markdown" anyway, no one will believe him.<p>Anyway, enough with the name. Let's just write that BNF. A reference implementation in something like MetaII or OMeta will then be a piece of cake. If I ever do that on my own, I'll call it "Strict Markdown". Because I don't like when obvious errors in my Markdown code produce unintended output instead of an error message (major culprits are links and emphases).
I'm not 100% convinced that one global Markdown spec is going to be of net benefit. I'd be fine with pockets of specialized Markdown flavours. For example, I don't see how merging whatever is in Fountain (for screenplays) into a common Markdown spec would be useful for general use.<p>On the other hand, having separate flavours for every different online code repository site, or blog engine, is probably too far in the specialized direction.<p>I think it might be easier to start with standardizing in small groups (eg: GitHub/StackOverflow/CodingHorror) and slowly globbing other variants into the standard. Perhaps that is the direction this will end up taking. So far I can't see what is going on other than conflict.
I have always found Git Flavored Markdown funny.
Not in a bad way, really. Just funny.
Thinking of the taste of markdown is just interesting, and something we can possibly expand on.
So we could perhaps refer to the original as 'vanilla markdown'.
Git is of course 'git flavored'.
Perhaps we need 'markdown with nuts'.
Or from the bagel side, 'everything markdown'.
Pandoc would probably be 'everything markdown'.<p>I know the main thread is a very serious topic and there are passionate opinions.
However, let's make sure we keep it light and civil.