text/markdown effort in IETF (invite)
jgm at berkeley.edu
Thu Jul 10 18:23:53 EDT 2014
+++ Carl Jacobsen [Jul 10 14 03:46 ]:
>> On Jul 9, 2014, at 3:07 PM, Michel Fortin <michel.fortin at michelf.ca> wrote:
>> I sure wish things would be simpler. But as things are now, I have a hard time identifying what "flavor" could mean. Should "Markdown.pl-1.0.1" be a flavor on its own?
>Perhaps it would be better to have *two* optional fields:
>- A "processor" field, as in `processor="Markdown.pl-1.0.1"` or `processor="Pandoc-22.214.171.124-nostrict", which indicates that the sender was using (that program) to view the output and was satisfied with it. This could be included whenever known, and hopefully *not* relied upon by the recipient, but could provide useful clues in some cases where the recipient *has* to decide how to interpret something.
>- A "flavor" field consisting of zero or more alphanumeric tokens, separated by "+" or "," or some such, declaring well-understood deviations from, or extensions to, the original standard. Not as a completely exhaustive list (you don't have to be able to indicate that your processor has, say, special syntax for animated gif backgrounds if no one else can use that anyway), but simply to promote better interoperability, to be interpreted as "the text contained herein supports basic markdown, plus *at least* X and Y and Z capabilities". Include some useful things like:
> - "nofill" (hard returns should be obeyed rather than joining lines - this would clarify that "two github flavors" situation),
> - "tables" (supports some agreed-upon "least common denominator" table syntax),
> - "footnotes" (similar but for footnotes),
> - "fencedcodeblocks" (you get the idea),
> - "titleblock" (text lines before first blank line are some sort of metadata and shouldn't be displayed to casual viewers),
> - "restrictunderscores" (mid-word underscores are not to be interpreted as starting/ending emphasized or strong text)
I already made an attempt in pandoc to factor out some of these
dimensions of variability (so that different markdown flavors can be
converted to each other). You can specify, e.g.,
See http://johnmacfarlane.net/pandoc/README.html#pandocs-markdown for
However, there are hundreds of more dimensions on which markdown
implementations vary (I could go on and on). A crude list of
extensions/variations might be helpful, but I don't think you
could get close to a complete list.
More information about the Markdown-Discuss