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.
I prefer reStructuredText too, but unfortunately Markdown âwonâ the simple markup market.
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.
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.
I endorse!
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.
In my opinion, Markdown has outgrown itâs original idea of âsimpler HTMLâ and is becoming a universal document format. To serve this purpose it needs more than just a spec for the file format. It needs a good simple object model for text that can become a basis for implementations of parsers and formatters in several different languages.
Most of the existing implementations work one way, i.e. from Markdown to HTML and donât have explicit model for text inside. Those who do, donât preserve document structure on load-save (for example, references are renamed on conversion from Markdown to Markdown).
Iâve been working on a JSON-based model for Markdown for some time. It currently has PEG-based parser, several formatters and a set of language-indepentent test cases. It also integrates with Pandoc and MultiMarkdown to import documents in their formats.
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:
Anyone interested in contributing is invited to connect to GitHub.
I prefer org-mode. Unfortunately, only emacs understands it.
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?).
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.
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 ?
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.
I wrote the Erlang Markdown interpreter https://github.com/hypernumbers/erlmarkdown
Real-life Markdown almost always requires that something be rendered twice:
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:
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.
http://www.w3.org/community/markdown/ The MarkDown community now exists. With your help its development can start.
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.
+1
Iâm not a complete power user of markdown - but the idea of continued fragmentation would be really frustrating.
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)