<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I am seeing a lot of concern expressed for backwards compatibility. Thoughts below.<br><br>On Aug 13, 2011, at 7:14 PM, Waylan Limberg &lt;<a href="mailto:waylan@gmail.com">waylan@gmail.com</a>&gt; wrote:<div><br></div><div><blockquote type="cite">On Aug 13, 2011, at 3:00 PM, John MacFarlane wrote:</blockquote><blockquote type="cite"><br></blockquote></div><div><blockquote type="cite"><blockquote type="cite">Of course, going forward, implementors have to worry about backwards<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">compatibility. &nbsp;I don't want to make changes that are going to break<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">old pandoc documents.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">We have the same concern. A few extensions are rather old now and<br></blockquote><blockquote type="cite">while other implementations have implemented a better syntax, we can't<br></blockquote><blockquote type="cite">change ours because people using our library with the old<br></blockquote><blockquote type="cite">implementation will now need to update countless numbers of documents.</blockquote><br><div>On Aug 14, 2011, at 4:24 AM, Michel Fortin wrote:</div><div><br></div><div></div><blockquote type="cite"><div>But standardizing even the most basic feature is likely break backward-compatibility for many people, so how can it be done?</div></blockquote><div><br></div><div>First, let me say all of you have a most admirable dedication to your users, and I applaud it.</div></div><div><br></div><div>In my mind, the backwards-compatibility concern is not as big an issue as it might seem.</div><div><br></div><div>Why?</div><div><br></div><div>First let us consider two broad methods of moving forward toward a unified syntax.</div><div><br></div><div>1. People agree on better-defined syntax and update their libraries accordingly.</div><div><br></div><div>2. A rebranded effort, not called Markdown, but presented as its more-powerful, better-defined successor. <i>New</i>&nbsp;libraries, even if largely based on old, are released, under <i>new </i>names.</div><div><br></div><div>With option #1 your concern is undeniably valid and troubling.</div><div><br></div><div>With option #2 it is a much more surmountable problem, in my opinion.</div><div><br></div><div>Note I also assume that something like Markdownify (or Markdownify itself, forked or updated) will exist to convert HTML to Markdown’s successor.</div><div><br></div><div>Now instead of updating a Markdown library leading to broken documents, I am making a choice to <i>replace</i>&nbsp;the older Markdown library with its successor. &nbsp;And perhaps now it crosses my mind to see if the syntax is the same, and lo and behold, on the successor's website there is a section about said differences -- <i>with a link to an automatic converter.</i>&nbsp; One could even exist completely online, using the old library to output HTML and then using the Markdownify-type tool as the last step.</div><div><br></div><div>These Markdown-successor libraries could even theoretically include a converter tool (like sass, which includes a converter between .sass, .scss, and .less formats). Implementation possibility: Run the old library on the input, then convert the HTML to the newer format, perhaps even by calling out to the Markdownify-type tool internally. Solvable problem, theoretically nearly trivial, given the existence of a Markdownify type program hosted somewhere, perhaps with bandwidth funded by the hypothetical Kickstarter project some of us are considering.&nbsp;</div><div><br></div><div>FWIW: Markdownify was written in PHP by&nbsp;Milian Wolff, who I see has not posted here for a while.</div><div><br></div><div>Alan Hogan</div></body></html>