Hi, because of the great editor "Writer" from Information Architects I've learned about Markdown and I love it. But it's very confusing, that there are so many standards with different features: classical Markdown, Markdown Extra, MultiMarkdown. I think for most users and the spreading of Markdown it would be nice, to have only one syntax. And this universal syntax should have the additions of MultiMarkdown: footnotes, tables, definition lists, citation, metadata (author, title, date), and so on... Because I think many people would like to have these additional functions in Markdown. And who doesn't need these additional functions, simply doesn't use them. I think, one universal Markdown-syntax with the additional possibilities of MultiMarkdown would be less confusing for consumers and would help to spread Markdown in more apps and to more users. Because it's really great! Best regards, Flo Sperlich
Hi Flo, I think the idea is the 'classic' Markdown is also supposed to be the universal one. If you want or need more features, you can choose one of the many non-standard variants, but they are just that: non-standard variants. I, for one, like Markdown as it is. Cheers, Wander On Wed, Aug 10, 2011 at 20:56, Florian Sperlich <flo.sperlich at googlemail.com> wrote:> Hi, > > because of the great editor "Writer" from Information Architects I've > learned about Markdown and I love it. But it's very confusing, that > there are so many standards with different features: classical > Markdown, Markdown Extra, MultiMarkdown. I think for most users and > the spreading of Markdown it would be nice, to have only one syntax. > > And this universal syntax should have the additions of MultiMarkdown: > footnotes, tables, definition lists, citation, metadata (author, > title, date), and so on... Because I think many people would like to > have these additional functions in Markdown. And who doesn't need > these additional functions, simply doesn't use them. > > I think, one universal Markdown-syntax with the additional > possibilities of MultiMarkdown would be less confusing for consumers > and would help to spread Markdown in more apps and to more users. > Because it's really great! > > Best regards, > Flo Sperlich > _______________________________________________ > Markdown-Discuss mailing list > Markdown-Discuss at six.pairlist.net > http://six.pairlist.net/mailman/listinfo/markdown-discuss >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110810/1706aae1/attachment.html>
> Hi, > > because of the great editor "Writer" from Information Architects I've > learned about Markdown and I love it. But it's very confusing, that > there are so many standards with different features: classical > Markdown, Markdown Extra, MultiMarkdown. I think for most users and > the spreading of Markdown it would be nice, to have only one syntax. > > And this universal syntax should have the additions of MultiMarkdown: > footnotes, tables, definition lists, citation, metadata (author, > title, date), and so on... Because I think many people would like to > have these additional functions in Markdown. And who doesn't need > these additional functions, simply doesn't use them. > > I think, one universal Markdown-syntax with the additional > possibilities of MultiMarkdown would be less confusing for consumers > and would help to spread Markdown in more apps and to more users. > Because it's really great!Flo, I completely agree with you. It's absurd. There are two steps to evolution: Mutation and natural selection. With Markdown we see more mutation than selection, though MultiMarkdown and PHP Markdown Extra do seem to be "selected" more than other mutations. There are those of us in the Markdown community who hope for some sort of official, largely-universial "version 2" of some sort (whatever it's called). Unfortunately this desire is far from universal. Alan
On Thu, Aug 11, 2011 at 4:56 AM, Florian Sperlich <flo.sperlich at googlemail.com> wrote:> > And this universal syntax should have the additions of MultiMarkdown: > footnotes, tables, definition lists, citation, metadata (author, > title, date), and so on... Because I think many people would like to > have these additional functions in Markdown. And who doesn't need > these additional functions, simply doesn't use them.Not to be a party pooper, but I really think it would be a good idea to try and fix the ambiguities and problems in the core syntax (and implementations thereof) before trying to find common ground between the legions of hideously ugly and frequently incompatible extensions. To get things started, here's a test case that most of the implementations on babelmark fail: http://babelmark.bobtfish.net/?markdown=*+*+&normalize=on&src=1&dest=2
I think that for any movement towards a "unification" of the Markdown variants to have a chance of success, the first step is to agree on a core set of principles. For example, one of my core principles for MultiMarkdown is taken from Gruber:> The overriding design goal for Markdown?s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it?s been marked up with tags or formatting instructions.Intelligent people can (and do...) quibble about whether I have overstepped this design with some of the features I have added, or whether they could be implemented in a less obtrusive way. There's always a tradeoff between functionality, versatility, readability, and ease of composing. Some of the suggestions being thrown around in this discussion, IMHO, are far afield of this principle, to the point where I would not consider implementing them in MMD. The longer this discussion goes on, the more I find myself reinforced in my belief that MMD represents the compromise point that is best for *me.* I find myself less interested in the effort it would take to complete this overhaul, if I were to believe that the end result would be a product less suitable to my needs than the current implementation. Without a clear set of guiding principles, I fear that any effort to create a successor to Markdown is going to end in "design by committee." The original Markdown syntax seems to have had a clear purpose and vision, which is why it resonates so well with so many. Sadly, it has been abandoned which means two things: 1) known bugs/edge cases/what have you are not being fixed 2) new features are not being added #1 is inarguably a problem. #2 is only a problem depending on your perspective. The first feature I added was to support the very footnote syntax that Gruber himself had proposed, but never implemented. It grew from there, but I haven't really added new syntax features to MMD in quite a while, and it becomes increasingly unlikely that new features will be added as time goes on. I feel that Markdown was incomplete, but I recognize that not everyone feels that way and it is perfectly suitable for some people. So, as the creator of MultiMarkdown, which from my totally biased perspectives seems to be one of the more popular descendants of Markdown, particularly among those still being actively developed, here is my plan/proposal: 1) I will support efforts to standardize the edge cases of the Markdown syntax to minimize discrepancies between flavors. My personal vote would be that John MacFarlane's peg-markdown is a good place to start --- it allows a mechanism for clearly defining a syntax, and that definition can easily be pulled directly into Markdown based tools for transformation or syntax highlighting. Other tools would not necessarily have to be built around a PEG definition, but it would represent the official rulebook on what should happen. Regardless of the tool chosen, I think such a formal definition would be a "good thing." 2) I will support efforts to create a universal test suite to help measure compliance with such a standard syntax definition. I have made my own additions to the test suite that John MacFarlane used in peg-markdown, which was originally created by John Gruber. The actual tool itself doesn't matter to me, but I do think the tests should be restructured so that there are more test files that each test a specific thing. 3) I will support efforts to standardize the syntax of extensions and/or output formatting, *where it makes sense*. I fully admit that "where it makes sense" is a totally subjective statement, and completely at my whim. And this is where a clear set of guiding principles would make it more likely that MultiMarkdown would merge towards the consensus opinion, rather than staying put. If the consensus among others was that they wanted the most flexible, powerful features, at the expense of a high markup to content ratio, then I would politely decline to implement those features as it clashes with my vision for MultiMarkdown. I agree with others who have pointed out that agreeing on extensions is a separate, and likely more contentious, problem than fixing the known lingering issues with Markdown itself, and should probably be pursued as a separate, but possibly parallel, project. 4) I am busy enough with my own projects that I am not willing to take this on as a lead (not that anyone was asking me too...) I am happy to help if there is a project started with a purpose I can agree with. I would be interested in assuring that MultiMarkdown is compliant with the agreed upon standard. But I, like others on this list, don't have the time to manage this as new project. I'm interested in further thoughts, feedback, discussion... F- -- Fletcher T. Penney fletcher at fletcherpenney.net
Am 17.08.2011 um 18:00 schrieb markdown-discuss-request at six.pairlist.net: Fletcher T. Penney pointed this out:> I think that for any movement towards a "unification" of the Markdown variants to have a chance of success, the first step is to agree on a core set of principles. > > For example, one of my core principles for MultiMarkdown is taken from Gruber: > >> The overriding design goal for Markdown?s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it?s been marked up with tags or formatting instructions. >Fletcher, sorry, but personally -- despite loving MMD (and even having used MMD CMS for a diary) -- I have never liked the way MMD handles metadata. Partly this is because, not being a native English speaker, I dislike English meta descriptors. A localization could resolve this -- but I still think it looks ugly. However, do you actually need descriptors at all? I doubt it: * The title could be anything "at the start" of the document. Blosxom is a good example. Anything up to the first blank line is the title. * After that, anything between the first blank line and the second blank line would be treated as additional metadata. * Instead of the "Author:" descriptor, explicitely stated, it should suffice to write "by". What follows is the name of the author. (Localization would be easier as only this "keyword" would have to be known to the parser in a number of languages.) * Dates would be self-explanatory, to a clever parser. * Any list of words separated by commas on a single line would be treated as tags. * Any more fanciful meta descriptors might be given explicitly just as in MMD before. This could be left to non-standard, personalized variants of Markdown. Thus the following would be a valid document: --- Test Document for Automatic Metadata Detection by Christoph Freitag 08/17/2011 Markdown, Standardization, MMD, Metadata A Markdown document may contain metadata in a human readable form that the parser converts to a machine readable form of metadata automatically. A casual reader will understand the content directly and without distraction. Bowerbird will love this. --- Best regards, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110817/3d5e0545/attachment.html>
here are some of the things that i think. i would expect some people to disagree. *** it's great to see this discussion taking off... and great to see penney and macfarlane here, taking part... *** the combination of multimarkdown with pandoc -- especially given penney's recent advances -- can't be defeated by another markdown superset. so the stalemate has now been effectively resolved. you either achieve parity with multimarkdown, or fold. and a number of developers will decide that there is no future in "achieving parity" with the front-runner. nonetheless, the deadlock is broken, the standoff over. *** it will be interesting to see if gruber lets you use the name "markdown", or if he has some vested interest in keeping it. *** penney cites gruber:> The overriding design goal for Markdown?s > formatting syntax is to make it as readable as possible. > The idea is that a Markdown-formatted document should > be publishable as-is, as plain text, without looking like > it?s been marked up with tags or formatting instructions.um, whenever i look at a multimarkdown input-file, it certainly does _not_ look like it's "as readable as possible" to my eyes. i see all kinds of crap that won't appear on the printed page (or the .html screen), and all that crap is a major distraction. so i think a lot of you guys are fooling yourselves that your markdown input-files are "readable" and even "publishable", and i don't believe the general public is gonna buy that line. because they want something that really _is_ readable as-is. (because you need to read a document as you're editing it.) now i am obviously being swayed by the fact that i invented a light-markup format which specifically eschews such crap, and does it successfully, so i know that it is entirely possible. and perhaps i'm overestimating the importance of that benefit to the general public and its uptake of a light-markup format. we'll see... but i suggest that it might be good for you to make some use of this opportunity which "unification" presents, enabling you to go back to the drawing-board and strip away what you can. *** making a new start will also allow you to rethink the process. my recommendation would be that you return to the basics, in the sense that you explain the conversion in pseudo-code. here is the pseudo-code for my conversion process: 1. split the document into "chunks", separated by blank lines. 2. walk through your array of chunks, assigning each its tag. 3. output chunks based on tag (plus maybe neighbors' tags). as you can see, this process works in any language/compiler. and it's so simple that even a beginner-programmer can write and/or maintain such a converter routine. these concerns are vital, especially if you lose developers -- as i predicted above. but they are also important from a _pedagogical_ standpoint, in the sense that you need to educate users about the format. there should never be any doubt what a specific chunk will be. crystal clarity in the end-user's mind should be your objective. *** there is no need for an influx of cash to create a solution. which is good, because there is no influx of cash coming. but even if there _was_, the markdown community would _not_ know how to allocate that cash to obtain a solution. indeed, there is serious doubt that it could even be done... it would likely cause little but dissension and hard feelings. *** there's no need for a resolution to take "18 to 36 months"... it could be done in 18-36 days, or maybe even 18-36 hours. (how long does it take to say "standardize on multimarkdown".) macfarlane has vetted multimarkdown very carefully, so if he can't tell us anything "wrong" with it, there's nothing "wrong". (ditto on terpstra and jalkut, who decided on multimarkdown.) so if you've got beef, you'll have to thrash it out with fletcher. (and if you feel you'll beat the multimarkdown/pandoc combo, especially with penney's "composer" debut, you are deluded.) on the bright side, penney doesn't seem to be too dogmatic, so if you have a good argument for change, he'll likely listen. *** speaking of the markdown community, it might be good if you actually started enabling such an entity, so that you could listen to what it has to say... a lot of you do speculation about "what" your user-base "wants", but you're more-or-less just guessing. if you had a way to poll the community, the answers you'd get would be _much_ more reliable, and accurate, and actionable... *** and of course it'd be good even if you just got the _developers_ on-board and talking to each other. for instance, in recent days, brett terpstra and daniel "punkass" jalkut have made big advances in markdown that have moved it forward in a significant way, yet neither of them is here on this list, or talking to the "community". *** one of the things that might come out of such widespread input is a strong consensus on what's "really needed" and what's not... my work has always been defined by _books_, so if a certain structure was one that was found (even if rarely) in _books_, then it was a structure which i needed to be able to support. you don't seem to have such a laser-focus; it might help you. *** meta-data belongs at the end of a document, not the start of it. *** anyway, those are some of the things that came up while i was chatting with grandmother at our bridge club the other night... -bowerbird -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110817/473c5a2c/attachment.html>
i do not disavow fletcher's disavowal of my opinions... :+) they are mine, and mine alone. and anyone can disagree. having said that... 1. it simply doesn't matter what implementation is "best". there is a clear leader now, so the icejam has been broken. and penney knows it, since he's using his "composer" app. and i know it, because i've been using a similar capability in my own dogfood for years now. it is a kick-ass feature. there's good reason "marked" -- even as clumsy as it is -- is still in the top-200 on the mac app store best-seller list. 2. if you want to call it "markdown 2.0", gruber will have to give y'all his permission. i said it will be "interesting" to see if he gives it, or not. because "interesting" is the right word. 3. macfarlane, terpstra, and jalkut could've utilized _any_ of the markdown supersets; but they chose multimarkdown. doesn't matter if they "back that up" with a public statement or not, because each of the choices speaks loudly for itself. and the cumulative flow of all three of 'em is overwhelming. it's also the case that new improvements to multimarkdown -- such that it is now easily deployed in i.o.s. environments, and without troublesome dependencies -- made a big jump in regard to leapfrogging over variants once superior to it... 4. fletcher tries not to be immodest too. he fools no one. ;+) -bowerbird -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110817/5015f985/attachment.html>
As the defacto maintainer of both the Pandoc bundle for TextMate and the Pandoc plugin for Vim, I wanted to add to the discussion another benefit of standardizing the syntax for markdown extensions: we would only need one syntax definition for each major text editor.