> 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.
I don't think Jeff was trying to create a spectacle, I honestly think he's all about the community and was trying to be inclusive.
What both Jeff and Gruber bring to the party is profile. As the article points out, there are already variants of Markdown that fix many of the problems but it would seem none of them have gained traction.
If you can get the founder of StackOverflow / StackExchange and the original creator of Markdown on-board, there's a good chance that whatever you come up with will get some momentum.
Specifications and test suites are all well and good but if no-one uses them what was the point? I suspect Jeff, as well as being someone with a good track record on making stuff happen, was an attempted solution to that problem.
> What both Jeff and Gruber bring to the party is profile. As the article points out, there are already variants of Markdown that fix many of the problems but it would seem none of them have gained traction.
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, ...)
Sorry, creator and maintainer of marked here ( 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 ). 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.”
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!
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?
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.
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.
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).
Regardless of how much I dislike Gruber's opinions on occasion, Jeff Atwood is completely steamrolling him here and I really feel for him; it isn't an accident that Jeff blogged about it instead of asking him privately. You do that when you don't care either way what the person says, and it's a completely dick move. As another commenter pointed out, there is no winning move for John Gruber here. That's so obvious that I can't even give Jeff the benefit of the doubt that he overlooked it.
This entire experience has left me with a bad taste in my mouth about Jeff Atwood -- I sure hope he doesn't set his sights on something useful that I've created for the world. You can make whatever argument you like about Gruber not "paying enough attention" to his creation, but Markdown doesn't really need to be "fixed" or "standardized". I look forward to the, undoubtedly, dozens of vendor-specific extensions that will be necessary in the final product and we'll end up right back at square one.
Really, really presumptuous and poor judgment. Invent your own stuff and let it stand on its merits rather than trading on Markdown's well-established name by force.
Jeff Atwood is a blowhard sure, but you're ignoring the history here. Gruber has refused for years to acknowledge that there are any problems with Markdown at all. Some argue that he has the right to do with his creation as he wishes, but that misses the larger point that Markdown has communal value far outstripping Gruber's original contribution of aggregating a bunch of ascii typographical conventions and compiling them in the spirit of Textile.
By sitting on his high horse and proclaiming Markdown "works for him" and that his unspecified version with tons of nasty edge cases is canonical and that not only is it correct, he won't weigh in on any formal specification, he deserves to be case aside and have the project taken forward without him. He doesn't have a moral claim on something as simple and widespread as Markdown, and the fact that he finally has to deal with someone with similar blog reach going on a crusade is nothing worse than he deserves for sticking his head in the sand.
Your comment reeks so strongly of entitlement that I don't even know where to begin.
We could say Twitter was instrumental in organizing human rights causes in the Middle East and is now important to the human race as a communication tool; that said, if Twitter doesn't implement a feature that you want, you don't get to redesign Twitter at your whim and call it "New Twitter". You don't have a "moral claim" to write an open letter to @jack telling him why you're moving on without him.
You instead, like all rational people, design a competing service and let your work stand on its own.
The fact that you would bring up a hosted service that is extremely complex and costs tons of money shows that you don't understand where I'm coming from at all.
Markdown is not some amazing patented invention that John Gruber is entitled to perpetual dictatorial rights to forever. It's a simple derivative idea. It's out there in the wild and people make tremendous use of it, but none of this use costs John anything, and it's successful on the backs of many implementors, not just Gruber. It's all fine and good to say design a competing "service", but people do do that, and all it does is lead to yet another variant which further exacerbates the problem.
To be clear, I'm not saying John owes anyone anything. He's free to do or not do whatever he wants, but so are other people. Precisely what courtesy do you think he's due if he refuses to act in any reasonable capacity as a steward?
> Markdown is not some amazing patented invention that John Gruber is entitled to perpetual dictatorial rights to forever.
Completely wrong. Markdown is John Gruber's creation, and he is quite entitled to perpetual dictatorial rights forever (although copyright is limited, his estate is perfectly capable of renewing if he wishes). John Gruber is the copyright holder on Markdown (the idea and implementation, which most of this thread is overlooking). It says so right here:
> 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.
Think about that while I repeat: You do not get to take over someone's creation and trade on its name simply because you are not satisfied with the stewardship of its creator.
He may have selected the particular syntactic conventions it uses, but the idea of parsing ASCII markup and converting it to a formatter's input syntax is much older. I'm aware of prior art dating back to 1986 or so -- and wouldn't be surprised if that wasn't the first either.
Right, so, for the sake of argument, you support perpetual copyright and software patents? Just trying to gauge how much exclusive ownership you think people should have over ideas.
Some people want to make a Markdown spin-off: clean, standardized, tested etc. Nothing ever stopped them, but they could really use the prestige given by the original name.
The question is, does John Gruber have the right to that name? I think he should give it away, but if he won't, we probably shouldn't force him. I'd change my mind if someone makes a compelling case against trademarks.
A better analogy: If Twitter had an API, and then had a spec for that API, and they didn't match, would it be out of line to call on Twitter to fix the API spec? And to put out a third-party spec if they didn't?
> it isn't an accident that Jeff blogged about it instead of asking him privately. You do that when you don't care either way what the person says, and it's a completely dick move. As another commenter pointed out, there is no winning move for John Gruber here. That's so obvious that I can't even give Jeff the benefit of the doubt that he overlooked it.
What if he did ask Gruber privately, and the private answer then was the same as the public one now, giving Atwood the choice between disclosing a private conversation, giving up on this, or doing what he has done.
I'd say you've discovered a hefty dose of speculation that lacks any evidence.
You've also invented a false trichotomy. Those aren't Jeff's only three choices. The fourth one you left out is "make something new without shitting all over Markdown".
> You've also invented a false trichotomy. Those aren't Jeff's only three choices. The fourth one you left out is "make something new without shitting all over Markdown".
And then everyone would criticize him for NIH syndrome and needlessly fragmenting the markup landscape further. And they would be right.
That's precisely what we should assume, because it's the facts as presented. Inferring things that don't exist because they benefit the parties in question is a subtle undercurrent that drives the entirety of our fact-unfriendly blogosphere, tabloids, and so on. You sound a little like an apologetic Gawker reporter, here.
We were given the story at face value, we interpret it at face value. We don't make up what could have been nor consider it acceptable to do so.
You're making something up as well if you assume Atwood intentionally did not contact Gruber beforehand. That is most definitely NOT interpreting the story at face value.
The dilemma is that it's basically impossible to contact one of these big blog/twitter folks privately. Send email? DM? I'm sure they get way too much volume (and hatemail) to even read it.
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.
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.
I sympathize with Gruber's apparent position, which I would summarize thusly: "Markdown is /this/, which I released; it is good enough for me; if it's good enough for you as well, use it; if not, feel free to make something for yourself instead".
I don't think he is saying that. Jeff Attwood is (I think) asking him to say "I approve, this is going to be a Markdown Spec" or "I disapprove" - in which case it will be a Rockdown Spec.
It seems to me that Gruber is adopting a 'Trotsky at Brest-Litovsk' position - "no war, no peace".
Am I the only one who thinks Jeff Atwood is completely without the necessary credibility to spearhead an effort like this?
That's how things get done. People get credibility by standing up, leading, and getting things done in the way Atwood does. He didn't have the "credibility" to partner with Joel Spolsky and create Stack Overflow either but I'm glad Joel didn't see it that way.
Actually, he lost credibility for not being a decent human being and e-mailing John Gruber first and StackOverflow is really irrelevant here.
"Say, so-and-so, you wrote a really nice book but there are several errors in the first edition. We think it's great and we love it, and we see the potential in your work, so we're going to rewrite a second edition by committee then sell it under your title and byline without your permission; that cool with you?"
If Markdown had continued to be robustly maintained by Gruber then I would give that thought more credence. As it is now it's barely just one notch shy of abandonware, I think that transfers Gruber's feelings from the realm of reasonable criticism to the land of butthurt.
Yep. Nuances of etiquette are one thing but I'll always side with the person that is trying to move things forward over the person that is throwing up hurdles.
To my way of thinking, Gruber comes out of this looking churlish and unhelpful at best.
The more pertinent question is why Jeff didn't make more effort to base this off one of the existing standardisation efforts.
The problem is that the existing spec is something one guy wrote up years ago, and there are edge cases that aren't handled. There is also a buggy implementation from the same guy, also from years ago, that sets behavior for those edge cases, but also does stuff that isn't in the spec. So if you want to write "MarkDown", do you write to the spec or to the implementation or what? And Gruber's response is "I'm happy with it as it is", which isn't even an answer to the question.
It seems to me that most good specs started out as individual efforts, then once they reached a certain level of maturity and usefulness, got taken over by a committee to polish into a proper standard. For example, C and UNIX. And this is exactly the path that Markdown will end up following, if this effort is successful.
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.
>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.
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.
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.
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.
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.
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.
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.
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).
> 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.
He won't enforce it. How about that elevator pitch:
> Makeup is a standardized version of John Gruber's Markdown. It has a formal specification, a reference implementation, and an exhaustive test suite. It also handles edge cases in a more sensible way than the original Markdown.
I think "Markdown" as a name can no longer be killed. The same holds for Markdown as a format. Alternate implementations will exist for a long time, and they will be referred to as "Markdown implementations", at least informally.
And so will whatever Markdown based "standard".
I probably crossed the line by suggesting "<qualifier> Markdown" as an official name. But as an informal name, it will be used, and John Gruber won't be able to do a thing about it.
By the way, I can't fathom why he wouldn't want Markdown spin-offs to be called "Markdown" as well. That name is his legacy. A standard would make sure to preserve it. As for his Perl implementation, it belongs to the museum, to be glorified as pioneering. But for actual use, Perl is now obsolete.
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
I don't know about the USA, but here in France, one can have a right to trademark even when it's not officially registered. The main requirement is to show that you have established a de facto brand.
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.
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.
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.
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.
> 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.