## The Future of Markdown

### October 25, 2012

Markdown is a simple little humane markup language based on time-tested plain text conventions from the last 40 years of computing.

Meaning, if you enter this… …you get this!
Lightweight Markup Languages
============================

According to **Wikipedia**:

> A [lightweight markup language](http://is.gd/gns)
is a markup language with a simple syntax, designed
to be easy for a human to enter with a simple text
editor, and easy to read in its raw form.

Some examples are:

* Markdown
* Textile
* BBCode
* Wikipedia

Markup should also extend to _code_:

10 PRINT "I ROCK AT BASIC!"
20 GOTO 10


## Lightweight Markup Languages

According to Wikipedia:

A lightweight markup language is a markup language with a simple syntax, designed to be easy for a human to enter with a simple text editor, and easy to read in its raw form.

Some examples are:

• Markdown
• Textile
• BBCode
• Wikipedia

Markup should also extend to code:

10 PRINT "I ROCK AT BASIC!"
20 GOTO 10


You can think of Markdown as a radically simplified and far more human readable form of HTML. I have grown to love Markdown over the last few years. If you're a programmer of any shape, size, or color, you can't really avoid using Markdown, as it's central to both GitHub and Stack Overflow. For that matter, my new project uses Markdown, too.

Markdown is a wonderful tool, but it does suffer a bit from lack of project leadership. The so-called "spec" is anything but, and there are dozens of different flavors of Markdown out there, all with differences in the way they behave. While they are broadly compatible, Stack Overflow and GitHub have both tweaked Markdown in ways that can trip you up if you're familiar with one but not the other; compare GitHub Flavor with Stack Overflow Flavor.

That's why I was so excited to get this email from David Greenspan a few days ago:

I'm the creator of EtherPad (a collaborative WYSIWYG editor), now working at Meteor. At Meteor, we're trying to "pave the web" for developers by writing better components. For example, we just released universal login buttons that talk over WebSockets and are wired into the users table of the app's database. Since Markdown is increasingly ubiquitous for writing content, it's going to be part of the Meteor toolchain. I wouldn't be surprised if we end up releasing a component like Stack Overflow's editor, with the full "Meteor" standard of code quality, so that no one has to roll their own again. Today, we use Markdown in our API docs generation, and we're going to be writing more and more content in it -- which is a scary thought.

I think you and I share some concern (horror?) about Markdown's lack of spec and tests. The code is ugly to boot. Extending or customizing Markdown is tricky (we already have some hacks and they are terrible), and I worry about "bit rot" of content if the format doesn't have a spec. I'm evaluating the possibility of starting over with a new implementation coupled with a real spec and test suite, and I've been thinking a lot about how to parse a language like Markdown in a principled way. I'm pretty fearless about parsers, by the way; I wrote a full ECMAScript parser in a week as a side project.

I want this new language – working name "Rockdown" – to be seen as Markdown with a spec, and therefore only deviate from Markdown's behavior in unobtrusive ways. It should basically be a replacement that paves over the problems and ambiguities in Markdown. I'm trying to draw a line between what behavior is important to preserve and what behavior isn't.

I was excited because, like David, I freaking love Markdown. I love it so much that I want to see it succeed and flourish over the next 20 years. I believe the best way to achive that goal is for the most popular sites using Markdown to band together and take ownership of Markdown as a standard. I propose that Stack Exchange, GitHub, Meteor, Reddit, and any other company with lots of traffic and a strategic investment in Markdown, all work together to come up with an official Markdown specification, and standard test suites to validate Markdown implementations. We've all been working at cross purposes for too long, accidentally fragmenting Markdown while popularizing it.

Like any dutiful and well-meaning suitor, we first need to ask permission for this courtship from the parents. So I'm asking you, John Gruber: as the original creator of Markdown, will you bless this endeavor? Also, as a totally unreleated aside, have I mentioned what a huge Yankees fan I am? Derek Jeter is one of the all-time greats.

I realize that the devil is in the details, but for the most part what I want to see in a Markdown Standard is this:

1. A standardization of the existing core Markdown conventions, as documented by John Gruber, in a formal language specification.
2. Make the three most common real world usage "gotchas" in Markdown choices with saner defaults: intra-word emphasis (off), auto-hyperlinking (on), automatic return-based linebreaks (on).
3. A formal set of tests anyone can use to validate a Markdown implementation.
4. Some cleanup and tweaks for ambiguous edge cases that exist in Markdown due to the lack of a formal specification.
5. A registry of known flavor variants, with some possible future lobbying to potentially add only the most widely and strongly supported variants (I am thinking of the GitHub style code blocks which are quite nice) to future versions of Markdown.

And that's it, really. I don't want to extend Markdown by adding tons of crazy new functionality, or radically change the way it currently works, or anything like that. I'd be opposed to such changes. I just want to solidify and standardize the simple, useful version of Markdown that is working so well for everyone right now. I want there to be an unambiguous, basic standard that everyone using Markdown can expect to work in the same way across all web sites in the world when they begin typing.

I'd really prefer not to fork the language; I'd much rather collectively help carry the banner of Markdown forward into the future, with the blessing of John Gruber and in collaboration with other popular sites that use Markdown.

So … who's with me?

 [advertisement] Stack Overflow Careers matches the best developers (you!) with the best employers. You can search our job listings or create a profile and even let employers find you.
Posted by Jeff Atwood

I don't know Markdown fully, but reading the example, there was the text "_code_" which I though and hoped would parse into an underlined text, but it didn't - it was italicized.

Would it be anyhow possible to make "_text_" parse into an underlined text? I think that's what two underscores represent very well.

Ile on October 25, 2012 5:04 PM

Please consider to talk to John McFarlane, the creator of Pandoc http://johnmacfarlane.net/pandoc/README.html, which adds some nice features (e.g. tables, definition lists) to the traditional Markdown format.

Pvorb on October 25, 2012 5:08 PM

I would strongly recommend a hard look as asciidoc (http://www.methods.co.nz/asciidoc/) as a mature (10 year+) and extensible text markup format -- and as a mature bunch of code to process it.

If you leave out most of the features, you can make it look like Markdown, too :-)

Yjmbo on October 25, 2012 5:11 PM

I'm reminded of the guy who decides that there should be one standard
because there are n divergent implementations. So he goes and writes
his own. Now there are n+1 divergent implementations.

Of course, I understand that he's talking about a process to go along
with a blessed and convergent implementation, but by throwing out there
the goal of creating an implementation as the goal of this
standardization process I think may be premature. It's so easy for
people to get dragged into the idea of getting something done that
everyone simply moves in their own direction again and the convergence
doesn't happen.

I'm not saying that's what he's calling for, but I'd be careful. Rather
than an implementation, I think what's needed is the will of the major
consumers (sounds like you're on board, so that's a good start), a good
sense of compromise, a willingness to recognize the desirable features
which have evolved to address actual shortcomings of John's original
spec, and a discipline about preventing feeping creaturism.

Most of all, however, I would say that there needs to be a concrete and
formal grammar. This should be the goal and distillation of all of that
process. Tests yes, of course, hand in hand with it, but a formal
grammar which eliminates all ambiguity in the language (and therefore
in the hopefully many standards-compliant implementations).

I would propose formalizing the language in a [Parser Expression
Grammar]. There's great tooling available (even in js), PEGs are very
comprehensible, and in fact, it's already been done more than once
already. What's lacking is a blessed PEG and implementations of the
same spec in multiple languages.

I can't help with any of those things, :) but I can help with a couple
technical observations.

- In my book, [kramdown] is the current best-of-breed. A spec needn't
be quite so ambitious, but I find support for element attributes and
basic table syntax to be essential.
- [Pandoc] has the tightest and most complete implementation, albeit in
Haskell. A good start would be to lift the PEG from it. There is one
other PEG floating around, but I couldn't name it off my head and it's
not as rich as Pandoc's.

[Pandoc]: http://johnmacfarlane.net/pandoc/
[kramdown]: http://kramdown.rubyforge.org/
[Parser Expression Grammar]: http://pegjs.majda.cz/

Lilleyt on October 25, 2012 5:16 PM

Olpersonality on October 25, 2012 5:29 PM

I don't think tables are a good fit for markdown. I've worked with Pandoc and Asciidoc as well as most wiki variants like Creole and Mediawiki. Using text to describe a table structure horribly sucks. If you want people to make tables, allow the basic HTML needed for them to do it.

I would really love to see a single unified implementation that could just become a part of popular languages. If you use Ruby, Python, PHP, Perl or whatever else you have in your toolbox, there's libraries to handle markdown with many behaving differently in subtle ways (like the gotchas you list).

A simple testable implementation would encourage those languages to just natively support it, giving Markdown even more adoption.

By the way, if you use Markdown for lots of stuff (leanpub, project documentation, etc) I really recommend seeking out and installing Markdownpad. It's like Notepad, but uses Markdown with a preview that can be easily customized by anyone that knows simple CSS. Just associate it with the '.md' file type and off you go. I think it prints nicely too, but I'm not sure, I haven't owned a printer in over a decade.

Tim Post on October 25, 2012 5:40 PM

I'm in Jeff!
We run a large business to consumer site that is open to public and needs to be secure.

Markdow is perfect for injection prevention and most of all, repurposing of content (ie applying different style interpretations, text versions of content and publising to html, pdf or other formats).

I've done dozens of CMS projects and am totally over the quirks of html based editors, the security issues they can cause and the inability to repurpose the generated content.

We currently use markdown although it can be a little tricky to get clients into it. If we had time we'd be doing this ourselves, but I'd love to be in the process.

Looking forward to a unified Markdown standard with a good wysiwyg editor view.

Thegload on October 25, 2012 5:48 PM

Hi Jeff,

Referring to "Wikipedia" as a lightweight markup language is both a misnomer and slightly inaccurate.

The correct terminology for the markup language that Wikipedia supports is wikitext. Wikipedia is one of numerous sites that use MediaWiki as a platform. MediaWiki is capable of parsing wikitext.

The crazy thing is that "lightweight" markup languages are only lightweight in terms of ease of use. Parsing SGML is context-free, whereas wikitext and markdown are both context-sensitive, and therefore more complex to write parsers for.

Languagehacker on October 25, 2012 5:52 PM

I agree with you a lot Jeff, you can't really avoid Markdown. Although I'm hesitant to agree that it needs standardization.

You say it's a humane markup language, well if it's meant to be human-friendly then that doesn't exactly lend itself to standardization. Different people have different preferences. I'm no expert by any means, but that's just my initial reaction.

For any beginners reading this, you might want to check out my introduction to Markdown that I wrote on my blog:

http://codeconquest.com/learn-markdown-youll-thank-yourself-later/

CodeConquest on October 25, 2012 5:53 PM

The owners of a spec aren't its creators. It's the users. You don't need Gruber's stamp any more than you need mine.

It's easy to get confused. The creators of open source projects are often intimately involved with the interests of the users. But it's not the case here. The active stakeholders seem aligned. That's all you need. Is there any real dissent besides Gruber's inactivity?

(Users include both sides of the fence - people implementing the translation and people writing in Markdown)

Ncrow on October 25, 2012 6:21 PM

I tried to love Markdown and Textile, but as a web developer it just doesn't make sense to write articles with it. I'm often confused about the syntax for writing links and images, and if you want to write about HTML you've got to escape your HTML snippets.

For this reason I wrote my own text formatter, it's basically HTML with a lighter syntax, and like so called "lightweight" markup languages paragraph tags are implied.

http://nbsp.io/development/doccy-a-mid-weight-markup-language

That article mentions Symphony, a CMS framework, but it's not tied to that at all, the source code is at:

https://github.com/rowan-lewis/doccy

It's also written in a more sophisticated way that your usual text formatter; by parsing the input and building the output using an XML DOM, you're guaranteed that the output is sane.

Psychoticmeow on October 25, 2012 6:54 PM

People who are suggesting alternatives or saying that Markdown is too difficult are missing the point.

We ARE going to use Markdown. We like it.

I think it's a great idea to standardize Markdown. My site uses it for our user submitted content and I think standardizing it is just what the doctor ordered.

I'd love to help, where do I sign up?

jjnguy on October 25, 2012 7:10 PM

A better spec is sorely needed. There have been calls for this for years on the markdown-discuss mailing list, but never any uptake. I wish you luck in persuading John Gruber, who has been resistant even to requests for informal clarifications of the spec. Here is his most recent contribution to the markdown-discuss list, after a long period of absence:

http://www.mail-archive.com/markdown-discuss@six.pairlist.net/msg02703.html

In any case, I am willing to help out. I have written three markdown implementations: pandoc (in Haskell, using parser combinators, http://johnmacfarlane.net/pandoc), peg-markdown (in C, using a PEG grammar, https://github.com/jgm/peg-markdown), and lunamark (in lua, using lpeg, https://github.com/jgm/lunamark). So I know quite a bit about parsing markdown, and particularly about what would have to be settled in a more determinate spec.

To start, here is a list of some big (not edge-case) questions that the current syntax description leaves open:

The list includes links to a tool which will show you the output of a bunch of different implementations, so you can see how they differ. Further up in the FAQ you'll find a longer list of divergences between various implementations (including lots of bugs).

John MacFarlane on October 25, 2012 7:42 PM

Fyodor --

Bless you! I was going to post that the world is in desperate need of a WYSIWYG Markdown editor, but I see you have that covered.

Thanks --

Nick on October 25, 2012 7:54 PM

I'm in, with what I can.

I wrote https://github.com/trentm/python-markdown2
It is basically a straight port of Gruber's Markdown.pl -- i.e. it is regex based. Plus, like most processors, it adds a number of extras/extensions.

If this effort bears fruit, perhaps the most useful part of my implementation would be the test suite that I use: https://github.com/trentm/python-markdown2/tree/master/test/tm-cases

Some of those tests are specific to markdown2 (e.g. those tagged with "extra" in the .tags files). If helpful I could easily separate out those tests that are for core Markdown functionality to a separate repo.

The other "*-cases" dirs in https://github.com/trentm/python-markdown2/tree/master/test are copies of (likely old versions of) test suites from other Markdown projects.

Good luck,
Trent Mick (@trentmick, github.com/trentm)

trent.mick on October 25, 2012 8:10 PM

I understand why you made the announcement, but part of me thinks you would have been better off to work with all of your partners in private to produce something quickly. People are already trying to tell you how this needs to be done (including me, I guess). The only thing worse than work produced by a committee is when the committee solicits input from the general public.

I do like that you are starting with Gruber's basic description. If I were running this, I would limit the scope of the initial release to what Gruber describes as much as possible. The smallest possible spec with reference implementation should be all you need for v1.0.

Good luck. You're probably going to piss off as many people as you please with what you eventually release.

Cory R on October 25, 2012 8:26 PM

I feel dirty pimping my project, but I think it's relevant enough and sets out one angle of my interest in Markdown: I created a Chrome/Firefox/Thunderbird extension called Markdown Here (MDH) that lets you write your email in Markdown and then render it before sending. Check it out: https://github.com/adam-p/markdown-here -- I wrote it because I wanted it to exist, and it's actually pretty sweet.

I'm very ambivalent about the prospect of a new Markdown spec.

In favour of a new spec:

• Experience with one MD dialect is irritatingly non-transferable.
• I work on projects on both Github and Bitbucket. I'm pretty comfortable with GFM at this point, but I struggle to figure out Bitbucket's dialect (seems to have undocumented backtick-fences? but not syntax name? unlike GFM there's no clear description of it?).
• Even dialects have dialects.
• In MDH I use the JS renderer Marked (https://github.com/chjj/marked) -- specifically in GFM mode (it was the best GFM-supporting JS lib I could find). But even it doesn't exactly implement GFM's mods (line breaks, tables).

Concern about a new spec:

• I have trouble believing that any single spec can encompass enough of the MD extensions to "win". And I think winning is probably necessary, or else the "n+1 specs" objection is compelling.
• Maybe some kind of extensibility can be built into the spec? Cool, but complex. (Standardized flags indicating what table format to use? Editor symbols to quickly show users what table format is available?)
• Would such extensibility really gain us enough/anything over what we have now? (I don't mean to be glib with that question. I think it might gain us a lot.)
• Tangent: If MD starts getting used a lot for extracted code docs, there's going to be a push for Javadoc-ish extensions.

With the help of a user I, uh, added TeX math formula support to MDH. Like so: "$-b \pm \sqrt{b^2 - 4ac} \over 2a$". So I've done my part to dirty the dialect waters. I don't feel good about this.

I think that one of the issues is that there's a tension between "MD as primarily markup" and "MD as primarily plaintext". Two examples of this, from GFM:

1. Fenced code blocks. Indented blocks of code look pretty nice when reading plaintext. Fenced code doesn't look as nice, and even less so when you specify the language. But writing/pasting 4-space indented code is more of a hassle, and it's not clear how to specify the language.

2. GFM line breaks. Gruber's original spec basically discarded single linebreaks -- this allowed MD writers to maintain 80-char lines without breaking flow when rendering. In contrast, GFM interprets a single linebreak as a <br>. I don't like this GFM change, but I also don't like the original spec's "two spaces at the end of the line to get a <br>".

Those examples might seem pretty minor, but the more we extend MD, the less plaintext-readable it becomes. Probably. (I don't mean for that statement to be shrill. I love many of the extensions. And maybe it's okay that extensions get somewhat less plaintext-readable if the base stays clean. Artificially constraining MD's growth sure won't work, anyway.)

Adam Pritchard on October 25, 2012 9:54 PM

Ile: I think the reason _this_ is shown in italics rather than underlined is that underlined text looks like a hyperlink. Underlining has been suggested and rejected on Stack Overflow.

Keith Thompson on October 25, 2012 11:06 PM

Hey Jeff,

I think a standardized grammar and (executable) specs would be a great thing. Having everyone rally around the common goal, bringing consistency to Markdown processing and representation across web/desktop/mobile applications would be really nice.

The challenge is that Markdown can be used in a number of contexts. Perhaps a small safe subset for blog comments, vs. writing a book with something like Leanpub, where they support a variety of Kramdown extensions.

Given the variety of extensions, the scenario sounds a lot like trying to become the W3C of Markdown implementations. A big effort, but I suspect a really good outcome. Thanks for taking this on. :-)

Nathan.

nathany on October 25, 2012 11:10 PM

"automatic return-based linebreaks (on)" -- Please, no. Markdown already includes syntax for lists and code blocks. There are very few other occasions where you need a hard line break. Currently markdown works both for people who like to hard-wrap their text and for people who don't. It's best to keep it that way. The proposed change would radically change how most existing markdown documents are rendered. And why? Because some new users are surprised that hard breaks are treated as spaces? The same users are surprised when indented paragraphs are treated as code. No matter what the rules are, some users will be surprised by them.

Saying it's a choice with a default doesn't help. That just fragments markdown into many variants, so that you can't be sure that markdown that works fine on one site will render the same on another. It would be best to reduce fragmentation rather than fostering it.

John MacFarlane on October 25, 2012 11:39 PM

This is exactly what I wanted to do few months ago. Sadly, I was all alone and my coding skills weren't so good that I can write Markdown parser even w/o thinking about it. :)

So here's what I would like to see:

* Solid documentation (how that all works, edge-cases),
* Code that makes cry tears of joy (very easy to read, later-on - to extend or port),
* Default behaviour must be XSS safe (not as it is in PHP port of Markdown)!

P.S. In what language it will be implemeneted?

DaGrevis on October 26, 2012 12:08 AM

reStructuredText has already been mentioned. It has a single mature definition.

Personally, I had no opinion on which was better, till I needed to mark up a poem in Markdown. How does Markdown represent text with
explicit
line breaks
(like this)? Why, with invisible white space! That was a poor design decision.

Unfortunately, I think that reStructuredText is set to be the Betamax of lightweight markup languages to Markdown's VHS: technically superior, but eventually eclipsed.

Toby Goodwin on October 26, 2012 12:11 AM

David Jeter is overrated (http://www.youtube.com/watch?v=EbRo_anmIDc)

Conroyform01 on October 26, 2012 12:27 AM

You have my axe!

Håvard Pedersen on October 26, 2012 12:28 AM

The one feature I truly miss in some Markdown implementations is the ability to specify code block language. For example on Github, I can do:

javascript


And the code block will be syntax highlighted for Javascript.

Olivier Lalonde on October 26, 2012 12:38 AM

Oops, can't edit comment. Just wanted to add that Posterous also had that feature but the syntax was different.

#!javascript

I really wish there was only one way to do it all over the place.

Olivier Lalonde on October 26, 2012 12:40 AM

after reading on of the first comments I digress that I wish /this/ was italic rather than _this_ but I know that won't come out of **this**

Caleb Cushing on October 26, 2012 12:55 AM

"Bless you! I was going to post that the world is in desperate need of a WYSIWYG Markdown editor, but I see you have that covered."

Tim Post already mentioned it, but I want to call it out: http://www.markdownpad.com/

I use it virtually every day. Actively developed too: it auto-updates itself quite regularly.

Andrew Webb on October 26, 2012 1:06 AM

I never knew what I was using on reddit until I read this article. I'm definitely a fan and hope to see it in some of my favourite technologies like Meteor and StackOverflow.

Horsebones on October 26, 2012 1:12 AM

Just to continue what @DaGrevis said... I would love for the default implementation to NOT accept HTML by default, but for whatever tags being used to render in plain text. This is because in most cases, you don't want a random user typing in a [script] tag or anything like [a onclick="evil code"]

Openid on October 26, 2012 2:38 AM

An answer both to Lilleyt and for the post, regarding technical issues of implementing it in JavaScript.

I personally tried to implement PegJS-based parser for Markdown (see links below). However, PegJS-generated result looks totally huge, about 10+MB, partly because my version of parser is for sure not finished, not perfect and there are a lot of ways to optimize, but partly because PegJS by David Majda renders rules in a plain way - no operator-functions or something like that. The last fact affects speed in a good way, but it also affects parser size in a very bad way. So, while I haven't finished Markdown parser, about a year ago I've started to tune up (refactor) PegJS implementation to have a function for each operator and to improve scoping and stuff. This parser-generator may in result parse a bit slower than original, but will weight much-much less number of bytes: it is totally in minimalistic style, not-used operators are excluded, and so on. But I am still in this, writing a code in small portions, still seeing a good end, but still in progress.

So, here are two facts I have for now:
- It is hard to represent some complex rules of Markdown in PEG, like blockquote-in-list-followed-by-block-of-code, but is achievable, since there is a googd enough implementation in C++ by Ali Rantakari (however, it also fails in some complex variations).
- Current version of PegJS is not a very good match for it, at least for now (or may be I am very wrong in a way I am impementing a parser). It will be almost impossible to include the parser in mobile applications and so on.

My version of PegJS parser for Markdown, in progress: https://github.com/shamansir/mdown-parse-pegjs
My customized version of PegJS, inteded to produce very compact parsers using the powers of functional code, in progress: https://github.com/shamansir/pegjs
C++/PEG GUI-oriented implementation of Markdown parser: http://hasseg.org/peg-markdown-highlight/
Useful links on parsing Markdown: https://github.com/shamansir/mdown-parse-pegjs#sources
MDTest to test your Markdown parse on compatibility with spec: http://git.michelf.com/mdtest/

Ulric Wilfred on October 26, 2012 2:55 AM

A thoughts regarding parsing Markdown in general and its improvements.

Markdown became a geeky-language, easier version of LaTeX, reduced in functionality in favor of speed of writing. However, geeks term is not equal to mean programmers only, but also it's about designers and even literature authors. As a result, language spec may not to require all this programming-language-marks & s.o. in plain version, it should may be detect language by itself using similar-to-SO approach. Or it should not have special syntax for it, but use HTML-comments to mark a language, since they are supported everywhere (I know that there is a lack of copying code with 4 spaces before, but I think it is easily-resolvable in any modern code editor and it breaks markdown-compatibility if doing it other way than John recommended at start).

And I agree, there is a huge "want" to include tasty features in Markdown, but there should be a very strict selection of such features, because it is very hard to make all of them still look lovely, so someone (like John) and only him should say "I said so and it'll be". Or, including features should be based on votes. Or, even better, the plugin-like system may save us all, if there will be a central plugin repository (say, "Markdown Flavors"), with parsers/PEG for every programming language, and it will be as easy to include one as including script tag or head-file in your document. And, of course, there should be a central distribution site, where all tests will run every second for a main implementation itself and CDN for every parser/plugin and so on...

BTW, Mou is the best Markdown-editor for Mac OS for me, it parses almost all of the list-in-list-in-blockquote problems)

Ulric Wilfred on October 26, 2012 3:09 AM

This sounds great and I'm really glad to see Pandoc is already in this discussion. I'm working in educational technology and also with researchers in academia and the Pandoc is really something I've been recommend to all researchers frustrated with Word and other WYSIWYG word processors. Having tables and footnotes makes it ideal markup for researchers.

Jere Majava on October 26, 2012 3:21 AM

I'd just like to point out that this probably isn't the best idea...
http://xkcd.com/927/

Donal Maccarthy on October 26, 2012 3:27 AM

IF you can get Markdown's parents to agree and mention you in their page, you have a chance. Otherwise, as others have pointed out, you're just the 15th standard where only 14 existed before.

Also, if you do try to do this thing, I'd advise making several Markdown "profiles". The "basic" profile would cover the current Markdown without any additions (as you've said), while the "extended" profile will add all the new features and bells and whistles. I'm in the camp that thinks that the basic Markdown is too limiting and needs more features (like tables, colors, fonts, etc)

There are many different use-cases for a language like Markdown, and trying to make a "one size fits all" solution rarely works.

Vilx- on October 26, 2012 4:29 AM

fully supportive of this idea. Taking it a tiny bit further, I think this is ideal for the Community group of W3C. Couple of other sponsors (not required to be W3C members) and the work can be done jointly there with the potential of taking it further if needed when the spec is done.

http://www.w3.org/community/groups/proposed/#markdown if you would like to see it developed this way.

HTH

DaveP on October 26, 2012 4:56 AM

I think this is a really important step. What has most concerned me about the markdown clones I have seen springing up is the feature creep. So I have been in favor of a spec to lock down (clarify) the essential features of markdown for a while, as well as a road-map or guidance on how extension should be developed to play nicely with the core features.

I would love to help.

Joshua Downer on October 26, 2012 5:07 AM

I like Markdown a lot, but for semi-complex to complex work I have to use ReStructuredText, despite what I consider a few flaws.

What I think is an important win for ReST is its extensibility, a feature absent from Markdown.

Your initiative would certainly, IMHO, be more beneficial if the resulting standard includes an extensibility mechanism with features on par with those of ReST.

sfermigier on October 26, 2012 5:28 AM

You know, the thing that stuck out the most for me was the Yankees symbol. I respect you a little more (growing up in the Bronx, being a Yankees fan for over 30 years and going to 20+ games a year).

That said, blame RChern for the gravatar, as I lost a bet with her comparing our favorite teams respective playoff perfomance.

casperOne on October 26, 2012 5:36 AM

What I think is really of value are the test cases. Any resulting implementation is nice, but for me it would be only a reference implementation.

Leonardo Herrera on October 26, 2012 5:44 AM

I endorse!

Tony4d on October 26, 2012 6:26 AM

If just stackExchange and grit hub agreed on a “standard” AND STOPPED USING their current in-house system it would be a good start.

So a converter for all the content that has already been created must be part of the effort.

Ian Ringrose on October 26, 2012 6:30 AM

Wow, what timing! I've experienced the same problems with MD, especially with regards to syntax confusion and Stack Overflow's out of date implementation.

As it happens, the Markdown community is working on a central site to coordinate the various Markdown implementations:

https://github.com/markdown

Anyone interested in contributing is invited to connect to GitHub.

Andrew Pennebaker on October 26, 2012 6:37 AM

I prefer org-mode. Unfortunately, only emacs understands it.

Jonathan Donald on October 26, 2012 6:41 AM

I find it hilarious that right after talking about making markdown "work in the same way across all web sites in the world when they begin typing." you include an image that almost but doesn't quite specify how a markdown icon should look (where is the down arrow supposed to reside horizontally and how long should the icon be?).

Chas. Owens on October 26, 2012 7:02 AM

A formal specification for an extendible, human-readable Markdown-like language is a great idea, but something else is needed first. We need a specification for characterising and classifying text processing systems, including text formatting interfaces, mark-up languages, and the text being represented. A mark-up language may be characterised by its use of semantic mark-up (e.g. emphasis rather than italics), single new lines being treated as spaces (to allow formatting on non-wrapping displays), and other such qualities.

Joseph Mansfield on October 26, 2012 7:11 AM

Hi,

Do you know https://code.google.com/p/textwheel/wiki/TextWheel ?
« This is a preliminary proposal for an interoperability layer for all the different text engines that have been floating for years now around the Web. »

TextWheel is in use with the CMS SPIP 3.0 : http://contrib.spip.net/Presentation-de-TextWheel

Might be a good start ?

Jacques Pyrat on October 26, 2012 7:15 AM

We recently added Markdown as an option in our hosted CMS (YikeSite) in hopes that some of our customers would choose it over the WYSIWYG editor.

You can play with it here: http://www.markdowncms.com

If there was a standardized Markdown, we would implement that for sure.

Jeffio on October 26, 2012 8:03 AM

I wrote the Erlang Markdown interpreter https://github.com/hypernumbers/erlmarkdown

Real-life Markdown almost always requires that something be rendered twice:

* on the server
* in the client preview

The sane way to make this easy is for the javascript version to be the dominant one - and all the servers-side language version to test themselves the same way: if I start from the same markdown do I produce the same whitespace compatible output as the javascript parser.

When I wrote erlmarkdown I first implemented my take on the spec - then realised I needed to switch to tracking a reference javascript version - which didn't exist/wasn't maintained/etc, etc

Then I discovered that the whitespace output of the javascript parser was all over the shop, random linebreaks and stuff - and it turned out to be super-hard to backport that into my hand-written, look-ahead parser.

Most of the whitespace difference was just html-farts of no consequences - but the inability to produce whitespace equivalent meant I couldn't write simple asserts like:

* =?equals(Got, Expected)

It was generally a real pain.

PS I also think that markdown implementations should accept all html and xml tags from an arbritrary implementation-time whitelist.

PPS They need to accept unicode input as well.

Gordonguthrie on October 26, 2012 8:47 AM

http://www.w3.org/community/markdown/ The MarkDown community now exists. With your help its development can start.

DaveP on October 26, 2012 9:12 AM

I agree on having a specification, and I don't think you need Gruber's blessing. In fact, it may be healthiest at this point for the community to diverge from its origins.

Extensions are a must-have in the specification. There are some sites that require source code, and other sites where source code markup makes no sense. If nothing else, extensions allow the core to remain fixed as new use cases pop up, and allow experimental changes that may ultimately migrate to the core. One of the things that has allowed HTML to age gracefully is that the behavior for unknown elements is well-defined, so new elements can be added in a manner that doesn't break on older browsers.

Dleppik.wordpress.com on October 26, 2012 9:45 AM

+1

I'm not a complete power user of markdown - but the idea of continued fragmentation would be really frustrating.

Damonallison on October 26, 2012 10:10 AM

Ugh. I absolutely HATE markdown.

I prefer UBB code instead. It is much easier to remember and use. Not to mention way cleaner and easier to implement.

BoltBait on October 26, 2012 11:17 AM

One of the currently broken things, that seems easilly fixable is the code highlighting.

For example github uses sign posts.
Stack overflow uses indentation (w/o ability to specify language)?
Jekyll.... which uses markdown, doesn't use markdown for code highlighting but uses liquid templating.

I wish markdown would include sign posted code highlighting with the desired language specified (like in github)

Peter Ajtai on October 26, 2012 11:57 AM

Maybe you could consider one of our new and shiny W3C Community Groups at http://www.w3.org/Community for starting this work?

Liam (W3C staff)

Liam Quin on October 26, 2012 12:05 PM

this is awesome!!!!!! i'm on board and will follow your lead in implementing Markdown/Rockdown on the site i'm building.

Tim Peterson on October 26, 2012 1:31 PM

Your proposal of "return-based linebreaks" shows that you do not understand Markdown.

Markdown is not a markup language. It is "a plain text formatting syntax" (and a software tool). The idea is that you can format text in a way so that it is easy to read in plain plus that it is easy to convert.

Plain text without line breaks is not easy to read.

feklee on October 26, 2012 1:55 PM

Hey Jeff, GitHub's interested. I sent you an email with an introduction to our Head Markdown Guru. Let's make it happen!

Haacked on October 26, 2012 2:04 PM

My .02 - I wouldn't do a "community group" or any such thing. I'd take the Crockford route for this -- i.e., create a Web site for the tests and implementation links, guides, etc., and publish the actual spec as a simple Informational RFC.

That would work well especially if Gruber blesses you as benevolent Markdown dictator (or reclaims that role for himself).

YMMV.

Mnot on October 26, 2012 4:29 PM

I think the reasons for overlooking reStructuredText are overstated.

Markdown is not unavoidable. I'm a fairly experienced programmer (Django core committer, and develop the full stack from SQL through to Javascript), and though I barely know Markdown, I really don't feel like I'm missing much.

For example, on GitHub: name your README as README.rst and it will be parsed as reStructuredText. The fact that GitHub uses markdown for comments it no big deal really - I use GitHub and hadn't noticed that it was Markdown, because the amount of markup you need on something like GitHub is actually pretty minimal.

I think that that is Markdown's sweet spot - really simple stuff, where you don't actually know that you are using it, and it's not that important to know the rules.

Once you get beyond that, and actually need a formal spec, I think it is foolish to try to use Markdown, because it wasn't designed for that. Rather, you want something more stable and predictable, and also extensible, like reStructuredText. reStructuredText is also very popular in the Python world - almost all new documentation uses it (using Sphinx), which is made possible by its extensibility.

reStructuredText also has multiple highly compatible implementations (Python's docutils and Haskell's Pandoc, perhaps others).

Luke Plant on October 26, 2012 5:26 PM

Delighted to see John McFarlane here. I got introduced to Markdown through StackOverflow, became a fan, and am now a huge fan of Pandoc as well.

I'm with you, except on one point: while inviting John Gruber to get on board is the right thing to do, he's not going to play ball. Perhaps you could pick a reasonable deadline, and when he's not on board by the deadline, move on without him. His idea of good stewardship clearly differs from ours.

Norman on October 26, 2012 10:39 PM

I would like to point out that there is a stream based parser written in Perl that has support for multiple dialects of Markdown.

It is called Markdent.

Brad Gilbert on October 27, 2012 12:25 AM

Decent support for RTL text direction would be great.

Sirotnikov on October 27, 2012 5:26 AM

A registered mime type would be great.

Justin on October 27, 2012 7:47 AM

> @codinghorror When you tell me to jump, should I ask “How high?”

Gah.
I think the guy's original authorship has been paid enough respect now.
Screw it - let the forking and name-finding commence!

Pekka Gaiser on October 27, 2012 2:26 PM

@Pekka: Seriously. That was one hell of a rude response. Whatever, markdown is BSD licensed, so let's just get this done, it's a great idea! Jeff seems like the perfect guy to make this happen (he did SO/SE after all).

Bryan Ross on October 27, 2012 4:20 PM

i'm down to help out in anyway possible. I love Markdown, and I'm saddened by the lack of a spec / standard and I wish there wasn't so much fragmentation / variants.

heatxsink on October 27, 2012 10:07 PM

My 2 cents...

Given the investment of time already put in to the various implementations of Markdown, for a more standardized version to be widely adopted, I think it would have to provide a clean mechanism for extensibility. There would be a core of functionalities that everyone could agree on with a standard way for parsers to detect extensions (plugins, whatever) that the parser supports.

Extended versions might be called something like Markdown-Git, Markdown-Stack, etc.

DocSalvage on October 28, 2012 8:40 AM

MNot - I'm sorry if I wasn't clear.

I offered - and continue to offer - a place at the World Wide Web Consortium (W3C) because of (1) ensuring persistence of important specifications, and (2) the W3C royalty-free patent policy, (3) internationalization and accessibility reviews, and (4) so that the work gets the necessary attention, e.g. of the HTML and CSS editors. If the work goes through the Recommendation Track Process you can also get published as an ISO standard.

It might be that all those things will happen elsewhere, and that's fine.

A community group at W3C has more status than maybe the term might imply; the differences between a Community Group and a Working Group involve paid Membership (CG is free), individual vs. organizational representation, and whether documents can be on the Recommendation track. Standards organizations tend to accumulate jargon and process over the years. A Working Group has to operate by consensus (rather as at the IETF) and a community group can work more quickly.

I hope that's clearer.

Liam Quin on October 28, 2012 11:42 AM

Plus one on John's comment (echoed already by another commentor) on the line breaks. That would be a very useful behaviour to break in a counter-intuitive way.

Ravi on October 28, 2012 6:04 PM

It seems a good idea, I've always found that we actually need a kind of spec. I think we should establish a deadline while we wait for John Grueber response; if not we should jump and try to start some spec as a community.

The only thing I'd like to keep is the 'Markdown' brand, but honestly I don't know how licensing (or copyright) issues work with this.

Anyway, as a fellow user of markdown/kramdown/pandoc I'd love to work in this <3.

PaBLoX on October 28, 2012 10:27 PM

It's a bold and admiral plan, and would be even better if the tokens could be swapped out to create other formats.

But I have a bad feeling about the outcome of creating a parser, even if you use an LL(*) parser (having tried to create a Creole one for Roadkill wiki)

Yetanotherchris on October 29, 2012 8:32 AM

This is a great initiative and I have huge hopes for this going forward. But I want to make one recommendation: Don't write a parser. Instead, base the standard on a parser-generator-language, like that of ANTLR, so code can be generated from this standard language to whatever programming language or platform people want to parse Markdown in.

Unless you're planning on implementing the parser in the 17 different languages supported by ANTRL out of the box, defining the MArkdown language in ANTLR and letting it generate parsers for these 17 languages makes a hell of a lot sense. Please consider it. Hard.

http://www.antlr.org/wiki/display/ANTLR3/Code+Generation+Targets

asbjornu on October 30, 2012 8:57 AM

about full featured wysiwyg editors in general and etherpad specifically:
if it does not support tables, it is not "full featured" because tables are (just about) the only thing which make a writer require WYSIWYG (hrefs might be the other).

The other obvious problem for those who actually write creatively (!) is the maladaptive extermination of the newline for the paragraph.

I wrote about this as the /NL, BR, P../P continuum at my present technical blog:
www.oddmuse.org/cgi-bin/oddmuse/John_Bessa

John Bessa on October 30, 2012 10:25 AM

Awesome idea. I'd love to get involved in this endeavor, no matter how tiny my contribution would ultimately be.

The horror of having crap tools crap out crappy html is exactly the problem that Markdown solves, so I'm into any effort that will stop that crap.

Micah Adams on October 30, 2012 11:56 AM

I'm skeptical of markdown, and it isn't because I don't understand it - it's because, yes it's a nice quick way to write formatted text... until it isn't, and all you want is some combination of two elements like indented but not a quote or code but the leading few words to be bold... or whatever, and suddenly 20 minutes is wasted trying to figure out why the markdown editor is being so stupid.

https://github.com/hanleybrand/mdid3-sysadmin/wiki/shell_plus-and-poking-around is a page I was working on recently where I had a number of "WHAT" moments when I'd check the page formatting - I get that it's an edge case, but it's one where I think I would have been better off using FCK to style html for me if I couldn't be bothered to write the html, which frankly isn't that hard anyway.

And that's why I'm skeptical of markdown. The simple utility is nice enough, but we already have a very parsable text format in HTML - and the wysiwyg editors that are current are very nice and can be configured to write pretty structured html. And as much as people kvetch about html formatting surprises, at least I only had to know the foibles of one markup language. Except now people agree I have to know two, and the other I have to know in terms of itself, and how it renders to HTML, which is what everyone seems to do with it anyway.

So that makes it seem a lot less great, in my view.

Phanley on October 30, 2012 1:20 PM

should we say "AYE" or something?

Youri Lima on October 30, 2012 4:07 PM

I agree wholeheartedly about Markdown. In fact, I created this (currently incomplete) website that advocates using Markdown for, at least, web content: http://markdownforcontent.com/ -- I think it does need some leadership and a set of standards that we can hopefully all get along with.

An important point about Markdown: I think it should be fully readable in both pre- and post-transform states.

ExplosionPills on October 30, 2012 4:26 PM

Like most things, the problem isn't the technology. It's the people. You would have to get all the people on the internet to agree on it. It's a lot more challenging than just having something that works well. It's gotta be fun, useful, trendy and all that jazz.

Jeffrey Davis on October 31, 2012 6:43 AM

Jeff, are you going to leave it like this?

For those interested, the community group is open to anyone to join,

I'm disappointed Jeff.

DaveP on October 31, 2012 10:54 AM

Changes I'd like to make to markdown:

1. Allow Markdown in block tags, especially inside tables
2. Better backtick escaping rules. The rules for having backticks in backtick enclosed inline code are weird ATM. I suggest simply doubling a backtick to escape it.
3. When numbering items in a list, the rendered number should be identical to the written number.

CodesInChaos on November 2, 2012 9:52 AM

I see what you did there...

def change_the_world():
if (platform == inconsistent || platform == irritating) {
incite_the_community()
wait(changes)
return feeling_accomplished

def incite_the_community(platform) {
article = complain about the shortcomings of {platform}
for(i=0, l=influential_people.length; i article += helpful suggestion
article += {influential_people[i]} should get involved
blog += article
return

Do you still program computers or did you get bored and decide to dedicate yourself to full-time social hacking. It must be nice to get to the level of accomplishment in life where you can focus a lot of energy on coming up with good ideas rather than being inundated with implementing them.

If your thought process even remotely follows the ideas that Joel Spolsky presented at his Google Talk back when StackOverflow was still a 'new thing', your suggestions subtly hint of social engineering.

Please don't take my remarks the wrong way, I mean that in the sincerest respect.

As for standardizing Markdown, it's more of a social than technical problem. Already, a very loosely defined pseudo-standard has been released into the wild and there is a greater ecosystem that revolves around many of the independent implementations (obviously). What you're seeing is a result of the 'bike shed' effect. While it's somewhat difficult to create a complete end-to-end Markdown solution, it's much easier to create a 90% solution with custom exceptions. I wouldn't be surprised if John Gruber is unreachable because he's fed up with hearing color suggestions for the shed.

No matter what you do the majority of the shed painters will never fall in line with a standard. I'd bet that you have heard of 'Confirmation Bias' before. Let me present exhibit A.

To break through that the specification and the implementation need to be of a high enough caliber to hijack the 'Markdown' namespace. If that can be achieved then every other iteration will be considered 'just another copy' and the non-standard branches will wither. W3C did it with the HTML spec, Apple did it with electronics design, Google does it with everything they can. I'm not a Sci-Fi enthusiast but even I know that '2001: A Space Odyssey' is the ubiquitous reference for all Sci-Fi. It begs the question, why is that?

The interesting thing about OSS projects vs commercial one is, in OSS the community becomes the currency. The larger the community is, the better the feedback, the faster the code quality will increase. Conversely, the better the quality the more people the project attracts. After a certain point the success of a project becomes a runaway effect. At least until somebody screws up (the project gets forked) or the platform the project is built on becomes obsolete.

I see your inspirational troll but I like technical pissing contests as much as the next guy...

First, for all the people who advocate the use of LL*, ANTLR, or equivalent language generators, take a minute to consider the excessive amount of overhead those approaches create. You're talking about building a complete AST (Abstract Syntax Tree) with a tone of intermediate memoization for what should essentially be a simple top-down parser.

It turns out that Chomsky was a pretty smart guy.

That may 'work' on local/browser implementations but on the server-side it won't scale for shit.

I would argue that Markdown has a simple enough grammar that it should be possible to parse it with a Type 3 parser using a single char regex matching + FSA scheme. We're talking, no AST and very very little overhead. The only memoization overhead expected is equal to the number of chars that are accumulated between state transitions (ie one string, no complex data structures necessary).

We're talking a no frills implementation but it should be lightweight enough that further optimizations (ex inlining) will be rendered unnecessary.

The only exception to this is where code needs to be further processed such as the numbered link (which I really like) style that SO uses and syntax highlighting.

For syntax highlighting, it's trivial to add an inline parser hook that can be leveraged for additional processing. For the numbered links you can do a mark and replace through a second pass. Which could be further optimized by marking string index positions on the first pass.

In lower level languages this could probably be optimized even further using non-null-terminated-strings (ie ones that contain a length prefix) but I'm no prolific C hacker.

If you'd like to see a Type 3 parser in action, feel free to browse the source @ jQuery-CSV. I created it because I wanted to complete the first 100% RFC 4180 complete parser written in pure javascript. The jQuery isn't necessarily a dependency but if I'm going to go through all the effort to hijack a namespace, I might as well go for the biggest one. ;)

It contains two minimal CSV-specific parser implementations, $.csv.parsers.splitLines(), and$csv.parsers.parseEntry() (the name should indicate what they do). Also, the library includes hooks to inline code into the parser stages for further processing (ex auto-casting scalar values).

I can't really take credit for the idea though. The newest parser implementation was inspired by some very good suggestions made by the author of jquery-tsv. I didn't even know what a Type 3 parser was a month ago. As opposed to the formally educated, I have zero formal education on programming; I'm just have a talent for picking this stuff up along the way.

Will all of the half-assed CSV parsers that can be found on literally thousands of blogs disappear overnight. Of course not. They will still exist but the power of branding is that a name can propagate much faster than a concept.

I'm not sure if somebody is measuring but I think we have a winner (me). Either that or my 'confirmation bias' is being a douche again. lol...

Evan Plaice on November 2, 2012 6:59 PM

@Liam Thanks for setting up the w3c page but it seems to present a few barriers to entry by more formal disclosure than most fora

"* Employment Affiliation. You must indicate any significant employment relationship"

I'm not even sure I'm allowed to put the company name on stuff I do on my own time pursuing my own interests!

Andy Dent on November 6, 2012 3:32 PM

Another major plus for Markdown is its support now in Doxygen, since 1.8, which means when I write my pages describing software design I can do so in Markdown, getting instant previewing and export.

It uses the extensions from PHP Markdown Extra, and GitHub flavored Markdown. I've found the simple tables and fenced code blocks incredibly useful.

Full details at
http://www.stack.nl/~dimitri/doxygen/markdown.html

Andy Dent on November 6, 2012 3:37 PM

Prove that 'Go' instead of 'No' mentality of the interwebs is stronger. Please.
Make it work. Adoption by non-techies like me will flourish.

Dulk on November 6, 2012 11:21 PM

@Andy Dent, you can choose "No Affiliation", which means you're only representing yourself.

@Evan Plaice, your arguments against standardizing Markdown could be made against standardizing HTML 20 years ago too. Now that we have a proposed W3C Working Group to handle the standardization of the Markdown language, I believe that's the best way forward.

asbjornu on November 7, 2012 3:53 AM

I hate that markdown doesn't do bold, italics and underlining this way:

*bold*
/italics/
_underline_

where you escape *, / and _ with \ if you don't want styling.

That's how it should be as it matches text/plain email composition style. You should have to do 2 ** before and after to get bold.

Shadow2531 on November 7, 2012 2:12 PM

"You should have to do 2..."

Shouldn't I mean.

Shadow2531 on November 7, 2012 2:14 PM

@asbjornu

You're assuming the W3C drives the direction of the web. They kinda lost that distinction with the whole XHTML 1.0/HTML 4.01 debacle. Last I checked the WHATWG was the driving force behind HTML5 not the W3C.

I would argue that they're probably one of the worst organizations to handle the Markdown specification. They're already too top-heavy. When it comes to creating a new spec the group behind it needs to be small, influential, and highly motivated.

Evan Plaice on November 7, 2012 9:24 PM

@Evan Plaice, the problem with the stagnation of HTML was of the existing WG in place and its decision to deprecate HTML altogether in place of XHTML. WHATWG was created to continue the development of HTML since there was no way to start that initiative from within W3C.

Since there is no existing Markdown WG in W3C, I don't think it faces the same problems as HTML did 8 years ago. While I agree with Anne van Kesteren's criticism of the W3C Process, I think it mainly boils down to how good the chairs and editors of the WG are. If we go the IETF route, those chairs and editors are even more important (from my experience being involved in RFC 4287 and 5023 as well as HTML5); just look at the mess that is OAuth 2.0.

I'm not sure that creating an ad-hoc standardization effort without the backing of an existing organization is such a good idea either; microformats isn't in a much better shape than HTML was 8 years ago. I'm not saying this is easy, I'm just saying it might be easier if we go with an organization that at least have a track record (although not perfect) than no organization at all.

asbjornu on November 8, 2012 1:27 AM

I 100% agree with everything you're saying. Markdown is spectacular and the fragmentation out there is doing it an extreme disservice.

I've been using Markdown for notes, documentation and even for writing essays. If markdown could be adopted by Google for Sites and by Evernote, I think it would take over the world.

With that being said, a friend is writing a book and showed me AsciiDoc (http://www.methods.co.nz/asciidoc/) which is like a way-complicated markdown, but adds a lot of nice features for basic formatting that I think Markdown is missing for longer documents. If I were to write a book, I'd probably draft it in Markdown, but then spend a week wrangling it into some other format (asciidoc? TeX?) so that it pages and footnotes properly.

A quick search in the comments and someone else mentioned asciidoc, too. The beat me to it.

Spike Grobstein on November 8, 2012 6:08 PM

I'm rather surprised that reStructuredText is getting so much airplay while multimarkdown has but a single mention.

Shaneknysh on November 13, 2012 6:36 PM

I just subscribed to the W3C mailing-list, as joining the group was _a bit_ too complicated when your organization is not yet part of W3C (do I own any rights etc. hell if I know..).

Anyway, I very much second the initiative and hope this will go somewhere!

If this is more a people's issue rather than a technical one, why not first have major parties at least subscribe to a common communication platform? (I also went to visit github/markdown but found no way to subscribe there..).

Christophe Muller on November 14, 2012 8:18 AM

Christophe, you can join the W3C WG as an individual (as I did).

asbjornu on November 16, 2012 12:56 AM

I have wrote post about Markdown for PHP in Russian: http://plutov.by/post/markdown_php.

Jeff Atwood, I advise to you to add Markdown to your comment form :)

Alexander Plutov on November 20, 2012 1:07 AM

The comments to this entry are closed.