Standard Markdown
standardmarkdown.com
standardmarkdown.com
Naming [2] [5]
Closed (initial) development [1]
Lack of formal grammar [3]
Lack of tables [4]
Just use another format (e.g. asciidoc) [6]
Ambiguity is a feature [7]
Markdown is a popular language with an ambiguous, poorly specified spec and buggy default implementation (so buggy that the vast majority of Markdown users have probably never used it, if they even know it exists). Now, we have a much more well-specified English language spec that explicitly addresses the challenges of the grammar, with a test suite that does a much better job of covering the corner cases, and much better default implementations. These improvements are by no means perfect, but they are improvements.
Yes, we need a formal grammar. Yes, we need tables, and other features. Yes, the naming is unfortunate, though frankly I don't feel sorry for Gruber given that Atwood posted a public letter calling for change two years ago. Yes, these are all issues. But it is an achievement nevertheless, and let's celebrate that.
And then we can get back to work.
----
More generally, I think we have issues with entitlement here on HN. Frankly, we have no fundamental right to either the original Markdown or this new version. But when posts like this come up, we hack away at them as if we had a right for better, as if the authors should be working to please us personally. We need to stop acting like we have a right to sentence judgement over what others release as open source.
[1]: https://news.ycombinator.com/item?id=8265469
[2]: https://news.ycombinator.com/item?id=8266370
[3]: https://news.ycombinator.com/item?id=8264828
[4]: https://news.ycombinator.com/item?id=8265299
[5]: https://news.ycombinator.com/item?id=8266073
That never hurt Perl... :-) Sorry, couldn't resist.
Your sentiments are well-taken.
No one "owns" Markdown, and quibbling over words is unproductive.
There is a concept: "a simple in-line markup language that is easy to write and maps clearly to HTML". One instance of that concept is a specific, buggy, ill-defined language called "Markdown".
"Standard Markdown" is another instance of the same concept. This is the way English works: adding modifiers to words that designate one instance of a concept to designate other instances of the same concept.
Getting to an EBNF grammar from the spec would be awesome, but the spec is a great place to start. All spec generation is tendentious, and it is common to have multiple people highly invested in the generation of different specs for the same nominal standard. Politics, as Aristotle tells us, is the master art. This is why.
So you think anyone would think it was totally cool if someone released things called 'Standard Excel' and 'Standard MacOS'? That wouldn't get by without criticism, why should this?
That is to say, you can't really spend a decade or two letting "Markdown" sort of mean whatever people want it to mean, and only then cry foul for the N+1 person to use the term. "Excel" and "MacOS" have not been genericized (is that a word?) to the same extent that "Markdown" has.
"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."
Legalities aside, this is a dick move that goes directly against the license.
As for your genericization argument, what do you think are the first 2 results in Google for markdown? And the wikipedia description (3rd result) includes both the syntax and the 'tool'. Popular != Generic
Also, if the problem with "Standard Markdown" is the use of the term "Markdown", then the license is relevant. But that means that everyone else (Multi-markdown, Markdown Extra, Github-flavored Markdown, Python-flavored Markdown, Markdown Python, Markdown PHP, etc. are all equally guilty of a "dick move". I don't see anyone arguing that calling it "XXX Markdown" is a problem. It's calling it Standard Markdown that they have a problem with, and the license doesn't really address that without also addressing everything else.
I do get the reaction to some degree. I would stop short of calling it a "dick move", but maybe it's a bit tone-deaf admittedly. I just think that the horse has left the barn on taking offense that someone implemented something sort of like what you called "Markdown" and called their version some form of "Markdown".
Gruber is OK with "Github flavored Markdown" because the name makes it sound like a fork. "Standard Markdown" does not sound like a fork. See my earlier comment in this thread for a cite to Gruber verifying that this is his problem with the name.
The thing that makes this weird in that context is that I can't think offhand of any examples where the inventor of "X" has been opposed to the idea of doing anything about the mass of incompatible versions floating around. Usually, you have a language, there are a few implementations, and then everyone gets together to nail down what an "official" version should do. My gut is that at some point, if after a decade of pleading, the maintainer of an "official" version is not stepping up, the community is OK to go on without them, but clearly there are arguments on both sides there.
I don't think anyone would dispute that both Excel and MacOS are, in fact, trademarks established through bona fide use in commerce and which have not been genericized, and which, therefore, currently serve to clearly designate the origin of particular commercial products.
I don't think the same consensus exists with Markdown. In fact, I suspect if there was a general consensus that "Markdown" had some clear meaning, whether or not it was to designate the original of a particular commercial product, the "Standard Markdown" project wouldn't exist.
Some examples of ambiguities:
1. It does not specify precedence. For example, if a line like "~~~" (or "[ref]: /url") is followed by a setext underline, is that a header, or is that the start of a fenced code block (or ref definition)?
2. The spec says: "Code span backticks have higher precedence than any other inline constructs except HTML tags and autolinks". It says as an example that "<a href="`">`" is a HTML tag. What happens for different placement of backticks, like "<a `href=""`>" or even "`<a href="">`" is left unspecified.
3. What is the precedence or associativity of span-level constructs? For example, does "<asterisk>a[b<asterisk>](url)" result in "a[b" being emphasised or "b<asterisk>" being linked?
Thing is, a specification-by-example like this would have to keep an ever-growing list of corner cases and give examples for each of them. To get completely unambiguous, the list needs to be very long, and when it gets very long, it becomes unwieldy to handle for an implementer of the spec.
Hence the need for a formal grammar, which is the shortest way of expressing something unambiguously. But it's not possible to write a CFG for Markdown because of Markdown's requirement that anything is valid input. So the next best thing is to define a parsing algorithm, like the HTML5 spec. (Shameless plug: vfmd (http://www.vfmd.org/) is one such Markdown spec which specifies an unambiguous way to parse Markdown, with tests and a reference implementation.)
So if "Standard Markdown" is NOT unambiguous and wouldn't be, then it's not a "standard", so calling it "Standard Markdown" is not quite proper.
> A specification-by-example like this would have to keep an ever-growing list of corner cases and give examples for each of them. To get completely unambiguous, the list needs to be very long, and when it gets very long, it becomes unwieldy to handle for an implementer of the spec.
Even more troubling, they skipped the chance for some basic innovations which will probably ultimately result in a Standard Markdown 2 spec. So, for example, they are defining Markdown as a mapping to HTML, rather than a mapping to an internal tree structure which can then be serialized to HTML.[1] If you make that change in perspective, then you can have Markdown for other languages too: not just HTML but also literate code in an arbitrary language, for example.
Another innovation which should probably work its way into Markdown as it becomes more of a file format is metadata. It's a little hard to remember, but acceptable metadata tagging was one of the killer features of MP3s, leading ultimately to their global rise. We don't have a good metadata expression for text files, and Markdown's embedded link references are, essentially, a sort of metadata already. Do this before it gets to the W3C so that we can start off a document with a simple
@author: Chris Drost
@author[http://www.w3.org/TR/markdown/2/] "Chris\u00a0Drost"
[1] This isn't a huge change in the language but it's a huge change in perspective. The main decision needed to fix this is to say that the "embedded HTML blocks" should have a special sigil at the beginning which is not the < character of the first tag; those "raw" blocks are then held separately in the Markdown tree, and the serializer to HTML passes the raw blocks through without HTML escaping or embedding in another tag.]
[2] Why not just use backticks? We could, of course. One problem here though is that there is no good way to distinguish those literate-code blocks which are commentary and those literate-code blocks which are code to be executed. If you don't fix that now, it will probably be fixed in SM2.
Honest question here: how do CFGs prevent you from parsing anything as valid input? E.g. AFAICT this CFG in BNF accepts anything as valid input (including no input!)
<s> ::= <x> EOF
| EOF
<x> ::= CHAR <x>
| CHAR
Also, isn't there a compromise between HTML's crazy parsing strategy and a CFG? A formal grammar, even if not context-free.
Actually, I should have said it's not possible to write an _unambiguous_ CFG for Markdown.
Say we need to parse emphasis in span elements. "_a_" is em and "__a__" is strong, but "_a", "a_", "__a" and "a__" are normal text. If we write the rules for all these, we end up with a grammar than can generate the same string in many different ways. To determine whether an "_" is the syntax qualifier of an em or just part of normal text, we might have to look ahead an arbitrary number of characters, and potentially till the end of the input. This is why it's not possible to write a useful (or unambiguous) CFG for Markdown, and this is because of the requirement to not throw an error on any input.
> Also, isn't there a compromise between HTML's crazy > parsing strategy and a CFG?
PEGs have been written for Markdown and they work because PEGs are inherently unambiguous, but use backtracking instead. But those PEGs don't handle nested blocks cleanly.
My own HTML5-ish Markdown spec (http://www.vfmd.org/vfmd-spec/specification/) is not as crazy as HTML5's, but admittedly, is not trivial to implement either.
> But those PEGs don't handle nested blocks cleanly.
What's the problem exactly?
More details on PEG for Markdown: - from the author of the PEG grammar, who's also the spec-writer of "Common Markdown": http://talk.standardmarkdown.com/t/standard-markdown-formal-... - from myself: http://www.vfmd.org/introduction/#prior-work
Also, I wrote an expanded explanation of essentially what I said about CFGs and Markdown: http://roopc.net/posts/2014/markdown-cfg/
The C and javascript implementations use a parsing algorithm that we could have simply translated into English and called a spec. (That's the sort of spec vfmd gives.) But it seemed to us that there was value in giving a declarative specification of the syntax, one that was closer to the way a human reader or writer would think, as opposed to a computer.
Re (3): we have an asterisk which can open emphasis. So, to see if we have emphasis, the rules say to parse inlines sequentially until an asterisk that can close emphasis is reached. The first inline we come to is [b*](url), which is a link. There's no closing asterisk, so we don't have emphasis, but a literal asterisk followed by a link.
Re (1): I believe you are right that the case of a referenc e definition before a setext header line should be clarified. However, the other case seems clear enough. ~~~ starts a fenced code block, which ends with a closing string of tildes or the end of the enclosing container. The underline would be included in that code block either way.
Re (2): I believe the talk of precedence may be misleading here (I thought it would be useful heuristically). The basic principle of inline parsing is to go left to right, consuming inlines that match the specs. This resolves all of these cases. Perhaps the talk of precedence should be removed.
I am no stranger to formal specifications. I wrote what I think was the first PEG grammar for markdown (peg-markdown, which came to be used as the basis for multimarkdown and several other implementations). PEG isn't a good fit, especially for block-level parsing. It almost works for inline-level parsing, but there are some constructs (like code spans) that can't be done in PEGs. It might be worth specifying inline parsing in a pseudo-PEG format to avoid worries like those you've expressed.
I understand what you have now is a provisional spec, but I have reason to believe that a specification based on declaring constructs and defining by examples is never going to get completely unambiguous. A lot of the ambiguity in parsing Markdown lies in the interplay between different syntax constructs. A spec like yours doesn't address them at all, so they remain as ambiguities. All examples of ambiguities I gave involve the interplay of different constructs (more on them below).
> The C and javascript implementations use a parsing algorithm that we could have simply translated into English and called a spec. (That's the sort of spec vfmd gives.)
It's debatable whether translating your code to English is "simple" without talking about memory addresses, pointers and arrays. In any case, vfmd is _not_ such a translation (I'm not saying that you imply that it is). vfmd was first written as a spec, then tests written to match the spec, and then implemented, followed by more tests. (However, the spec did get fixes during testcase development and implementation.)
> But it seemed to us that there was value in giving a declarative specification of the syntax, one that was closer to the way a human reader or writer would think, as opposed to a computer.
I agree there is value in making an easy-to-read syntax description. However, making a readable specification for document-writers and making an unambiguous specification for parser-developers are opposing objectives. The document writer asks "What should I do to get a heading?", while a parser developer asks "How should I interpret a line starting with a hash?". Your spec is good if you target only document writers, but falls short as a spec for parser developers, because of the ambiguities.
In vfmd, I addressed this by creating two documents - one for document-writers and one for parser-developers - that are consistent with each other.
On the specific examples:
> Re (3) ... the rules say to parse inlines sequentially until an asterisk that can close emphasis is reached
Yes, but where does your spec say that an asterisk can not close emphasis if it's contained within a link? As it stands now, going by the rules in the emphasis part of the spec (section 6.4), it should be treated as emphasis, and going by the rules in the link part of the spec (section 4.7), it should be treated as a link. The spec is silent on corner cases where multiple constructs overlap: Does the leftmost construct always win? What happens if it's not a well-formed link? What if three syntax constructs interleave?
> Re (1): ... ~~~ starts a fenced code block, which ends with a closing string of tildes or the end of the enclosing container. The underline would be included in that code block either way.
Going by the setext headers section of your spec (section 4.3), I'm not at all sure why a "~~~" line followed by a "===" line is not a setext header. Yes, your implementation interprets it as a code block, but your spec is ambiguous on how this _should_ be interpreted.
> Re (2): ... The basic principle of inline parsing is to go left to right, consuming inlines that match the specs. This resolves all of these cases. ...
If the basic principle of inline parsing is to go left to right and if all inline constructs should be parsed like that, then "[not a `link](/foo`)" should be interpreted as a link (which is contrary to Example 240 in your spec). Clearly, code spans should have a higher priority, but that needs more than a couple of examples to define correctly.
This principle is also looks contrary to your reply to (3) above, where you say "<asterisk>a[b<asterisk>](url)" is a link, not emphasis.
As noted above, the problem with a declarative spec for Markdown is the ambiguity (which is quite similar to the ambiguity in defining Markdown as a CFG, for example). As long as the spec is declarative, there will be multiple ways of interpreting an input (which, ironically, was the problem that parser-developers found with John Gruber's original Markdown syntax description too). Problems like this cannot be completely solved by providing examples because the combinations between the different constructs are too many to list as examples in a spec.
I only listed these items to illustrate the bigger problems in the design or style of the spec itself. Even if these individual items are addressed, there will always be more coming up, so I don't think it would make sense for me to keep finding and reporting ambiguities to your Discourse forum.
We considered writing the spec in the state machine vein, but I advocated for the declarative style. It may be worth rethinking that and rewriting it, essentially spelling out the parsing algorithm. As you suggest, a parallel document could be created for writers.
I'll need to study your spec further to see what the substantive differences are.
I'll be happy to open a post in talk.commonmark.org on the ambiguity problems caused by using a declarative style for the stmd spec. I'll do that once the forum is back (I can't seem to access it right now).
In parallel, I too will try to work out what the syntax differences are between stmd and vfmd. Meanwhile, please see: http://www.vfmd.org/differences/ (in case you haven't already).
Post on declarative style: http://talk.commonmark.org/t/571
Syntax diff: https://github.com/vfmd/vfmd-spec/wiki/commonmark-vs-vfmd
Criticism is valuable. If I release anything into the public, I expect criticism. Heck, I even look forward to being criticized because it means people care about what I did (even if I did it wrong!)
"Neither the name “Markdown” nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission."
It's a total breach of license, and on a fairly standard BSD too.
I'm seriously getting tired of copy-pasting this, and surprised that ya'll are defending this whole thing. but I guess I shouldn't.
Anyway, I better jet before I start trolling. In the end, I'm ok with making a better markdown, but completely opposed to breaking the law.
Markdown is written in Perl. Standard Markdown has released implementations in C and Javascript. It seems unlikely that they are using Markdown code, therefore I don't think they are bound by anything in the Markdown license.
Now we get into the question of whether an abstract API can be copyrighted -- we all assumed no, although the Oracle v. Google case (about Java), suggested an abstract API could be copyrighted. With, most of HN thinks, fairly disastrous consequences if that holds as law, although I think it's probably going to be litigated more.
I frankly doubt Gruber was assuming that his abstract (poorly specified!) API for Markdown could be copyrighted. And almost everyone on HN seemed to think it would be disastrous if that were the case regarding Java; it would be somewhat hypocritical if the same people think it somehow ought to be the case regarding Markdown.
It's too bad because I actually really like this, but I think it's not going to take off because of all the courtroom drama.
⚫ The spec isn't code. More to the point, it's not a derivative work of Markdown itself. The BSD license applies to the licensed work as a whole. What it doesn't apply to, specifically, is other works which refer to the original. That is: copyright is not trademark, and you cannot embed an effective trademark license within a copyright license.
⚫ Works (parsers, libraries, etc.) based on the Standard Markdown spec which do not incorporate any of Gruber's original Markdown code are themselves not derivative works of Gruber's original BSD-licensed work, and again, are not governed by the license.
⚫ There are a number of things copyright doesn't apply to: functional works (SEGA v. Accolade), simple compilations of facts (Feist v. Rural Electric), and APIs or standards (I'm aware of a few cases involving these, though I don't recall specifically if any are precedent). Specifically, however, a copyright license cannot cover facts or functional design. It only applies to a specific expression of an idea. Paraphrase that idea and you're scott-free.
So while you raise an interesting point, it's moot here.
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.)
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.
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.
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.
"github flavored markdown" sounds like a fork.
"standard markdown" sounds like ownership. Not
my project but shitty
That. Exactly that.
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.
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.
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.
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:
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
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.
| widgets | quality level | cut-off point
| :------- | :----------- | :------------
| frobs | 98% | 90%
| bolts | **65%** | 70%
| splangs | 85% | 80%
https://help.github.com/articles/github-flavored-markdown#ta...
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:
*This is bold*
_This is italic_
_Markdown italic, ALWAYS_
**Markdown bold, ALWAYS**
But I suspect it's also in part simply that Atwood and company never said in public "we are doing this." They just announced it as a fait accompli. Yes, two years ago Atwood and Gruber tweeted at one another briefly and Gruber said he wasn't interested in formalizing the spec. But that's not really an attempt at having a discussion, and it sure as hell isn't an announcement of a project.
I think a formalized spec for Markdown is a good thing. But the way this was handled was still kind of a dick move, and I don't think it had to have been.
> “Standard Markdown” is neither.
Just look at the @markdown timeline, though. That is one of two tweets ever made. The last one was "23 May 2011". It is a bit passive agressive, IMO, to not stay in the conversation and then all of the sudden express your opinion. Not that he doesn't have a right to, but this project is at least a step forward. If he has specific vision for the project he is responsible for leading it.
Widely read blogger independently develops a simple file specification that addresses a real world problem. Simple file format becomes a de facto standard. Developers gripe about ambiguities in the specification. Effort to create a formal, standardized specification is launched. This new effort is publicly denounced by the original specification author.
Markdown is being used by very different products to fulfill different requirements. Having no specification means you can inspire yourself from Markdown and just do your own thing, which is what is relevant.
Markdown is being used by comments systems, issue trackers, documentation programs. Those have very different needs, and having a liberal non-specification is what helped Markdown to be popular.
Coming with a new standard, not called "Standard Markdown" (which I think is very presumptuous, even for a big company) and providing new features (arranging/aligning images, variables, include, mathematic notation...) would have been much more productive.
I mean, who cares of those little differences? When I edit a comment or something, I just hit the preview button (or see the preview real time). I'm not going to learn a specification, and if markdown has to look different on stackoverflow or github or <insert doc system>, so be it.
Markdown is also mean for people who have no idea what a "syntax error" is, I know the specification is meant for implementations, good, but if I want to write an implementation, I want it to be fast and this kind of complicated spec is exactly what prevent me from writing something lighting fast.
I'm really sorry, I don't want to insult your work (which is great), but it looks like a waste of energy to me.
Markdown has become popular enough that a complete, unambiguous spec is good for end-users. If you are building a little text entry thing for your mp3 catalog app, sure, it's nothing to worry about. But when you are github and stackoverflow and google, and end-users are authoring documents, knowing the behavior matters.
For example, on github, to get a decent paragraph title, I must use #### (h4), on some other site that might be h1 or h2 to get the effect I want.
I understand the need to define the grammar precisely, but for me Markdown is highly tighten to the site it will be rendered to.
I'm not against a specification, but I feel this is a lot of work (and again I'm not saying it's badly done) that feels unnecessary.
Taking your google example, they might deviate from the syntax because their comment box is too small. I really don't want to argue, it's just some feeling, it might not be rational, and by all means I'm not saying I'm right. I was expecting (and waiting for) specifications for tons of things, but not markdown.
I don't think this standardization is meant to stop sites from adding their own extensions, it is to make sure that the core markdown always looks the same, no matter which site/parser is being used.
You will say, OK then, but this is not markdown, you'd be right, it'd be some markdown inspired markup, and that's my point, this specification might be relevant to github, and it is, but don't call it standard markdown, call it anything else.
Markdown wasn't designed for the purpose "standard markdown" is giving to it now. Alright, do something new, get traction, but putting markdown in a box doesn't seem to be the best approach to me.
> I mean, who cares of those little differences?
> When I edit a comment or something, I just hit
> the preview button (or see the preview real time).
There's nothing to lose by having a standard. Most markdown libraries I've used let you configure between various flavors of markdown. I'd love to enable "Standard Markdown mode" on two different implementations that need to produce the same output and be done with it.
I still feel that if you write a standard, you should cover some important missing features, like:
- Referencing other parts of the document - Image caption (figures), and figure references
Of course, this list should be discussed, but there is room for improvement.
Such as this: http://jgm.github.io/stmd/spec.html#html-blocks
The tags listed are not a complete list of section elements (missing `address` and `nav`), nor the grouping elements (missing `main`), nor the embedded content elements (missing `area`, `audio`, `iframe`, `img`, `param`, `picture`, `source`, and `track`), and doesn't scratch the form elements (but yet the "HTML blocks" include `form`, `fieldset`, `textarea` and `progress`).
The tags listed also include child elements, rather than just the topmost parent elements that were listed in the original Markdown syntax: http://daringfireball.net/projects/markdown/syntax#html
So we have a list of arbitrary HTML elements that have been declared as "HTML blocks", some of these are not really "blocks", and some are clearly other things, and some things that perhaps should be included are not.
And reading through why this list exists creates a sense that the implementation difficulty (of having to produce a balanced tree) is dictating how Markdown must now be experienced by the users.
Example 99 is a great example of surprising a user by not doing what they think will happen and leaving them with a game of "Guess why it's not working.".
Gruber's Markdown has this goal: http://daringfireball.net/projects/markdown/syntax#philosoph...
> Markdown is intended to be as easy-to-read and easy-to-write as is feasible.
That's it... that's the single big idea that drives the philosophy of Markdown.
And how about Standard Markdown? http://standardmarkdown.com/#how
> one of our major goals is to make Markdown easier to parse, and to eliminate the many old inconsistencies and ambiguities that made writing a Markdown parser so difficult.
Markdown and Standard Markdown have very different goals.
One is designed to make it easy for end users to read and write content for the web, the other is designed to make it easy for developers to parse and process content for the web.
The purpose is no longer the same, a subtle shift has occurred.
For a lot of cases it may be true that fulfilling the second fulfils the first. But crucially, not for all cases.
They are not equal goals, one does not fully imply the other (in either direction). Yes, a better balance could be struck than today... but if the second goal is trumping the first... the users will suffer.
Okay, that came out wrong. While I understand why one would want any input to pass (web comment from non-technical users), I have experienced several failures (wrong emphasis, missing link, weird unintended brackets…) just because the original markdown.pl didn't warn me about some obvious mistake I made.
We need a strict mode, where paragraphs cannot be interrupted, where fenced code blocks must end by a fence (not just the end of the file), duplicate or missing references must be signalled… That, and many other precautions could turn Markdown into a serious and reliable document format.
Besides, this tolerance is complicating the grammar. I don't mind context sensitivity nor ambiguity (parser generators can now deal with both), but I do mind the sheer size. If you ask me, a formal spec (one that can be treated as a DSL and translated mechanically into a parser), should not take more than 300 lines. More than that is probably too complicated to implement, or even use.
> 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.
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.
You certainly can't point users to the spec, which is incredibly lengthy.
Gruber has stated he wants to keep it ambiguous. You may disagree. But Gruber owes you nothing, and you are in his debt if Markdown has been useful to you. Draw inspiration from his project and make your own.
Later, he realized that the releases of the framework he had created were happening without his involvement. But, instead of accusing the community, he said something remarkable which only multiplied my original respect for him:
I never "left" the Lift community.
Yes, I have other project and work in different languages.
What I did was cease to be Lift's benevolent dictator for life.
Lift has grown way beyond one person and the fact that
the 2.5-M4 release was done without me is a strength, not a weakness.
Because, that's the spirit of open source. When you release something to the public, for public consumption, then you must understand that someone is eventually going to fork it up and assign it a different nomenclature, sometimes even a nomenclature that you may not like. In this case, this particular project had no standardization and a part of the community decided to just standardized it. If you don't like this standardization, then simply don't use it. Use what resonates with you. If you feel the standardization has some flaws, then fork it and fix what's wrong. IF people agree with you, eventually they will end up using your fork. It's as simple as that.
What is funny is to see John Gruber who appears to be butthurt about this, when his contributions have grown negligent (https://news.ycombinator.com/item?id=8266574), inconsistent and his recent focus has been more on other (personal) things.[2]
This reminds me of Luca Pasani[3], who released the much popular WURFL repository as open source in a liberal license first, then one fine day, cried foul because other people (including companies) were using it for profit (in accordance with the license), deleted all online repositories and instances of the project released under the old liberal license [4], then re-released the project with a comparatively restrictive license.[5]
In my opinion, releasing something for open, public consumption means you have to develop an honest mindset of accepting that other people WILL benefit from your creation eventually. If you don't get that right, then open source is probably isn't for you. (And crying foul later, is a double standard, if you do)
[1] http://stackoverflow.com/questions/12424617/comparing-lift-w...
[2] like writing controversial Apple articles at daringfireball.
[3] http://en.wikipedia.org/wiki/Luca_Passani
[4] http://en.wikipedia.org/wiki/WURFL#License_update
[5] http://yro.slashdot.org/story/12/01/09/169216/wurfl-founders...
"Neither the name “Markdown” nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission."
No ifs, and, or buts. It is what it is. It didn't meet that condition. It's in breach of copyright. http://daringfireball.net/projects/markdown/license
Soon enough, no one will care. GH, SE and Reddit have enough mass to have their flavour/spec dominate in terms of user base and adoption.
I forsee a possible recursive acronym of the form Foo is Not Markdown in the not-too-distant future.
Or a Mozilla / Phoenix / Firebird / Firefox contretemps.
Gruber really should put on his big-boy pants though, IMO, and thank those who've picked up his ball and run it further down-field from where he'd abandoned it quite some time back.
Yes. Very much so. Personally I'd have been honoured if something I came up with gets big with sites like these, picked up and carried on by smart people like these. Especially if it kept the same name, because Gruber will always[0] get to say: "Markdown? I invented that". That's the big-boy pants part of it: Gruber has that claim. Being "the inventor of Markdown" is pretty much the biggest claim of value Gruber has anyway, not that perl-script his copyright-license pertains to. And it's that value which only gets bigger thanks to this project. IMO it doesn't even make sense to complain about somebody else running with an idea that you haven't touched in years, yet has grown huge on the Internet in the mean time.
[0] https://en.wikipedia.org/wiki/Moral_rights_%28copyright_law%... (in large parts of the world, anyway)
⚫ Hey, I thought of that.
⚫ Hey, other people thought it was useful and/or a good idea.
⚫ Hey, they did the work (or took over the work) for me.
And often on top of that: "oh, someone's added a new idea / cool feature / process improvement that I hadn't even considered".
Sure, sometimes people goof stuff up. Shit happens. But I've pretty much always got other things that are keeping me occupied.
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
It sounds as though this is very much a unilateral decision from one of the many sites that use Markdown to standardise it, masked by what seems to be a call for other companies with an interest in Markdown to join.
It seems a little questionable to me for John Gruber to have been ignored in this process. Afterall, he made Markdown and it probably would have been a better idea to take his rather ambiguous spec, develop it into a proper standard, and then call that version 1.0.
No doubt Jeff Atwood deserves some credit for trying to initiate a standards process for Markdown, but I think he's doing it the wrong way.
No, it's the other way around. Gruber decided to ignore everyone who tried to improve the sad state of Markdown for the last 10 years.
And Jeff is using Markdown for his forum project, Discourse, so that's another chunk of users.
This kind of coalition has the power of numbers to standardize on something, which is why this is so exciting.
“Read the spec, run the test suite, and exercise our reference impementations.”
“impementations” → “implementations”
I couldn’t find a GitHub repository for the code of the website itself, or I would have made a pull request.
Edit: I see there is already a thread about this: http://talk.standardmarkdown.com/t/site-typo-s-one-to-start-...
[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...
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.
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"
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.
It definitely seems shitty to take the name of his project without his permission, regardless of how righteous they think the cause.
They could have called it anything else, but they just had to go for full ownership of the spec. I hope all the indie App Store developers that Gruber is friends with shut this "standard" out.
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...!
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...
## ChangeLog
1.0.2
: Update README
: Update of the script comment in order to reflect the README
1.0.1
: Fix minor bug
1.0.0
I would be interested in what the team behind Standard Markdown thinks about this problem, it does not seem addressed in their spec (but it might be beyond their scope).
Why do <h3> tags have font-size: 100%?
But seriously, who cares?
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...
Why is Gruber not included in the group?
Markdown is often used for one-page webpages due to its simplicity, and thus anchor links become important in this usecase.
Did you even read the start of that license?
> Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met...
I suppose they could just take a right turn and go for "MarkLeft" or something...
Markdown done right.
Default text would be good to, perhaps with a button for clearing the box.
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
This standard seems totally pointless.