8 ms·

Markdown: The Spec - it's coming and it's full of personalities

168 points by voidfiles 14y ago

Groxx 14y ago
The spec. The spectacle. This fall, only on Twitter! I see the assertion that: >MMD has a very clear specification. It also has an openly available test suite. But the specification link goes to the help page [1] which as far as I can tell has no spec, just links to descriptions (Gruber's canonical blog post) and examples. Is there an actual spec for MMD, or are they claiming examples are specs? [1]: http://fletcherpenney.net/multimarkdown/help/ http://fletcherpenney.net/multimarkdown/help/
- voidfiles 14y ago
  Maybe he is referencing the pdf: http://fletcher.github.com/peg-multimarkdown/mmd-manual.pdf http://fletcher.github.com/peg-multimarkdown/mmd-manual.pdf
- mvzink 14y ago
  There is a test suite [1] available, though. Furthermore, the core of MMD is in the PEG grammar [2], which is enough of a specification for me. Compatibility of language subsets is even provable, so specifying a MMD-lite version (which might be the vanilla Markdown features) would be simple. On the other hand, I think its flexibility/sanity is actually a disadvantage for MMD: with the confusion and variability of a spec-free language that is still roughly familiar (i.e. Markdown), people seem more likely to adopt it with their own implementations and customizations. [1]: https://github.com/fletcher/MMD-Test-Suite https://github.com/fletcher/MMD-Test-Suite [2]: https://github.com/fletcher/peg-multimarkdown/blob/master/markdown_parser.leg https://github.com/fletcher/peg-multimarkdown/blob/master/ma...
  - qznc 14y ago
    The grammar is not enough. You also need to specify the output of the HTML transformation.
  - Groxx 14y ago
    That's just a grammar though. It's meaningless without defining what the result is, because you could use that grammar to output anything. A spec should also (ideally) define all possible behavior, so you know if something is conforming or not.
- ianb 14y ago
  Looking at the site, it seems like MMD is Yet Another Markdown Implementation. Which is a good reason to participate, and they might have some particularly good things to contribute (like a test suite), but it's not itself "standard Markdown". And even the test suite probably is overly specific and needs to be reviewed. For instance, it seems unlikely that balanced quotes would become a required feature (or at least to do so would require discussion).
nthitz 14y ago
As usual, Gruber seems like a bit of a prick.
- SuitAndThai 14y ago
  It's not terribly hard to see how this whole thing came to be offensive to him. Jeff put Gruber in the public spotlight with a question like "give us permission?" Gruber says 'Yes': whoop de doo Gruber says 'No': Well, the person at fault looks like Gruber for being prohibitive of others trying to improve his work. If his opinion was really to be respected, Jeff should've messaged John behind closed doors to see if he could expect his support or not on this committee, like John had any real say in the matter.
  - alexchamberlain 14y ago
    Part of the problem is Gruber is incredibly resistant to change. The software he wrote hasn't changed in 8 years, despite a number of bugs.
    - gordonguthrie 14y ago
      > The software he wrote hasn't changed in 8 years, despite a number of bugs. That isn't the problem. The problem is that the software hasn't changed despite a number of bugs and the source code asking you to submit bugs. 'Deprecate or maintain' is not an unreasonable request of a public persona in the technology sector.
    - troels 14y ago
      well, maybe that's a feature?
  - Jonanin 14y ago
    If Gruber says no, then who else besides him is to blame for needlessly attempting to block Markdown's forward progress, especially when it is seriously in need of attention, and when he has not put in any effort to give it some? The person at fault would look like Gruber because the person at fault would be Gruber.
mathias 14y ago
> On Macdrifter Gabe Weatherhead said: > > > Nowhere does he mention MMD and it seems very unlikely that he does not know about it. [http://stackoverflow.com/questions/tagged/multimarkdown http://stackoverflow.com/questions/tagged/multimarkdown] 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.
- jrajav 14y ago
  Given, that was a pretty bad citation. Still, it's a good guess that he heard about MultiMarkdown somewhere along the way since he considered and initiated the use of Markdown on Stack Overflow / Exchange; he's been personally involved with it for roughly 4 years now. (http://www.codinghorror.com/blog/2008/05/is-html-a-humane-markup-language.html http://www.codinghorror.com/blog/2008/05/is-html-a-humane-ma...) (http://www.codinghorror.com/blog/2009/10/treating-user-myopia.html http://www.codinghorror.com/blog/2009/10/treating-user-myopi...)
SuitAndThai 14y ago
>Nowhere does he mention MMD and it seems very unlikely that he does not know about it. 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.
redbad 14y ago
Am I the only one who thinks Jeff Atwood is completely without the necessary credibility to spearhead an effort like this? To say nothing of the time-tested idiocy of designing a spec by committee? IEEE telco protocols being the canonical example? The whole effort seems like a terrible idea. Gruber's responses seem to me to be completely appropriate.
- unimpressive 14y ago
  > Am I the only one who thinks Jeff Atwood is completely without the necessary credibility to spearhead an effort like this? I don't think he'll be spearheading it by the end, for whatever thats worth.
- jamesaguilar 14y ago
  Are there a lot of things that have been standardized without a committee being involved? I'm not aware of many. Designed, yes. Standardized, no.
  - qznc 14y ago
    Standardization by definition requires a buy-in of major players. Nevertheless, TeX might qualify as standard without commmittee.
    - ygra 14y ago
      A very messy one, though. With not that many alternative implementations (iirc they all are based on the converted-to-C Pascal code).
      - qznc 14y ago
        All major implementations (miktex, pdftex, xetex, luatex) are derivatives of Knuth's Pascal code. There are others, but they did not get very far: http://kasper.phi-sci.com/tex++/ http://kasper.phi-sci.com/tex++/ http://www.cucug.org/amiga/amiinfo/reviews/AmigaTeX.txt http://www.cucug.org/amiga/amiinfo/reviews/AmigaTeX.txt
deleted 14y ago
[deleted]
chjj 14y ago
Sorry, creator and maintainer of marked here ( https://github.com/chjj/marked https://github.com/chjj/marked ). 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). 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). 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 ( https://github.com/chjj/marked/tree/master/test/tests https://github.com/chjj/marked/tree/master/test/tests ). 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.
- voidfiles 14y ago
  Hi, I wrote the blog post. I haven't been able to find any public discussion about a spec from the parties involved other then Atwood's blog post.
buro9 14y ago
As Gruber said: > If you liked the original, which I created dictatorially, what makes you think you’d like a sequel from by a committee? What dictator ever accepted that a group of people could do a better job? The best thing for this new effort is to now embrace the new name (tentatively Rockdown), create the test suite and move on. 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. 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. 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. 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. Consistent tests that lead to consistent and implementable parsers... these are good goals. If Markdown has to have a 5% change in it's DNA to make this work, then this is also a good thing. I hope dgreensp isn't feeling too disheartened by the clash of personalities of Gruber and Jeff.
- qznc 14y ago
  The best defense against "anyone joining" in my opinion is time and boredom. A standardization takes at least one year and while in the first week everybody and his pet wants to add their opinion those people usually disappear after a few weeks. Personally, I have a wishlist of people who should sign the resulting spec. Jeff and Gruber, of course. Furthermore the implementors of solid and/or widely used markdown libraries (Pandoc, MultiMarkdown, Markdown Extra, etc). A few markdown users (Doxygen, Github, ...)
  - masklinn 14y ago
    > I have a wishlist of people who should sign the resulting spec. Jeff and Gruber, of course. Why them? > A few markdown users (Doxygen, Github, ...) Github are also implementors, hence the 2 or 3-years old "github-flavored markdown". https://github.com/vmg/sundown https://github.com/vmg/sundown is their core library, with https://github.com/vmg/redcarpet https://github.com/vmg/redcarpet as the ruby interface.
wamatt 14y ago
An ideological debate between collaborative vs dictatorial approaches, misses the point entirely. 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). Furthermore, developing this should not require anyone to 'be someone'. While it may help adoption, if it's great, then by it's own merits, it could have a decent chance of succeeding.
zoul 14y ago
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.” 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.
- zzzeek 14y ago
  The best ideas and software are labors of love, but love is not very rational.
acabal 14y ago
Wow, Gruber is kind of a jerk. Or maybe that's a symptom of having conversations in 140 character bursts.
- Tyrannosaurs 14y ago
  Jeff's side of the conversation was also limited to 140 characters and he didn't come off like a jerk. I like Gruber's writing but if it looks like a duck etc.
- DougBTX 14y ago
  Jeff comes along and says, "I'm going to mock you if you don't let me take over your project," and Gruber is the jerk for saying no?
  - malkarouri 14y ago
    Totally agree. Jeff is almost acting like a common bully here. I am surprised people are coming to the opposite conclusion.
porker 14y ago
I still wish reStructuredText was considered - it's solid, adaptable and (for some reason) totally unsexy.
- MatthewPhillips 14y ago
  Could be because it's hosted on Sourceforge.
davidgerard 14y ago
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.
antihero 14y ago
Did everyone forget about RST? That said, RST is a bit complicated seeming.
- klibertp 14y ago
  I did not, but I'm a Python programmer. It seems too few pythonistas participate in this thread to make a difference - RST was mentioned just 3 times. And Textile was mentioned once, although not as an alternative but as an inspiration for Markdown. MediaWiki syntax was mentioned once, but described as crap. I just felt the need to count something, don't mind me.
mmahemoff 14y ago
For those who are saying Jeff Attwood posted this publicly out of nowhere, please read this from 2009: http://www.codinghorror.com/blog/2009/12/responsible-open-source-code-parenting.html http://www.codinghorror.com/blog/2009/12/responsible-open-so... 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.
pohl 14y ago
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. FAQ Are you asking for Jeff to open the SO service? No, we only feel that the structure of Q&A and reputation management be federated and openly specified. But we do feel that StackExchange would be the perfect name for the protocol. Are you making an analogy? No, though we might be modeling behavior.
- tarabukka 14y ago
  That's a poor analogy. A service and a way of formatting documents are completely different. Not to mention that most ways of formatting documents have a context-free standard already.
  - jonny_eh 14y ago
    Not all analogies have to be identical. It was close enough to demonstrate how you approach people about their projects.
calinet6 14y ago
This post has made me realize how dysfunctional twitter is for real communication. It's nigh impossible to follow or understand.
- jimminy 14y ago
  That was the post's fault not Twitter's. I had to stop reading because I got so confused. Tweets in that post start referencing Gruber's response, but Gruber's response wasn't shared within the post, when it should have been. And authorship of tweets within the post wasn't really clear. Edit: Looking at it again, Gruber's response is there, but I missed it for the authorship issues.
gadders 14y ago
I'm getting flashbacks here of Dave Winer and the battle over RSS and Atom.
- mcormier 14y ago
  Then you might want to re-watch episode 6 of nerd TV: http://www.pbs.org/cringely/nerdtv/shows/ http://www.pbs.org/cringely/nerdtv/shows/
grannyg00se 14y ago
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. 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. 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.
- loup-vaillant 14y ago
  A possibility is to separate the core from extensions. The idea would be for everybody to observe the core spec, and clearly signal any extension. If an extension makes consensus, it could even be standardized. The most widely used standard extensions could then be merged in the core spec. The other, more specialized extensions, would stay in their separate standard.
loup-vaillant 14y ago
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. Ideally the name should be clearly different than the original one, and clearly signal the underlying spec is the same, only better (of course, the actual spec better live to that expectation). "Rockdown" sounds cool, but it doesn't work. Sure, it rocks, but it's doesn't say "you should use me, not my obsolete father". 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 the flavour. Better let the name reflect that. As for the actual Markdown, I guess people will start calling it "Original Markdown". Now there's little chance, but maybe, maybe John Gruber will still shout that his original version is the standard no matter what. If monsters like Stack-overflow, Reddit, and GitHub make a good "std Markdown" anyway, no one will believe him. 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).
- jspthrowaway 14y ago
  > 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. http://daringfireball.net/projects/markdown/license http://daringfireball.net/projects/markdown/license
  - shabble 14y ago
    Does this mean all the current "Markdown" implementations out there are in violation of this licence term[1]? How would one reasonably convey that their formatter is markdown-capable? It would seem to me that there's a significant difference between "Bloopdown - a Markdown compliant formatter for blah" and "Markdown v3.Ice-cream-pony"; the latter clearly trading off the name of the original, while the former is descriptive. I'm not sure where "$X Flavored Markdown" falls on that scale, although I'd be surprised if something like GitHub hadn't sought permission or clarified the naming provisions. [1] Having checked a couple of different projects, none of them mention having sought or received that permission, but I suppose they might have
mrpsbrk 14y ago
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. 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). That is why no spec (and Gruber's attitude) is a feature.
variedthoughts 14y ago
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'. 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.

168 points by voidfiles 14y ago

Groxx 14y ago

The spec. The spectacle. This fall, only on Twitter! I see the assertion that: >MMD has a very clear specification. It also has an openly available test suite. But the specification link goes to the help page [1] which as far as I can tell has no spec, just links to descriptions (Gruber's canonical blog post) and examples. Is there an actual spec for MMD, or are they claiming examples are specs? [1]: http://fletcherpenney.net/multimarkdown/help/ http://fletcherpenney.net/multimarkdown/help/

voidfiles 14y ago
Maybe he is referencing the pdf: http://fletcher.github.com/peg-multimarkdown/mmd-manual.pdf http://fletcher.github.com/peg-multimarkdown/mmd-manual.pdf
mvzink 14y ago
There is a test suite [1] available, though. Furthermore, the core of MMD is in the PEG grammar [2], which is enough of a specification for me. Compatibility of language subsets is even provable, so specifying a MMD-lite version (which might be the vanilla Markdown features) would be simple. On the other hand, I think its flexibility/sanity is actually a disadvantage for MMD: with the confusion and variability of a spec-free language that is still roughly familiar (i.e. Markdown), people seem more likely to adopt it with their own implementations and customizations. [1]: https://github.com/fletcher/MMD-Test-Suite https://github.com/fletcher/MMD-Test-Suite [2]: https://github.com/fletcher/peg-multimarkdown/blob/master/markdown_parser.leg https://github.com/fletcher/peg-multimarkdown/blob/master/ma...
- qznc 14y ago
  The grammar is not enough. You also need to specify the output of the HTML transformation.
- Groxx 14y ago
  That's just a grammar though. It's meaningless without defining what the result is, because you could use that grammar to output anything. A spec should also (ideally) define all possible behavior, so you know if something is conforming or not.
ianb 14y ago
Looking at the site, it seems like MMD is Yet Another Markdown Implementation. Which is a good reason to participate, and they might have some particularly good things to contribute (like a test suite), but it's not itself "standard Markdown". And even the test suite probably is overly specific and needs to be reviewed. For instance, it seems unlikely that balanced quotes would become a required feature (or at least to do so would require discussion).

nthitz 14y ago

As usual, Gruber seems like a bit of a prick.

SuitAndThai 14y ago
It's not terribly hard to see how this whole thing came to be offensive to him. Jeff put Gruber in the public spotlight with a question like "give us permission?" Gruber says 'Yes': whoop de doo Gruber says 'No': Well, the person at fault looks like Gruber for being prohibitive of others trying to improve his work. If his opinion was really to be respected, Jeff should've messaged John behind closed doors to see if he could expect his support or not on this committee, like John had any real say in the matter.
- alexchamberlain 14y ago
  Part of the problem is Gruber is incredibly resistant to change. The software he wrote hasn't changed in 8 years, despite a number of bugs.
  - gordonguthrie 14y ago
    > The software he wrote hasn't changed in 8 years, despite a number of bugs. That isn't the problem. The problem is that the software hasn't changed despite a number of bugs and the source code asking you to submit bugs. 'Deprecate or maintain' is not an unreasonable request of a public persona in the technology sector.
  - troels 14y ago
    well, maybe that's a feature?
- Jonanin 14y ago
  If Gruber says no, then who else besides him is to blame for needlessly attempting to block Markdown's forward progress, especially when it is seriously in need of attention, and when he has not put in any effort to give it some? The person at fault would look like Gruber because the person at fault would be Gruber.

mathias 14y ago

> On Macdrifter Gabe Weatherhead said: > > > Nowhere does he mention MMD and it seems very unlikely that he does not know about it. [http://stackoverflow.com/questions/tagged/multimarkdown http://stackoverflow.com/questions/tagged/multimarkdown] 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.

jrajav 14y ago
Given, that was a pretty bad citation. Still, it's a good guess that he heard about MultiMarkdown somewhere along the way since he considered and initiated the use of Markdown on Stack Overflow / Exchange; he's been personally involved with it for roughly 4 years now. (http://www.codinghorror.com/blog/2008/05/is-html-a-humane-markup-language.html http://www.codinghorror.com/blog/2008/05/is-html-a-humane-ma...) (http://www.codinghorror.com/blog/2009/10/treating-user-myopia.html http://www.codinghorror.com/blog/2009/10/treating-user-myopi...)

SuitAndThai 14y ago

>Nowhere does he mention MMD and it seems very unlikely that he does not know about it. 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.

redbad 14y ago

Am I the only one who thinks Jeff Atwood is completely without the necessary credibility to spearhead an effort like this? To say nothing of the time-tested idiocy of designing a spec by committee? IEEE telco protocols being the canonical example? The whole effort seems like a terrible idea. Gruber's responses seem to me to be completely appropriate.

unimpressive 14y ago
> Am I the only one who thinks Jeff Atwood is completely without the necessary credibility to spearhead an effort like this? I don't think he'll be spearheading it by the end, for whatever thats worth.
jamesaguilar 14y ago
Are there a lot of things that have been standardized without a committee being involved? I'm not aware of many. Designed, yes. Standardized, no.
- qznc 14y ago
  Standardization by definition requires a buy-in of major players. Nevertheless, TeX might qualify as standard without commmittee.
  - ygra 14y ago
    A very messy one, though. With not that many alternative implementations (iirc they all are based on the converted-to-C Pascal code).
    - qznc 14y ago
      All major implementations (miktex, pdftex, xetex, luatex) are derivatives of Knuth's Pascal code. There are others, but they did not get very far: http://kasper.phi-sci.com/tex++/ http://kasper.phi-sci.com/tex++/ http://www.cucug.org/amiga/amiinfo/reviews/AmigaTeX.txt http://www.cucug.org/amiga/amiinfo/reviews/AmigaTeX.txt

deleted 14y ago

[deleted]

chjj 14y ago

Sorry, creator and maintainer of marked here ( https://github.com/chjj/marked https://github.com/chjj/marked ). 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). 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). 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 ( https://github.com/chjj/marked/tree/master/test/tests https://github.com/chjj/marked/tree/master/test/tests ). 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.

voidfiles 14y ago
Hi, I wrote the blog post. I haven't been able to find any public discussion about a spec from the parties involved other then Atwood's blog post.

buro9 14y ago

As Gruber said: > If you liked the original, which I created dictatorially, what makes you think you’d like a sequel from by a committee? What dictator ever accepted that a group of people could do a better job? The best thing for this new effort is to now embrace the new name (tentatively Rockdown), create the test suite and move on. 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. 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. 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. 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. Consistent tests that lead to consistent and implementable parsers... these are good goals. If Markdown has to have a 5% change in it's DNA to make this work, then this is also a good thing. I hope dgreensp isn't feeling too disheartened by the clash of personalities of Gruber and Jeff.

qznc 14y ago
The best defense against "anyone joining" in my opinion is time and boredom. A standardization takes at least one year and while in the first week everybody and his pet wants to add their opinion those people usually disappear after a few weeks. Personally, I have a wishlist of people who should sign the resulting spec. Jeff and Gruber, of course. Furthermore the implementors of solid and/or widely used markdown libraries (Pandoc, MultiMarkdown, Markdown Extra, etc). A few markdown users (Doxygen, Github, ...)
- masklinn 14y ago
  > I have a wishlist of people who should sign the resulting spec. Jeff and Gruber, of course. Why them? > A few markdown users (Doxygen, Github, ...) Github are also implementors, hence the 2 or 3-years old "github-flavored markdown". https://github.com/vmg/sundown https://github.com/vmg/sundown is their core library, with https://github.com/vmg/redcarpet https://github.com/vmg/redcarpet as the ruby interface.

wamatt 14y ago

An ideological debate between collaborative vs dictatorial approaches, misses the point entirely. 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). Furthermore, developing this should not require anyone to 'be someone'. While it may help adoption, if it's great, then by it's own merits, it could have a decent chance of succeeding.

zoul 14y ago

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

zzzeek 14y ago
The best ideas and software are labors of love, but love is not very rational.

acabal 14y ago

Wow, Gruber is kind of a jerk. Or maybe that's a symptom of having conversations in 140 character bursts.

Tyrannosaurs 14y ago
Jeff's side of the conversation was also limited to 140 characters and he didn't come off like a jerk. I like Gruber's writing but if it looks like a duck etc.
DougBTX 14y ago
Jeff comes along and says, "I'm going to mock you if you don't let me take over your project," and Gruber is the jerk for saying no?
- malkarouri 14y ago
  Totally agree. Jeff is almost acting like a common bully here. I am surprised people are coming to the opposite conclusion.

porker 14y ago

I still wish reStructuredText was considered - it's solid, adaptable and (for some reason) totally unsexy.

MatthewPhillips 14y ago
Could be because it's hosted on Sourceforge.

davidgerard 14y ago

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.

antihero 14y ago

Did everyone forget about RST? That said, RST is a bit complicated seeming.

klibertp 14y ago
I did not, but I'm a Python programmer. It seems too few pythonistas participate in this thread to make a difference - RST was mentioned just 3 times. And Textile was mentioned once, although not as an alternative but as an inspiration for Markdown. MediaWiki syntax was mentioned once, but described as crap. I just felt the need to count something, don't mind me.

mmahemoff 14y ago

For those who are saying Jeff Attwood posted this publicly out of nowhere, please read this from 2009: http://www.codinghorror.com/blog/2009/12/responsible-open-source-code-parenting.html http://www.codinghorror.com/blog/2009/12/responsible-open-so... 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.

pohl 14y ago

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. FAQ Are you asking for Jeff to open the SO service? No, we only feel that the structure of Q&A and reputation management be federated and openly specified. But we do feel that StackExchange would be the perfect name for the protocol. Are you making an analogy? No, though we might be modeling behavior.

tarabukka 14y ago
That's a poor analogy. A service and a way of formatting documents are completely different. Not to mention that most ways of formatting documents have a context-free standard already.
- jonny_eh 14y ago
  Not all analogies have to be identical. It was close enough to demonstrate how you approach people about their projects.

calinet6 14y ago

This post has made me realize how dysfunctional twitter is for real communication. It's nigh impossible to follow or understand.

jimminy 14y ago
That was the post's fault not Twitter's. I had to stop reading because I got so confused. Tweets in that post start referencing Gruber's response, but Gruber's response wasn't shared within the post, when it should have been. And authorship of tweets within the post wasn't really clear. Edit: Looking at it again, Gruber's response is there, but I missed it for the authorship issues.

gadders 14y ago

I'm getting flashbacks here of Dave Winer and the battle over RSS and Atom.

mcormier 14y ago
Then you might want to re-watch episode 6 of nerd TV: http://www.pbs.org/cringely/nerdtv/shows/ http://www.pbs.org/cringely/nerdtv/shows/

grannyg00se 14y ago

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

loup-vaillant 14y ago
A possibility is to separate the core from extensions. The idea would be for everybody to observe the core spec, and clearly signal any extension. If an extension makes consensus, it could even be standardized. The most widely used standard extensions could then be merged in the core spec. The other, more specialized extensions, would stay in their separate standard.

loup-vaillant 14y ago

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. Ideally the name should be clearly different than the original one, and clearly signal the underlying spec is the same, only better (of course, the actual spec better live to that expectation). "Rockdown" sounds cool, but it doesn't work. Sure, it rocks, but it's doesn't say "you should use me, not my obsolete father". 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 the flavour. Better let the name reflect that. As for the actual Markdown, I guess people will start calling it "Original Markdown". Now there's little chance, but maybe, maybe John Gruber will still shout that his original version is the standard no matter what. If monsters like Stack-overflow, Reddit, and GitHub make a good "std Markdown" anyway, no one will believe him. 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).

jspthrowaway 14y ago
> 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. http://daringfireball.net/projects/markdown/license http://daringfireball.net/projects/markdown/license
- shabble 14y ago
  Does this mean all the current "Markdown" implementations out there are in violation of this licence term[1]? How would one reasonably convey that their formatter is markdown-capable? It would seem to me that there's a significant difference between "Bloopdown - a Markdown compliant formatter for blah" and "Markdown v3.Ice-cream-pony"; the latter clearly trading off the name of the original, while the former is descriptive. I'm not sure where "$X Flavored Markdown" falls on that scale, although I'd be surprised if something like GitHub hadn't sought permission or clarified the naming provisions. [1] Having checked a couple of different projects, none of them mention having sought or received that permission, but I suppose they might have

mrpsbrk 14y ago

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. 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). That is why no spec (and Gruber's attitude) is a feature.

variedthoughts 14y ago

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