We did -- no response to the current spec after a week of waiting for a reply.
A much earlier lengthy email response from Gruber around 11/2012 evaluated each of the changes Stack Overflow and GitHub made to Markdown one by one (there were some he agreed with) and essentially said "ambiguity is a feature" at the end.
But why use basically the same name? If you want to make a fully specified version why not give a slightly different name instead of just "Standard X"?
Using (basically) the same name strikes me as somewhat hostile given the views Gruber has expressed, and likely to cause confusion to end users.
The problem is that once Gruber embraced ambiguity and encouraged lots of people to make whatever they want and call it "Markdown," it's hard to say "no, no, you can't call this one specific thing Markdown."
Markdown has outgrown Gruber's stewardship, "ambiguity is a feature" is not an opinion I can get behind. Calling this something other than markdown would be more confusing for end users. It is markdown, standardised.
"I don't like his position so he should lose his ownership". Lovely.
My problem with the name "Standard Markdown" is I don't think it's going to be clear enough, I think people will think it's the same thing as Markdown (which it's not), under the theory that "non-standard" would have an obviously different name such as "Lisp Markdown" or "Japanese Markdown".
If they had used a word other than "Markdown" I wouldn't have a single problem, I would cheer them on.
I don't see a real benefit in this name to anyone, but I see serious downsides.
> "I don't like his position so he should lose his ownership"
That's certainly an unbiased translation :rolls eyes:. If you want to have a good-faith debate, you should avoid tendentious re-writes of your interlocutor's arguments.
> "ambiguity is a feature" is not an opinion I can get behind
You clearly don't like his position.
Be he has explicitly chosen not to make a specification, he's had years and numerous requests. From what I've seen/heard John Gruber likes that it isn't formalized with a spec.
So if a group of people, especially a large group with 10s of millions of users (at a minimum) decides to write a spec and name it "Markdown" over Gruber's wishes it sounds like trying to take ownership from him.
My phrase was glib, but I don't think it's that far off from many of the comments expressed here.
He owns an ambiguous text formatting system? He didn't invent the notion of simple ASCII-character based formatting, and he didn't write a spec. Plus this spec explicitly deviates from his implementation, so it's not the same obviously.
The reasons that he didn't write a spec after requests is very likely post-hoc rationalisation, behind the simple reason that writing a spec is not a fun task.
Because it communicates the right thing to users >90% of the time. If you learn the language specified here and then go write some reddit comments or file a GitHub issue using that language, it will do what you expect.
The few places where it doesn't you probably don't have an intuition about anyway.
If you treat "markdown" as an improper word describing the language and not some sort of proper "brand name" that describes provenance, then what they describe here is "markdown".
> If you learn the language specified here and then go write some reddit comments or file a GitHub issue using that language, it will do what you expect.
It would do the same thing if all those groups (since they seem to be onboard) had decided to call it TextMark or CommentAscii or some other new term. As long as they all use the same term it would be fine.
But instead they're basically trying to strong-arm redefine Gruber's name, and they'll win because they're bigger.
It's in terribly poor taste.
This will actually make things worse too, because they've invented another standard. People will see 'old' Markdown sites that don't work like 'new' Markdown sites ('Standard' is too subtle) and ascribe it to a bug in 'new' Markdown.
They haven't avoided confusion in the way a new name would have done very quickly.
Same confusion, acting like a jerk to take over someone else's creation. High class there.
I've certainly struggled with the layout of exact stuff in Markdown ... but there's something about this name, the writing on the index.html, and the constant use of the unofficial file icon (which i'm really not a fan) that kind of irks me. Maybe it's the spirit of the naming? Maybe it's because of the effort to _brand_ this? And perhaps the developer-centric tone of the writing versus the writer-centric tone of the
original spec? I'm not sure.
From the original Markdown doc: "HTML is a publishing format; Markdown is a writing format. Thus, Markdown’s formatting syntax only addresses issues that can be conveyed in plain text." The lack of support for complex or exact layout was intentional.
As I read it, if you want your Markdown documents to be rendered a specific way, you choose/configure/write a Markdown parser that renders it that way (possibly with the assistance of an additional stylesheet). If you need a particular extension for a task (tables, syntax-highlighted code blocks) you can use an parser that supports them. And if you need specific HTML elements, you can use them inline.
The way I read it, Markdown is intended as an _input format for markup tools_, designed to be both legible and meaningful as plain text. Any meaning that can't be explicitly encoded in the ASCII format, including the specific HTML tags used to render a given construct, is outside Markdown's scope and should probably be stored in a more structured format.
It kind of sounds like you have disagreed over the same things for five years now, and finally got enough names on your side that you decided you didn't need to get agreement and could just take over the name.
Whatever. I really respect Gruber for his original design of markdown, but am puzzled by his destructive behavior in this. While he was sitting on his hands, a lot of us have been annoyed at creating a markdown doc in one app and finding it looks funny in another client. This spec is long overdue.
He can still choose to be caustic and demand a rebrand, but it'll only delay the inevitable replacement of the original markdown.
But wont that always be an issue because vendors will have to disable features selectively. I see the merits of a standard from a developer standpoint but I don't think hat solves the problem you are describing.
Gruber has been okay with people writing and distributing their own markdown processors, with whatever variations they want.
The difference here is that they wrote a spec for the variation they plan to implement? That somehow makes it not cool?
Or just that they're calling it "Standard Markdown"? Could the dispute be avoided if they called it "A Standardized Markdown", or "Standardized Flavor of Markdown" instead?
There are many markdowns, and Gruber likes that, fine. Other people would like to standardize and make compatible implementations. Nothing's stopping people who disagree from continuing to ignore the standardized spec. But where' the logic in saying "you can release whatever markdown variations you like, as long as you don't try to make different implementations compatible with each other."
It really should be obvious that none of those other names are acceptable. Github-flavored markup is obvious because it is _not_ taking the name from the author and it is not lying about where it comes from.
Standard markdown lies about where it comes from and thus claims more authority than it is due. Formalize it all you want, then name it coding horror markup.
I don't see how stealing other peoples credit is acceptable.
has there been any standardization efforts which didn't end up with implementation-specific changes everywhere?
admittedly the worst example for such a topic, but, we still don't have a situation where all browsers agree on all renderings, and all of them still don't follow the spec, and in some areas, they don't plan to.
I can see html requirement being a pain-point for anyone implementing standard markdown.
Going to be honest, I'm not cool with this, and will not support it under this name. I'm probably a minority, I almost always am, but it will impact how I view and support the products built by this team. Not cool with me gentlemen, not cool by half.
You can't have your cake and eat it too. If ambiguity (and thus different implementations) is a feature, then a natural side effect is that another group of people can come along and say "this is ridiculous, let's define a new implementation we can all support".
And if you're doing that, it's pretty obvious to call the effort to produce a standard implementation Standard Markdown. Unless you think Github-StackOverflow-Reddit-flavored markdown is a better name :)
Yea, usually out of respect and general human decency, the inventor of a technology gets to retain rights to the name and the names usage. Very disappointed.
I think you've got it backwards. It would be less decent to give it an new name and forget its origins. Calling it Standard Markdown waives any claim to have created anything new. It makes it clear this is merely an effort to standardise the language Gruber famously invented. It gives all credit for origination to him.
I'm 100% certain I don't have it backwards. Gruber is still alive, so you can ask him if he wants it the same name. Oh, they did; he said no. Not honoring the original inventors wishes is in direct opposition to propriety. It will cause me to file trademark against any open source project I don't want to lose rights to. Seriously, how am I the only one who doesn't think this is f^#&^%d up?
I hadn't read the stuff about Gruber not wanting them to use the same name before I wrote my comment. But I still don't think it's 'fucked up' in the slightest. It actually sounds like Gruber is being irrational and a bit of a dick, from his comments that I've just read. His behaviour seems weirdly lame for someone capable of such good design. If he wanted to, he could have trademarked it, but he chose to give it free to the world and just sort of hoped that it would stay roughly in a shape he would like. Resisting standardisation is a weird thing to do. His notion that ambiguity is a feature is a dumb one. I think this is all relevant to the discussion about whether it's decent/honourable to use a similar name against his wishes. If his wishes are anti-progress, then tough luck, people are going to progress things if they can. He chose not to copyright/trademark anything. He can't have it both ways.
He did copyright everything. Explicitly. In a very short license where one third of the conditions of use was:
>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.
Gruber is not being irrational. He is operating under a different paradigm, which he explained last time Marco Arment was on his podcast. He is approaching this from the view that the optimal markdown implementation for a code site like GitHub is different to the optimal markdown for a commenting site like Reddit. Standardisation just locks in a suboptimal implementation for everyone. Whether you agree or disagree, it's at least a rational viewpoint.
The creator of the project let you do anything with it other than use the name markdown for a derivative product. They went ahead and did that. A completely unreasonable move that is just spiteful.
Standardisation doesn't lock it down, it just establishes a central flavour. It doesn't force Github to use the standard. Github can keep using GFM. It still benefits Github and others for there to be a well-defined standard which they can use as a base for defining their own variations against.
Documenting your own Markdown flavour will be easier if you can say "It's Standard Markdown, plus/except these features...", instead of "It's part of the soupy world of 'Markdown', but here are the features that some/all other implementations don't have...".
> He did copyright everything. Explicitly.
I didn't realise that. In that case he can force them to change it if he doesn't like it, right? I don't get why people are talking about honour/decency.
You can't copyright a name, which seems to be his main point of contention judging by the public responses he has offered.
This has nothing to do with my view point, it's simply a fact of law: you can't copyright a name. No matter what text you put somewhere says, it doesn't magically apply.
If you create an open format without any standardization, what do you expect? Does every implementation of markdown need Gruber's blessing? They're not stealing his idea or anything. He's given proper credit for inventing markdown in the first place.
Another way to look at it is this is just another implementation of markdown -- one that some of the bigger names in the markdown-business are going to support moving forward.
Given that it'll have StackOverflow, GitHub and Reddit behind it, that's definitely a large enough boost (or at least a large united front) to have this flavour be dominant. What does that Venn Diagram look like, I wonder: SO, GH, Reddit inside the whole online Markdown community.
Gruber seems to be a bit of a dick about it. Maybe he got surprised and it hit him harder than expected today. No surprise though, he's now about to be usurped. He sat on his hands for years. In the release today (and forever) they give him large amounts of due credit. The Talk Show crowd (I'm a listener) will grumble, and fanboys on Twitter will support him and jeer Atwood personally, but oh welp. There's one party actually advancing technology, the other resting on laurels.
He kind of mentioned being a benevolent dictator on the [podcast 88 discussion](https://overcast.fm/podcasts/episode/344902019595#t=4527), but what important decisions has he actually made lately? It seems to me he just points back to his implemention perl script. Genuine question. He hasn't made a spec because (loosely) "why have a spec; just do whatever you want, take a look over here".
So it's a variant of his perl script. Great, that sounds exactly as he mused everyone should do. I can see how it rubs him the wrong way with "Standard Markdown".
Also: by doing this, the group will be forcing his hand. They've released it magnanimously, invited him to be a part of the process for years. He didn't respond in kind, labeling it "Atwood's crusade".
He may not like the name "Standard" enough to do something about it. He can choose to pursue legal options. I doubt he wants to spend any money on that. You've got to assume GH, SO, and Reddit went over the Markdown license on DaringFireball.
He can choose to be grumpy about it, but this is happening. Those 3 entities have massive persuasive force with their user bases; enough to become standard.
Then they should call it Big Site Markdown. Calling this a standard takes regular, varied, simple, use-case-specific, optimal Markdown away from the rest of us.
But if you say your system uses "Markdown" then that's zero help for someone who wants to submit to you a complicated Markdown document for processing.
Ambiguity is not a feature it is a bug. It is not optimal.
> But if you say your system uses "Markdown" then that's zero help for someone who wants to submit to you a complicated Markdown document for processing.
This "Standard" makes things even worse. There are plenty of sites already on the internet that say they accept "Markdown", and that meant something: that it implements Gruber's formatting, and perhaps some extensions (and sites with extensions are normally clear about the fact that they're extensions, e.g. "Github-flavoured Markdown"). Now people will see a site that accepts "Markdown", expect it to support a feature from "Standard Markdown", and get angry when it doesn't.
If you want to submit a big document for parsing make it LaTeX or HTML.
Markdown is not for that and the exact reason to use it is that every site could customize it for their usage. Contrary to your assertions (which I see is backed by no argument) abiguity in markdown is a feature. Ambiguity in HTML was a bug.
You can make it clear that your implementation isn't the "official" one without denying credit. See e.g. Iceweasel; it's very clear that a) it isn't Firefox b) it owes a lot to Firefox.
I agree with Gruber. Ambiguity is a feature. It allows every implementer (leanpub, github et al) to add their own idiocentricities while staying true to Gruber's "spirit" of Markdown.
Everyone is still free to implement their own version. But it seems like many of the people behind the biggest implementations would rather agree on a standard.
He said in his podcast a few weeks ago that he thought it was unnecessary, as the ambiguity allowed for different flavors with different uses. I'm assuming the reference to the Yankees being the best team in baseball is directed at Gruber.
During that podcast, Gruber encouraged that group to consider not calling what they were doing Markdown. Something to the effect of, "Come up with your own thing, and see if it catches on." He noted that the ambiguity is probably what has made Markdown useful to such diverse groups with different needs, and should be preserved.
I've landed on the guy's markdown pages (he refers to this in the podcast) several times, trying to figure out how to do stuff in markdown. I find the page hard to read (the font is tiny; I always resize it), and the examples rarely seem to describe what I am trying to achieve.
> During that podcast, Gruber encouraged that group to consider not calling what they were doing Markdown.
John Gruber's stance was a little stronger than this - he currently has a reasonable claim to the trademark Markdown, as a term he coined and popularized for this use. This group's use of the brand "Standard Markdown" to describe something the owner of "Markdown" disagrees with seems ill-advised. He's now forced to either try to push them off the name or effectively abandon the trademark to genericization.
He's already lost it to genericization. Trademarks distinguish vendors in a market place; plenty of different people operate services that provide "Markdown" formatting that are not the original vendor and are incompatible. Without having taken any steps to license other people's uses of the term, it's not operating as a trademark in any normal sense (unregistered or not).
I don't know how well genericization applies to this, markdown was a loosely defined specification, intentionally encouraging modification. all the "incompatible" versions of markdown are within what he intended.
further, its just the name of a spec, should the owner of a spec really be expected to continuously hunt down and test/validate every implementation of their specification? that doesn't exactly seem possible in the slightest.
I don't think he would have trademark protections for something like this for other reasons, I do wonder if there is anything similar that applies in this situation
> should the owner of a spec really be expected to continuously hunt down and test/validate every implementation of their specification?
I'm pretty sure thats exactly what trademark law says you have to do. You have to defend your trademark. You can't go ten years letting everyone use the Markdown brand where ever they want, and then suddenly decide one day you want to start controlling it.
So, Gruber is fine with people implementing their own markdown processors without his permission, and still call it markdown, and he even likes it when they do that, he likes the flexibility and multiple flavors of markdown.
But if people implementing their own markdown processors try to write a spec or grammar for what they are implementing... he is not fine with it, and considers legal action? It's okay to write a markdown parser, as long as you don't write a spec for it?
There may be a way to justify that position rationally, but I doubt there is legally. He's already abandoned any claims to trademark, by making it clear he's okay with people making their own markdown parsers and describing them as 'markdown parsers', without his permission.
My position (and what I see others taking) is not a problem with formalizing Markdown, which many see as a good thing, but the name.
If they made this an called it StackMark it would be fine.
But this feels more like a power play. Like when Microsoft came and made Visual J++ in an attempt to take control of Java from Sun. It seems oddly and unnecessarily mean spirited and hostile. The name seems designed to either engender confusion or as a slight against the original.
I'd accept that. Seems unwieldily (so it wouldn't be my choice), but I don't think it's outright hostile to the original.
We've got Disqus, Stack Overflow, GitHub, and others. John has referred in the past that he doesn't mind how GitHub has GitHub flavored mark down. This new one could be called Atwood flavored (to pick a name I know is involved). Or they could have stuck with GitHub Flavored markdown and just expand the GitHub flavor.
> he currently has a reasonable claim to the trademark Markdown, as a term he coined and popularized for this use.
Coining and popularizing a term is not a basis for a reasonable claim to a trademark. Trademark rights stem from one source: bona fide use of the mark in the ordinary course of trade. If its not used as a mark identifying and distinguishing the source of a product in commercial transactions, its not a trademark.
> He's now forced to either try to push them off the name or effectively abandon the trademark to genericization.
If there was ever a good claim that it was a trademark (which I don't see the evidence for), I think there's a pretty strong claim that it has already been lost to genericization, given the long-standing established uses on a variety of unlicensed implementations with differing sources.
The ambiguity of Markdown formats has been nothing but a minor pain to me. It makes it harder to search for syntax advice, that's for sure, and 99% of us casual users are doing just that.
I am excited for a well-documented, standard Markdown format to be the top link on Google.
Is this the same group of people he brought up on the recent episode of The Talk Show? The group that wanted to essentially take away the original credits (or something to that effect) from him?
I don't think anyone wants to take credit away from Gruber. My understanding is that they want to move the language forward. More people than just Gruber use it now. I haven't been following him much recently, but for a long time his attitude was, basically, "You can't change anything without my approval but I'm not going to invest any time in this." The way he has handled Markdown's success over the last few years has not engendered my respect.
Why is it important that the new thing have the old name?
Reducing user confusion is one possible answer, but I expect if you are going to argue that, you end up with the name not mattering because most of the users aren't even aware of it.
People are definitely aware of the name. It would be a complete non-starter to have a name that didn't reference "markdown" in some way when the project is an effort to standardise markdown.
There are certainly a large number of people that are aware of the name, I'm not disputing that.
My point is that there are tens of millions of redditors that aren't. I would also guess most light users of Stack Exchange sites are not very aware of the name.
For all those people, I don't think the name matters. Also, the heavier, more interested users will likely not be disrupted much by a different name.
From the podcast linked below, my rough summary of his position: Essentially, that while a spec that cleared up some ambiguity might be useful and is a task he might undertake someday, calling one thing "true markdown" and other flavors not wouldn't be useful. If Github wants to have a version of markdown that supports code better than a blog engine needs, good for them.
To be clear, "Standard Markdown" is only trying to address the ambiguity of the syntax. Sites are still going to implement Standard Markdown plus some ad hoc extensions, so it will still be the same practically in that regard.
When you are considering how two things are alike, don't forget to also think about the ways in which they are not. Unlike with HTML, content producers who write Markdown, don't need their documents to be parsed correctly by many different engines. They only have to target the one they are using.
It is not the first time this happens. It might be a good idea to merge the comment trees and let both links show at the top of the page for these cases.
No, but in the case where there are two posts covering the same story on the front page, it's certainly a factor.
If one url had been obviously better than the other, we would have kept it and (if necessary) assigned it to the thread with more comments. In this case, neither url was obviously better. That's why I asked, and also why the responses were contradictory.
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 ;)
I'm currently trying to get a project started to convert between various file formats typically used for writing/word processing (https://github.com/uxproductivity/DocFormats). Markdown is one of the languages I hope to add, and I've been planning to use the Multimarkdown grammar. But if I can make a convincing argument on the list for using something like this, it will make things a lot easier for everyone hopefully.
It's very much like Pandoc, but with two (three?) major differences:
1. Uses the Apache License (Pandoc is GPL). The code for this project is part of a commercial, closed-source project (and needs to continue to remain part of this project) so sadly this rules out Pandoc on legal grounds. I've also had interest from others in seeing such a library unencumbered with the GPL restrictions.
2. It's written in C, not Haskell. The commercial product (UX Write) runs on iOS, and I'm not aware of any Haskell compilers for iOS. I think there are some efforts underway, but at least when I began this two years ago C seemed the natural way to go.
3. It does non-destrctuctive updates, meaning you can make a change to the target file, and then update the source based on the modifications. Doing so will leave any elements in the source document which were unable to survive the translation intact. I'm not sure if Pandoc does this.
For HTML to Markdown this works in Pandoc, because HTML elements are valid Markdown. Haven't tried with other target formats.
One option if you can run Haskell code somewhere is to use the Pandoc library, which will produce an in-memory structure that you can manipulate as the user makes edits.
> Have you had any interest from others in seeing your commercial project unencumbered from legal restrictions?
I have, yes. But currently it's my only source of income, and I need to maintain said income, otherwise I will not have the resources to devote to development of the app (both the closed source parts and open source parts).
If I could make the same amount of money (or more) by open sourcing the entire app, I'd happily do it. I know that theoretically at least, there are strategies to do so, and actually I'd like to take this approach if I can find one that works. If you have any suggestions I'd certainly like to hear them (and yes I'm serious).
I'm a strong believer though in the "hybrid" approach, whereby parts of a product are open source (and used by other products), and other parts are kept proprietary. KHTML (now known as WebKit) is a perfect example of this. If it was GPL, there's no way Apple could have built Safari on it, and the project would have continued to struggle as it had been for some time and probably gone nowhere. But because it was under a license that allowed Apple (and later Google) to build a proprietary product on top of it, both companies had a strong incentive to take the library and improve it. Granted, it was LGPL (not Apache), so they were legally required to contribute their changes back to the community.
A proprietary product that brings in money that can, in part, be used to fund development of the open source components of an application is something I see as a good model. But certainly there are others that could be made to work.
> 1. Uses the Apache License (Pandoc is GPL). The code for this project is part of a commercial, closed-source project (and needs to continue to remain part of this project)
You can release code as GPL and still use it in your own proprietary projects, because you retain copyright. You just need to ensure you have a contribution agreement that assigns copyright to you. The risk is that somebody will fork your work and then you couldn't switch to the forked version.
I'm aware of that, but I suspect people will (rightly) be wary of assigning copyright to my company, granting me rights over their contributions that they themselves aren't able to exercise (since doing so would require incorporating code licensed from me under the GPL).
We're currently putting together a proposal to make this an Apache Incubator project and I hope to have it developed as a community effort there. Thus everyone will be able to use it in their own open- or closed-source products if they wish (which will increase the attractiveness of the project for some, who would otherwise avoid GPLd code due to its viral nature). And then no company/individual has any special rights over others who have contributed.
TL;DR Packrat trades guaranteed linear memory usage for worst-case polynomial time; the worst-case almost never comes up in non-contrived input, so it's a reasonable implementation decision to go with the less memory-hungry naive implementation.
Depends on the algorithm; the naive recursive algorithm takes worst-case exponential time, while the packrat algorithm guarantees linear time.
However, for most sensible[1] inputs, the recursive algorithm runs in linear time and constant space, while packrat takes about the same time, but with linear space usage.
[1] Where "sensible" is defined to be "amount of backtracking is bounded by a fixed small constant, as is grammar nesting depth" - conditions that hold for most human-generated files matching useful grammars (I've been working on a new PEG parsing algorithm; it doesn't work so well, but the results I've been getting in testing about the existing algorithms are quite interesting.)
I was thinking more that maybe some aspect of markdown was not easily expressed using a PEG (it's the same implementer behind both the parser in Pandoc and this project) .
I think code blocks don't track indentation. A code block is just a bunch of lines beginning with 4 spaces (or blank lines) and the rest (when >4 spaces) are treated as leading spaces.
I generally agree with the sentiment that this is going to just add more confusion, but since I've recently been writing a bunch of Markdown docs and exploring different static site generators, I've found that most link back to Markdown.pl as their "source" and despite that, each is using a different middle-man Markdown parser which has different output.
It's one thing to say, for example, that you support Markdown, or MultiMarkdown, or Pagedown style, but another when you just say Markdown and link back to the original, and produce different output. This seems pervasive, and a Standard Markdown that is "one Markdown to rule them all" would be helpful.
Of course, others have pointed out that this spec lacks a formal grammar, and that it also lacks a number of other Markdown elements, so it would need to become a lot more well defined and a lot more mature to be useful.
I think this is great, I'm all for extending markdown for specific situations but I think the base h1, li, and p tags should be clearly defined. It appears that most parsers could adopt most of the spec without breaking backwards compatibility. (I'm probably wrong.)
There's an obvious annoyance with markdown like this, where a lack of a blank line after the headlines causes problems but only in a few parsers. I'm glad to see most of them do the right thing.
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.
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.
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.
Lucky for these guys, they seem to have some pretty powerful names behind the project. I think this will go pretty far towards becoming the single standard that everyone references.
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 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...).)
I understand the herd effect - so I put it in user-facing projects that I'm working on - but I don't understand what's driving the herd. Specifically, I don't see any advantages over asciidoc and find it awful to work with.
edit: I do understand this project, though. It'll get rid of the horribleness in implementing markdown, at least.
Reddit uses Markdown. GitHub uses Markdown. HN (sorta) uses Markdown. Wordpress, Tumblr, and Discourse all use Markdown. If I used Markdown for my own User-Generated-Content Textareas™, people might already know it.
If I use Asciidoc, I may as well be using SGML. It's just another (nice!) syntax you're forcing people to cram into their brains.
I'd never heard of asciidoc before this thread. I suspect asciidoc suffered from being associated with docbook? And perhaps it's just that Perl was much more popular for writing forums in than Python, at the time.
The way to remember it is just that you're parenthesizing the URL. Naturally, you might write it "look at this thing (http://example.com)" - in Markdown, you do the same, but with brackets to indicate where you want the link to show up. "look at [this thing](http://example.com)"
I don't buy for a second that <a href="http://example.com">this thing</a> is more intuitive than that, even if you disagree about the specific brackets used.
Actually, as a C++11 user, it's a lot like a lambda declaration: [capture](parameters){…}. Certainly the brackets are in the same order. The similarity between lambdas and Markdown URL's is actually a nice feedback loop when I'm doing C++11 code.
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.
Asciidoc (and the myriad of other markup languages that are supported in their file rendering) is not supported in comments/issues/pull requests, only "GitHub Flavored Markdown".
I don't know that reddit's a secret, but it certainly uses markdown.
Which is key among the reasons I _vastly_ prefer composing longer-form content there than on G+, which has its own bastardized, incomplete, inconsistent, buggy, poorly-parsed tagging format.
Though I do wish that Markdown used the G+ syntax for bold vs. italic:
*This is bold*
_This is italic_
I find markdown's doubled-character syntax ugly, and have my own convention of:
I find the dokuwiki table syntax to be pretty simple and effective, or the markdown extra version. Don't know why none has been made a standard part of markdown yet. Seems like it must be due to backlash against table-based web designs of the 1990s, (which resulted in an entire generation of web developers thinking that tables are inherently evil and an entire generation of non-developers who just do things in MS Word or Excel instead because it's relatively easy to make tables).
A standard can be descriptive (bottom-up) or top-down (prescriptive). A descriptive standard will only check and document common-ish features to implementations. Tables are not one of them.
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.
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.
But as long as the correct HTML is output it doesn't matter how it looks. I mean that's the whole idea of separating structure from representation, right?
Personally the first time I used markdown was when I signed up for SO.I used to be a BBCode guy. But there are other formats, like rst.Strangely they are not as popular,despite the fact that they have a spec.
Cool, was wondering if John MacFarlane was part of it (and he is). The standard implementation is in C[0]. I guess this is a good middle ground (from a social perspective, not from a technical one). This is a very nice initiative. In particular we can hope that all those markdown editors will be perfectly compatible with each others, or that any deviation from the standard will be very well approachable.
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
The dingus could do with a mini reference so that new markdown users can trial "standard markdown" without having to bring up a separate reference source alongside it.
Default text would be good to, perhaps with a button for clearing the box.
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.
The counter argument is that simple tables are simple. And as silly as that sounds, a typical expository essay might easily include a 2 x 2 'table' to explain some principle (I call them McKenzie tables since every presentation from those guys seemed to include one or more). Or simple columnar data like the current price of the Macbook pro line, or any number of things that are represented easily and efficiently in a simple table. That is why I like Fortin's syntax something like:
Reads easily in text and markdown's easily as well using multimarkdown (my current go to implementation). Use your CSS to style the selectors tbody, thead, and colgroup and you're off to the races.
The problem that I see with that is it makes editing a table very difficult. Sure, if you know exactly what you're going to put in a table, then it might be worth it to draw all of those lines, but as soon as you need to go and edit the content of a cell, or remove a column or something, you might have to go and edit unrelated parts to maintain your formatting. It also seems like it'd be a real pain to parse. I'm not sure I know of a better solution, except to suggest that markdown might not really be suited for tables, and it's better to just use HTML for that part.
In Github-flavored markdown, the spacing is optional. So it's actually easier to edit than an HTML table. Though a WYSIWYG editor is still beneficial for these kind of things.
Not quite related, but if you haven't seen how emacs and org-mode handle ascii tables, it's pretty amazing! It will reflow automatically, and tabbing works just like you would expect in a spreadsheet application.
It's amazingly easy to run into simple writing tasks that require tables. E.g. if I write a simple product review, I might want to produce a comparison table rather than describe differences in long-winded and opaque prose.
Does stackoverflow allow ```ruby now? I thought their thing was different. There is a stackexchange person on this, so does that mean we will be able to ````mylanguage on stackoverflow sites?
Stack Overflow does syntax highlight Ruby its just a different syntax instead of ``` its like <-- language --> or something. At least thats what I remember.
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.
Since when Markdown was just about ASCII text ? then we can't write French, Arabic, Chinese using markdown ?
my whole point is to define a syntax indication in the specs on how RTL elements should be identified when converted to say HTML. when converted, THAT element (or the whole document) would contains dir="RTL" attribute in its tag.
for example, something like this:
<-rtl--
Foo
Bar
would convert to:
<p dir="rtl">Foo
Bar
</p>
Prettifying won't help... RTL elements/document should be indicated in markdown
I don't agree that it should be defined in markdown, RTL languages should be detected by the parser and be outputted within a block-level element, P is good, with dir="rtl" as you mentioned.
I really disagree, RTL should be defined in Markdown,.. as the ZEN of Python says:
"Explicit is better than implicit."
this is a case where indicating RTL should be done explicitly, letting the parser/browser or whatever do the work still won't help. Why?
think about a mixed text of one sentence/line where there's only one word in Arabic at the beginning and the rest of it is Latin... the browser/parser or whatever will think of it like LTR text because the sum of latin words > sum of Arabic words. which is False.
A live example of this is Facebook. it does actually a Layout detection based on the content's language in comments. but it sucks in many cases. try to write a comment in Arabic with a mention of someone's name (the name in Latin) to see what I mean.
so IMO, neither dir='auto' nor the parser can detect this implicitly, we still don't have the AI for smarter detection, even if we have, there are cases where you want RTL regardless of the content. thus it SHOULD be defined in Markdown.
It's not about ASCII, it's about where that ASCII is presented whether it's terminal emulator like mlterm or a text box in a sane OS like Ubunutu. RTL languages can be detected and viewed correctly without any additional information.
Addendum: I'm using 'ASCII' only because in this context we are talking about 'plain text' and not the actual 7-bit ASCII. UTF-8 encoding is a given when talking about RTL languages.
Where does ASCII come into it? UTF-8 plain text supports RTL fine. The point of markdown is formatting that looks ok in plain text and can be prettified into HTML. It ought to work when that text includes RTL.
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.)
I definitely see your point of view. Design by committee is enough to wear down the most passionate person. However, maybe they could have said a simple "We're actually working on a spec and two portable implementations (JS, C) based on the original article," and that might have gone a long way to prevent people from wasting their time.
Ouch! He's defintely not happy, but I think there needs to be some more structure around the format. I love using Markdown, but it's annoying finding out what quirks work on different parsers. For example, GitHub supports hyperlinked images, but Designer New's comments don't. I think the spec has too many open ends and needs wrangling. I'm just not sure if this was the best way to go about doing it.
I don't disagree. I think they shouldn't have called it "Standard Markdown", though, as that's appropriating it. "Community-flavoured Markdown" or something would be far better.
Either way, they're forcing his hand. He's been sitting back while others have been simply trying to get a spec.
If he wants to be grumpy, cool. GH, SO, and Reddit will forge on. If we wants to litigate, cool too; bring it on.
Those 3 communities have large overlapping userbases. This baby is being born, Gruber or not, and nobody will remember in n years about the current kerfuffle.
It's good something like Markdown exists, and it shouldn't have had to flourish despite not having an unambiguous formalized spec.
> If we wants to litigate, cool too; bring it on.
He's got nothing to litigate about. The trademark claim on "Markdown" had no place in his copyright license, nor does that copyright license affect this specifications project in any meaningful way (because they don't use the copyrighted work).
That's why the only valid argument so far has been over the implications of the word "Standard" in "Standard Markdown" being a "dick move" (which is a personal POV, which is fine, which I also happen to disagree with).
And how would that work? Let's assume I wrote BrainFuckStandardMD, the implementation for Brainfuck. I would base it solely on the spec published as Common Markdown. I would not in any way use the copyrighted code as basis for my implementation, so it is not derived from it. I don't use the name markdown, so that even the ficticious claim to a trademark would be void. On what grounds would he sue me?
I don't think having a standard will in any way reduce the variance of implementations and which implementations (custom or otherwise) sites choose to use. Some wont want to support images. Some won't want to support inline html.
There was an obvious, demonstrable need out there for implementation consistency. Gruber didn't step up to help resolve confusions, so he has no right to complain when other people do the hard work.
Well taking something someone else created and rereleasing it using relatively the same name while insinuating it's the official or standard version is what's known in the industry as a dick move.
Imagine if you forked GTK and named it "Official GTK" and then blamed GTK for not doing what you wanted them to, so its obviously their fault that you needed to steal their name.
"Standard" carries with it a significant heft in meaning, especially authority, that "Something" else is unlikely to carry. Authority that is illegitimate without the original author's involvement.
It is kind of a dick move, and sadly this sort of thing (specifically, not respecting existing name usage) appears to be becoming more and more common. And sadly outrage from the community seems to be ineffective at preventing this stuff. Look at Google pilfering the name "Go" for their new programming language[1].
Yeah, it was a slightly different situation, but still, there was a name collision and in the end nothing was ever done about it.
I don't see how you can not see that the two situations are similar. Note: similar, not identical. Google stole a name that was already being used in the exact same domain (programming language). Nobody said they borrowed the same syntax or anything, that isn't the point.
And I don't really see the problem there
And that is the problem. People don't care about somebody just coming along and arbitrarily usurping a name somebody else is already using. Of course they may see it differently one day when the shoe is on the other foot. But for now, there seems to be a trend where people don't care about resolving name collisions... and even more so if they're a rich entity like Google or Apple.
And for those who don't follow links: this was the phone number advertised by BSD Unix, a fork of AT&T's Unix, when BSD launched its own commercial distribution.
The resulting legal battle came to be known as "the UNIX wars", and resulted in a legal finding that AT&T had little to no effective copyright ownership of the BSD codebase (a few minor files IIRC). This decision was issued under seal, later broken in the subsequent SCO vs. IBM lawsuit of the early 2000s.
The contretemps has been argued as among the reasons Linux emerged and became as popular as it is: it was a de novo, fully independent, largely POSIX-compliant reimplementation of the UNIX environment that was good enough for those who wanted that sort of thing.
Imagine if you took a look at all the incompatible implementations of 1970's and 1980's C and blamed them for not being compatible, and created a fork called "ANSI C".
Generally with language standards though, the major players involved are all part of the standardization process. A slightly different example might be Microsoft developing an incompatible version of Java and calling it Java (until they got smacked into calling it J++ instead).
Honestly, I'm of the opinion that they can call it Standard Markdown if they want to and there's nothing wrong with that. Gruber's opinion is worth something for sure because of his authorship of the original, but there's a statute of limitations. He doesn't think Markdown needs anything more than his Perl script, but the rest of the internet has disagreed pretty strongly for long enough now that it's fine to treat him as absentee.
I realize that the "S" in ANSI stands for "Standards", but I think it is obvious to anyone who cares that the things which come from ANSI are produced by a non-profit national standards committee ( http://en.wikipedia.org/wiki/American_National_Standards_Ins... ). As the Wikipedia page says, ANSI "oversees the development of voluntary consensus standards for products, services, processes, systems, and personnel".
I don't really see this as a valid comparison to what the folks behind "Standard Markdown" are doing. I agree with others that the Standard Markdown name was a poor choice. For me at least, it feels like they are saying "We're taking over now". I don't know if that indeed was their intent, but that's the way it comes across to me. I think they should choose a different name.
For the record, I really don't have any skin in the game here, as the controversy doesn't really affect me much.
That's an argument in favor of them making a spec, not an argument in favor of them using the name "Standard Markdown."
They could have called it any number of other things that don't make the same claims that "Standard Markdown" does. Off the top of my head; Common Markdown, Clean Markdown, or better yet don't actually use the Markdown name, simply imply it such as Forkdown or Sporkdown.
That doesn't really address the main objection to the name "Standard Markdown" unless you already know what the problem with the name is (and thus the implications of the slight difference.)
It would be best if the team would just go another route entirely.
To be honest, I think this industry wide devotion to Markdown is hilarious, since to me it's a pretty garbage way of solving an easily solved problem. The main/only thing in its favor is its ubiquity.
Standard implies "normal" or "default" as well as "standardised".
Whatever you may think of Markdown (that is markdown as created by Gruber), it surely isn't unreasonable to suggest that if any version can make that sort of claim, it should be the original.
What percentage of all Markdown written is on GitHub, Reddit, or Stack Exchange? What percentage of rendered Markdown served to users is from those sites? Tough to estimate, but I would say it's certainly a majority. Surely any flavor of Markdown agreed upon by those sites can make a pretty strong case to be considered "standard."
Out of curiosity, what do you think is the better "easy" solution to the problem Markdown is trying to solve?
How would "Common Markdown" be any better than "Standard Markdown"? Doesn't it sort of imply the same thing?
(btw I'm in the camp that thinks "Standard Markdown" is just fine, though I do hope they get the formal specs nailed down a bit more solidly on the ambiguities discussed upthreads, preferably with some kind of formal grammar)
> There was an obvious, demonstrable need out there for implementation consistency.
I hear this sentiment a lot but I just find it unconvincing.
Over the past decade, Markdown became the lingua franca for transforming plain text to HTML. It did this entirely on the back of Gruber's spec, implementation, and the community that developed around the project. It hasn't had a formal spec this entire time and it's done just fine.
Are there some undefined behaviors in the original spec? Sure. But it was just designed to handle the most common situations, not everything.
While Markdown is certainly used widely and is based on Grubers original specification, the practical real-world usage is a lot more complicated that just relying on the original specification.
Reading Atwoods issues with original Markdown[1] (which is significant given his extensive experience in products that rely heavily on Markdown), it is quite clear that Markdown as a format has prospered almost in spite of the original specification.
I can understand his point of view on the matter. He created something that is loved by millions, and he feels that this project is trying to wrestle ownership from him.
On the other hand, he created something. He released it to the wild, and then he didn't aptly respond to the need for it to change. His response to "Markdown needs work" is basically "Whatever! It's my project, you're not the boss of me!" How can he seriously be shocked that people would go around him to try and develop a spec that made more sense?
As to using "Standard" in the name, if Reddit, StackExchange, and Github all agree to use this Markdown spec, I think that there could be a reasonable argument that it is standard. In reality, they are wrestling ownership of Markdown away from Gruber. In a couple of years Gruber's Markdown will probably only be useful for historical purposes. Why? Because he failed to respond to the real needs of his users, so those users with the largest stake took matters into their own hands.
And that's his good right. Calling it "Standard Markdown" when he explicitly chose not to participate is just as childish a move as this: http://www.notmarkdown.com
It doesn't matter that he was asked to participate and didn't want to. What matters is whether he did or didn't give specific written permission that they could use the name Markdown. It's set in stone on the license.
Markdown-related projects have been using "Markdown" in the name for years (in violation of the license). Gruber has yet to get upset at "Github flavored Markdown" or "MultiMarkdown" for example. Methinks that it has less to do with the name, and more to do with their motive of becoming the new de facto Markdown spec that has Gruber up-in-arms.
> What matters is whether he did or didn't give specific written permission that they could use the name Markdown. It's set in stone on the license.
If you're going to paste the very same argument multiple times all over this discussion, you should at least first make sure it is correct.
It's been explained several times now that this is not how that license works. It doesn't work (not binding) to specify trademark-related things in a copyright license. And anyway a copyright license only affects those bound by the copyright on the work: The work, being the code of Gruber's perl markdown parser. Which this group hasn't used at all. Usage of the name "Markdown" is something which has nothing to do with copyright but trademark law. Trademark law works very differently, definitely not by just writing up a license (like copyright) and simply said: The name Markdown is not trademarked (currently, and given its usage, also probably not in the future).
So, is it the use of "Standard" or "Markdown" that's the issue here? I don't see people complaining that "MultiMarkdown" is appropriating the name, for example.
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.
376 comments
[ 2.1 ms ] story [ 359 ms ] threadA much earlier lengthy email response from Gruber around 11/2012 evaluated each of the changes Stack Overflow and GitHub made to Markdown one by one (there were some he agreed with) and essentially said "ambiguity is a feature" at the end.
We disagree about that.
Using (basically) the same name strikes me as somewhat hostile given the views Gruber has expressed, and likely to cause confusion to end users.
IANAL.
I would avoid this wording. I would instead say:
It's a flavor of markdown. The flavor is heavily documented. The flavor's name is "Standard Markdown".
My problem with the name "Standard Markdown" is I don't think it's going to be clear enough, I think people will think it's the same thing as Markdown (which it's not), under the theory that "non-standard" would have an obviously different name such as "Lisp Markdown" or "Japanese Markdown".
If they had used a word other than "Markdown" I wouldn't have a single problem, I would cheer them on.
I don't see a real benefit in this name to anyone, but I see serious downsides.
That's certainly an unbiased translation :rolls eyes:. If you want to have a good-faith debate, you should avoid tendentious re-writes of your interlocutor's arguments.
You clearly don't like his position.
Be he has explicitly chosen not to make a specification, he's had years and numerous requests. From what I've seen/heard John Gruber likes that it isn't formalized with a spec.
So if a group of people, especially a large group with 10s of millions of users (at a minimum) decides to write a spec and name it "Markdown" over Gruber's wishes it sounds like trying to take ownership from him.
My phrase was glib, but I don't think it's that far off from many of the comments expressed here.
The reasons that he didn't write a spec after requests is very likely post-hoc rationalisation, behind the simple reason that writing a spec is not a fun task.
Because it communicates the right thing to users >90% of the time. If you learn the language specified here and then go write some reddit comments or file a GitHub issue using that language, it will do what you expect.
The few places where it doesn't you probably don't have an intuition about anyway.
If you treat "markdown" as an improper word describing the language and not some sort of proper "brand name" that describes provenance, then what they describe here is "markdown".
It would do the same thing if all those groups (since they seem to be onboard) had decided to call it TextMark or CommentAscii or some other new term. As long as they all use the same term it would be fine.
But instead they're basically trying to strong-arm redefine Gruber's name, and they'll win because they're bigger.
It's in terribly poor taste.
This will actually make things worse too, because they've invented another standard. People will see 'old' Markdown sites that don't work like 'new' Markdown sites ('Standard' is too subtle) and ascribe it to a bug in 'new' Markdown.
They haven't avoided confusion in the way a new name would have done very quickly.
Same confusion, acting like a jerk to take over someone else's creation. High class there.
As I read it, if you want your Markdown documents to be rendered a specific way, you choose/configure/write a Markdown parser that renders it that way (possibly with the assistance of an additional stylesheet). If you need a particular extension for a task (tables, syntax-highlighted code blocks) you can use an parser that supports them. And if you need specific HTML elements, you can use them inline.
The way I read it, Markdown is intended as an _input format for markup tools_, designed to be both legible and meaningful as plain text. Any meaning that can't be explicitly encoded in the ASCII format, including the specific HTML tags used to render a given construct, is outside Markdown's scope and should probably be stored in a more structured format.
Not cool.
He can still choose to be caustic and demand a rebrand, but it'll only delay the inevitable replacement of the original markdown.
The difference here is that they wrote a spec for the variation they plan to implement? That somehow makes it not cool?
Or just that they're calling it "Standard Markdown"? Could the dispute be avoided if they called it "A Standardized Markdown", or "Standardized Flavor of Markdown" instead?
There are many markdowns, and Gruber likes that, fine. Other people would like to standardize and make compatible implementations. Nothing's stopping people who disagree from continuing to ignore the standardized spec. But where' the logic in saying "you can release whatever markdown variations you like, as long as you don't try to make different implementations compatible with each other."
Standard markdown lies about where it comes from and thus claims more authority than it is due. Formalize it all you want, then name it coding horror markup.
I don't see how stealing other peoples credit is acceptable.
Edit: In case what I am writing is misunderstood, I am not trying to be snarky or negative. I am just curious.
No ambiguity, no 500 different things called XMarkdownY
admittedly the worst example for such a topic, but, we still don't have a situation where all browsers agree on all renderings, and all of them still don't follow the spec, and in some areas, they don't plan to.
I can see html requirement being a pain-point for anyone implementing standard markdown.
And if you're doing that, it's pretty obvious to call the effort to produce a standard implementation Standard Markdown. Unless you think Github-StackOverflow-Reddit-flavored markdown is a better name :)
>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.
Gruber is not being irrational. He is operating under a different paradigm, which he explained last time Marco Arment was on his podcast. He is approaching this from the view that the optimal markdown implementation for a code site like GitHub is different to the optimal markdown for a commenting site like Reddit. Standardisation just locks in a suboptimal implementation for everyone. Whether you agree or disagree, it's at least a rational viewpoint.
The creator of the project let you do anything with it other than use the name markdown for a derivative product. They went ahead and did that. A completely unreasonable move that is just spiteful.
Documenting your own Markdown flavour will be easier if you can say "It's Standard Markdown, plus/except these features...", instead of "It's part of the soupy world of 'Markdown', but here are the features that some/all other implementations don't have...".
> He did copyright everything. Explicitly.
I didn't realise that. In that case he can force them to change it if he doesn't like it, right? I don't get why people are talking about honour/decency.
This has nothing to do with my view point, it's simply a fact of law: you can't copyright a name. No matter what text you put somewhere says, it doesn't magically apply.
Another way to look at it is this is just another implementation of markdown -- one that some of the bigger names in the markdown-business are going to support moving forward.
Gruber seems to be a bit of a dick about it. Maybe he got surprised and it hit him harder than expected today. No surprise though, he's now about to be usurped. He sat on his hands for years. In the release today (and forever) they give him large amounts of due credit. The Talk Show crowd (I'm a listener) will grumble, and fanboys on Twitter will support him and jeer Atwood personally, but oh welp. There's one party actually advancing technology, the other resting on laurels.
He kind of mentioned being a benevolent dictator on the [podcast 88 discussion](https://overcast.fm/podcasts/episode/344902019595#t=4527), but what important decisions has he actually made lately? It seems to me he just points back to his implemention perl script. Genuine question. He hasn't made a spec because (loosely) "why have a spec; just do whatever you want, take a look over here".
So it's a variant of his perl script. Great, that sounds exactly as he mused everyone should do. I can see how it rubs him the wrong way with "Standard Markdown".
Also: by doing this, the group will be forcing his hand. They've released it magnanimously, invited him to be a part of the process for years. He didn't respond in kind, labeling it "Atwood's crusade".
He may not like the name "Standard" enough to do something about it. He can choose to pursue legal options. I doubt he wants to spend any money on that. You've got to assume GH, SO, and Reddit went over the Markdown license on DaringFireball.
He can choose to be grumpy about it, but this is happening. Those 3 entities have massive persuasive force with their user bases; enough to become standard.
Ambiguity is not a feature it is a bug. It is not optimal.
This "Standard" makes things even worse. There are plenty of sites already on the internet that say they accept "Markdown", and that meant something: that it implements Gruber's formatting, and perhaps some extensions (and sites with extensions are normally clear about the fact that they're extensions, e.g. "Github-flavoured Markdown"). Now people will see a site that accepts "Markdown", expect it to support a feature from "Standard Markdown", and get angry when it doesn't.
Markdown is not for that and the exact reason to use it is that every site could customize it for their usage. Contrary to your assertions (which I see is backed by no argument) abiguity in markdown is a feature. Ambiguity in HTML was a bug.
I don't see a problem.
During that podcast, Gruber encouraged that group to consider not calling what they were doing Markdown. Something to the effect of, "Come up with your own thing, and see if it catches on." He noted that the ambiguity is probably what has made Markdown useful to such diverse groups with different needs, and should be preserved.
Just several hours to sift through :)
"Atwood's crusade"
https://overcast.fm/podcasts/episode/344902019595#t=4527
John Gruber's stance was a little stronger than this - he currently has a reasonable claim to the trademark Markdown, as a term he coined and popularized for this use. This group's use of the brand "Standard Markdown" to describe something the owner of "Markdown" disagrees with seems ill-advised. He's now forced to either try to push them off the name or effectively abandon the trademark to genericization.
further, its just the name of a spec, should the owner of a spec really be expected to continuously hunt down and test/validate every implementation of their specification? that doesn't exactly seem possible in the slightest.
I don't think he would have trademark protections for something like this for other reasons, I do wonder if there is anything similar that applies in this situation
I'm pretty sure thats exactly what trademark law says you have to do. You have to defend your trademark. You can't go ten years letting everyone use the Markdown brand where ever they want, and then suddenly decide one day you want to start controlling it.
But if people implementing their own markdown processors try to write a spec or grammar for what they are implementing... he is not fine with it, and considers legal action? It's okay to write a markdown parser, as long as you don't write a spec for it?
There may be a way to justify that position rationally, but I doubt there is legally. He's already abandoned any claims to trademark, by making it clear he's okay with people making their own markdown parsers and describing them as 'markdown parsers', without his permission.
If they made this an called it StackMark it would be fine.
But this feels more like a power play. Like when Microsoft came and made Visual J++ in an attempt to take control of Java from Sun. It seems oddly and unnecessarily mean spirited and hostile. The name seems designed to either engender confusion or as a slight against the original.
We've got Disqus, Stack Overflow, GitHub, and others. John has referred in the past that he doesn't mind how GitHub has GitHub flavored mark down. This new one could be called Atwood flavored (to pick a name I know is involved). Or they could have stuck with GitHub Flavored markdown and just expand the GitHub flavor.
Coining and popularizing a term is not a basis for a reasonable claim to a trademark. Trademark rights stem from one source: bona fide use of the mark in the ordinary course of trade. If its not used as a mark identifying and distinguishing the source of a product in commercial transactions, its not a trademark.
> He's now forced to either try to push them off the name or effectively abandon the trademark to genericization.
If there was ever a good claim that it was a trademark (which I don't see the evidence for), I think there's a pretty strong claim that it has already been lost to genericization, given the long-standing established uses on a variety of unlicensed implementations with differing sources.
I am excited for a well-documented, standard Markdown format to be the top link on Google.
Reducing user confusion is one possible answer, but I expect if you are going to argue that, you end up with the name not mattering because most of the users aren't even aware of it.
My point is that there are tens of millions of redditors that aren't. I would also guess most light users of Stack Exchange sites are not very aware of the name.
For all those people, I don't think the name matters. Also, the heavier, more interested users will likely not be disrupted much by a different name.
https://twitter.com/gruber/status/262287246953164800
It definitely seems shitty to take the name of his project without his permission, regardless of how righteous they think the cause.
Edit: since this thread has all the discussion, we'll keep this one.
The link it references is: http://blog.codinghorror.com/standard-flavored-markdown
It is not the first time this happens. It might be a good idea to merge the comment trees and let both links show at the top of the page for these cases.
If one url had been obviously better than the other, we would have kept it and (if necessary) assigned it to the thread with more comments. In this case, neither url was obviously better. That's why I asked, and also why the responses were contradictory.
p.s. my blog is awesome
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 ;)
I agree that a universal PEG would be great, perhaps this is the project to base that grammar on.
I'm currently trying to get a project started to convert between various file formats typically used for writing/word processing (https://github.com/uxproductivity/DocFormats). Markdown is one of the languages I hope to add, and I've been planning to use the Multimarkdown grammar. But if I can make a convincing argument on the list for using something like this, it will make things a lot easier for everyone hopefully.
sounds bit like Pandoc: http://johnmacfarlane.net/pandoc/
1. Uses the Apache License (Pandoc is GPL). The code for this project is part of a commercial, closed-source project (and needs to continue to remain part of this project) so sadly this rules out Pandoc on legal grounds. I've also had interest from others in seeing such a library unencumbered with the GPL restrictions.
2. It's written in C, not Haskell. The commercial product (UX Write) runs on iOS, and I'm not aware of any Haskell compilers for iOS. I think there are some efforts underway, but at least when I began this two years ago C seemed the natural way to go.
3. It does non-destrctuctive updates, meaning you can make a change to the target file, and then update the source based on the modifications. Doing so will leave any elements in the source document which were unable to survive the translation intact. I'm not sure if Pandoc does this.
Use GHC. http://www.infoq.com/news/2014/04/ghc-7-8-1
One option if you can run Haskell code somewhere is to use the Pandoc library, which will produce an in-memory structure that you can manipulate as the user makes edits.
That would open up your options considerable.
I have, yes. But currently it's my only source of income, and I need to maintain said income, otherwise I will not have the resources to devote to development of the app (both the closed source parts and open source parts).
If I could make the same amount of money (or more) by open sourcing the entire app, I'd happily do it. I know that theoretically at least, there are strategies to do so, and actually I'd like to take this approach if I can find one that works. If you have any suggestions I'd certainly like to hear them (and yes I'm serious).
I'm a strong believer though in the "hybrid" approach, whereby parts of a product are open source (and used by other products), and other parts are kept proprietary. KHTML (now known as WebKit) is a perfect example of this. If it was GPL, there's no way Apple could have built Safari on it, and the project would have continued to struggle as it had been for some time and probably gone nowhere. But because it was under a license that allowed Apple (and later Google) to build a proprietary product on top of it, both companies had a strong incentive to take the library and improve it. Granted, it was LGPL (not Apache), so they were legally required to contribute their changes back to the community.
A proprietary product that brings in money that can, in part, be used to fund development of the open source components of an application is something I see as a good model. But certainly there are others that could be made to work.
You can release code as GPL and still use it in your own proprietary projects, because you retain copyright. You just need to ensure you have a contribution agreement that assigns copyright to you. The risk is that somebody will fork your work and then you couldn't switch to the forked version.
We're currently putting together a proposal to make this an Apache Incubator project and I hope to have it developed as a community effort there. Thus everyone will be able to use it in their own open- or closed-source products if they wish (which will increase the attractiveness of the project for some, who would otherwise avoid GPLd code due to its viral nature). And then no company/individual has any special rights over others who have contributed.
https://github.com/jgm/peg-markdown/issues/28
Any PEG can be parsed in linear time and space.
Depends on the algorithm; the naive recursive algorithm takes worst-case exponential time, while the packrat algorithm guarantees linear time.
However, for most sensible[1] inputs, the recursive algorithm runs in linear time and constant space, while packrat takes about the same time, but with linear space usage.
[1] Where "sensible" is defined to be "amount of backtracking is bounded by a fixed small constant, as is grammar nesting depth" - conditions that hold for most human-generated files matching useful grammars (I've been working on a new PEG parsing algorithm; it doesn't work so well, but the results I've been getting in testing about the existing algorithms are quite interesting.)
I was thinking more that maybe some aspect of markdown was not easily expressed using a PEG (it's the same implementer behind both the parser in Pandoc and this project) .
I think you're right about lists though.
Unit tests are not enough.
Which is exactly what Markdown's spec consisted of:
http://daringfireball.net/projects/markdown/syntax
This project seems to be repeating the same mistakes, albeit with more clarity in the description and a more extensive set of examples.
It's one thing to say, for example, that you support Markdown, or MultiMarkdown, or Pagedown style, but another when you just say Markdown and link back to the original, and produce different output. This seems pervasive, and a Standard Markdown that is "one Markdown to rule them all" would be helpful.
Of course, others have pointed out that this spec lacks a formal grammar, and that it also lacks a number of other Markdown elements, so it would need to become a lot more well defined and a lot more mature to be useful.
I wrote http://markdownshare.com/ and found it a nightmare to pick a Perl module to handle the formatting, and know what was included and not.
I welcome a standard, although this particular "standard" seems inadequate - due to lack of grammar and test-suite.
For example, this is how CSS syntax is defined: http://www.w3.org/TR/CSS2/grammar.html
or JSON: http://json.org/
or HTTP: https://www.ietf.org/rfc/rfc2616.txt
There's an obvious annoyance with markdown like this, where a lack of a blank line after the headlines causes problems but only in a few parsers. I'm glad to see most of them do the right thing.
http://johnmacfarlane.net/babelmark2/?normalize=1&text=%23+I...!
StackOverflow? (who're also on board via Atwood)
That said I'm sure he has valuable experience with Markdown and is almost certainly using it again in his latest venture.
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.
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...
edit: I do understand this project, though. It'll get rid of the horribleness in implementing markdown, at least.
Reddit uses Markdown. GitHub uses Markdown. HN (sorta) uses Markdown. Wordpress, Tumblr, and Discourse all use Markdown. If I used Markdown for my own User-Generated-Content Textareas™, people might already know it.
If I use Asciidoc, I may as well be using SGML. It's just another (nice!) syntax you're forcing people to cram into their brains.
[this links looks like function in most languages](link function argument)
I don't buy for a second that <a href="http://example.com">this thing</a> is more intuitive than that, even if you disagree about the specific brackets used.
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.
Asciidoc works on github, too: http://asciidoctor.org/news/2013/01/30/asciidoc-returns-to-g...
edit: Thanks Titanous - I assumed it was an optional text filter or something for general use.
Which is key among the reasons I _vastly_ prefer composing longer-form content there than on G+, which has its own bastardized, incomplete, inconsistent, buggy, poorly-parsed tagging format.
Though I do wish that Markdown used the G+ syntax for bold vs. italic:
I find markdown's doubled-character syntax ugly, and have my own convention of: Visually it's far more distinctive.[0]: http://web.archive.org/web/20140830092621/https://michelf.ca...
I find the dokuwiki table syntax to be pretty simple and effective, or the markdown extra version. Don't know why none has been made a standard part of markdown yet. Seems like it must be due to backlash against table-based web designs of the 1990s, (which resulted in an entire generation of web developers thinking that tables are inherently evil and an entire generation of non-developers who just do things in MS Word or Excel instead because it's relatively easy to make tables).
A standard can be descriptive (bottom-up) or top-down (prescriptive). A descriptive standard will only check and document common-ish features to implementations. Tables are not one of them.
PHP Markdown, MultiMarkdown, etc also support that syntax. Stack Overflow is pretty much the exception [2].
I'm not interested in Markdown parsers which do not support tables. They are useless to me.
[1] http://www.reddit.com/about/ - "last month, reddit had 114,540,040 unique visitors"
[2] http://meta.stackexchange.com/questions/138946/can-we-add-ma...
See example #87. Personally I think it is absurd to try and include HTML(5?) in this standard and I would much prefer the tables in github markdown:
https://help.github.com/articles/github-flavored-markdown#ta...
font-family: 'Helvetica Neue', Helvetica, Arial, serif;
I've never seen serif used as the fallback for Helvetica/Arial.
Also: PRs welcome!
http://talk.standardmarkdown.com/t/improvements-fixes-to-the...
> 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.
You certainly can't point users to the spec, which is incredibly lengthy.
See: http://talk.standardmarkdown.com/t/create-a-page-or-subdomai...
Why do <h3> tags have font-size: 100%?
But seriously, who cares?
[0]: https://github.com/jgm/stmd
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
Default text would be good to, perhaps with a button for clearing the box.
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.
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.
https://help.github.com/articles/github-flavored-markdown#ta...
http://kramdown.gettalong.org/
Most of us who syntax highlight code that is supplied in Markdown use Mike Samuel's work: https://google-code-prettify.googlecode.com/svn/trunk/README...
Ruby isn't one of the languages presently supported, but if you add it then a lot of sites will start syntax highlighting Ruby.
http://meta.stackoverflow.com/questions/250157/could-stack-o...
A for effort though.
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...
> انا اسم [روري](http://roryokane.com/)
To understand what I mean, try to inspect your comment, add `dir="rtl"` to the <p> tag of the Arabic text...
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.
my whole point is to define a syntax indication in the specs on how RTL elements should be identified when converted to say HTML. when converted, THAT element (or the whole document) would contains dir="RTL" attribute in its tag.
for example, something like this:
<-rtl--
Foo
Bar
would convert to:
<p dir="rtl">Foo
Bar
</p>
Prettifying won't help... RTL elements/document should be indicated in markdown
I don't agree that it should be defined in markdown, RTL languages should be detected by the parser and be outputted within a block-level element, P is good, with dir="rtl" as you mentioned.
"Explicit is better than implicit."
this is a case where indicating RTL should be done explicitly, letting the parser/browser or whatever do the work still won't help. Why?
think about a mixed text of one sentence/line where there's only one word in Arabic at the beginning and the rest of it is Latin... the browser/parser or whatever will think of it like LTR text because the sum of latin words > sum of Arabic words. which is False.
A live example of this is Facebook. it does actually a Layout detection based on the content's language in comments. but it sucks in many cases. try to write a comment in Arabic with a mention of someone's name (the name in Latin) to see what I mean.
so IMO, neither dir='auto' nor the parser can detect this implicitly, we still don't have the AI for smarter detection, even if we have, there are cases where you want RTL regardless of the content. thus it SHOULD be defined in Markdown.
Addendum: I'm using 'ASCII' only because in this context we are talking about 'plain text' and not the actual 7-bit ASCII. UTF-8 encoding is a given when talking about RTL languages.
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/...
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.)
[0] https://twitter.com/justin/status/507304506007515136
[1] https://twitter.com/markdown/status/507341395137658880
If he wants to be grumpy, cool. GH, SO, and Reddit will forge on. If we wants to litigate, cool too; bring it on.
Those 3 communities have large overlapping userbases. This baby is being born, Gruber or not, and nobody will remember in n years about the current kerfuffle.
Which I think is good. Long overdue, maybe even.
It's good something like Markdown exists, and it shouldn't have had to flourish despite not having an unambiguous formalized spec.
> If we wants to litigate, cool too; bring it on.
He's got nothing to litigate about. The trademark claim on "Markdown" had no place in his copyright license, nor does that copyright license affect this specifications project in any meaningful way (because they don't use the copyrighted work).
That's why the only valid argument so far has been over the implications of the word "Standard" in "Standard Markdown" being a "dick move" (which is a personal POV, which is fine, which I also happen to disagree with).
That would be a quick way to shut it down. Just threaten to sue anybody who _implements_ it.
Hell, just look at C compilers!
Imagine if you forked GTK and named it "Official GTK" and then blamed GTK for not doing what you wanted them to, so its obviously their fault that you needed to steal their name.
Standard Markdown is just that, it's Markdown but standardized. It's exactly the right name given what it does.
Some names are descriptive, some are prescriptive. Just deal with it.
Yeah, it was a slightly different situation, but still, there was a name collision and in the end nothing was ever done about it.
[1]: https://code.google.com/p/go/issues/detail?id=9
http://swift-lang.org/main/
Google didn't appropriate the syntax or standard for the original Go, they just used the same (extremely common) two letter word.
And I don't really see the problem there, there are a multitude of hobby and dead languages with names that may be duplicated in the future.
And I don't really see the problem there
And that is the problem. People don't care about somebody just coming along and arbitrarily usurping a name somebody else is already using. Of course they may see it differently one day when the shoe is on the other foot. But for now, there seems to be a trend where people don't care about resolving name collisions... and even more so if they're a rich entity like Google or Apple.
Some background here for those interested: http://daemonforums.org/showthread.php?t=6563
The resulting legal battle came to be known as "the UNIX wars", and resulted in a legal finding that AT&T had little to no effective copyright ownership of the BSD codebase (a few minor files IIRC). This decision was issued under seal, later broken in the subsequent SCO vs. IBM lawsuit of the early 2000s.
The contretemps has been argued as among the reasons Linux emerged and became as popular as it is: it was a de novo, fully independent, largely POSIX-compliant reimplementation of the UNIX environment that was good enough for those who wanted that sort of thing.
That'd totally suck, wouldn't it?
Honestly, I'm of the opinion that they can call it Standard Markdown if they want to and there's nothing wrong with that. Gruber's opinion is worth something for sure because of his authorship of the original, but there's a statute of limitations. He doesn't think Markdown needs anything more than his Perl script, but the rest of the internet has disagreed pretty strongly for long enough now that it's fine to treat him as absentee.
I don't really see this as a valid comparison to what the folks behind "Standard Markdown" are doing. I agree with others that the Standard Markdown name was a poor choice. For me at least, it feels like they are saying "We're taking over now". I don't know if that indeed was their intent, but that's the way it comes across to me. I think they should choose a different name.
For the record, I really don't have any skin in the game here, as the controversy doesn't really affect me much.
Which the "non-profit national standards committee" is just a collection of folks representing firms in the industries to which the standards apply.
They could have called it any number of other things that don't make the same claims that "Standard Markdown" does. Off the top of my head; Common Markdown, Clean Markdown, or better yet don't actually use the Markdown name, simply imply it such as Forkdown or Sporkdown.
It would be best if the team would just go another route entirely.
To be honest, I think this industry wide devotion to Markdown is hilarious, since to me it's a pretty garbage way of solving an easily solved problem. The main/only thing in its favor is its ubiquity.
Whatever you may think of Markdown (that is markdown as created by Gruber), it surely isn't unreasonable to suggest that if any version can make that sort of claim, it should be the original.
Out of curiosity, what do you think is the better "easy" solution to the problem Markdown is trying to solve?
(btw I'm in the camp that thinks "Standard Markdown" is just fine, though I do hope they get the formal specs nailed down a bit more solidly on the ambiguities discussed upthreads, preferably with some kind of formal grammar)
I hear this sentiment a lot but I just find it unconvincing.
Over the past decade, Markdown became the lingua franca for transforming plain text to HTML. It did this entirely on the back of Gruber's spec, implementation, and the community that developed around the project. It hasn't had a formal spec this entire time and it's done just fine.
Are there some undefined behaviors in the original spec? Sure. But it was just designed to handle the most common situations, not everything.
Reading Atwoods issues with original Markdown[1] (which is significant given his extensive experience in products that rely heavily on Markdown), it is quite clear that Markdown as a format has prospered almost in spite of the original specification.
[1] http://blog.codinghorror.com/the-future-of-markdown/
On the other hand, he created something. He released it to the wild, and then he didn't aptly respond to the need for it to change. His response to "Markdown needs work" is basically "Whatever! It's my project, you're not the boss of me!" How can he seriously be shocked that people would go around him to try and develop a spec that made more sense?
As to using "Standard" in the name, if Reddit, StackExchange, and Github all agree to use this Markdown spec, I think that there could be a reasonable argument that it is standard. In reality, they are wrestling ownership of Markdown away from Gruber. In a couple of years Gruber's Markdown will probably only be useful for historical purposes. Why? Because he failed to respond to the real needs of his users, so those users with the largest stake took matters into their own hands.
There's nothing wrong with making a standard, just don't appropriate the name.
Markdown-related projects have been using "Markdown" in the name for years (in violation of the license). Gruber has yet to get upset at "Github flavored Markdown" or "MultiMarkdown" for example. Methinks that it has less to do with the name, and more to do with their motive of becoming the new de facto Markdown spec that has Gruber up-in-arms.
[1] https://twitter.com/justin/status/507304506007515136
[2] https://twitter.com/gruber/status/507305771265454080
If you're going to paste the very same argument multiple times all over this discussion, you should at least first make sure it is correct.
It's been explained several times now that this is not how that license works. It doesn't work (not binding) to specify trademark-related things in a copyright license. And anyway a copyright license only affects those bound by the copyright on the work: The work, being the code of Gruber's perl markdown parser. Which this group hasn't used at all. Usage of the name "Markdown" is something which has nothing to do with copyright but trademark law. Trademark law works very differently, definitely not by just writing up a license (like copyright) and simply said: The name Markdown is not trademarked (currently, and given its usage, also probably not in the future).
Naming conventions specified in the software license don't apply to 1) non-software works such as a spec or 2) independently derived software works.
There's a great deal else concerning copyright/trademark confusion here: https://news.ycombinator.com/item?id=8271548
So, is it the use of "Standard" or "Markdown" that's the issue here? I don't see people complaining that "MultiMarkdown" is appropriating the name, for example.