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.
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)
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)
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)