this is awesome!!! i’m on board and will follow your lead in implementing Markdown/Rockdown on the site i’m building.
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.
Hey Jeff, GitHub’s interested. I sent you an email with an introduction to our Head Markdown Guru. Let’s make it happen!
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.
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).
1 Like
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.
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.
Decent support for RTL text direction would be great.
A registered mime type would be great.
@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!
@PekkaG: 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).
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.
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.
@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.
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.
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.
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)
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
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
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.