Community Group for Markdown Standardization

[Aristotle Pagaltzis]

* Fletcher Penney <fletcher at fletcherpenney.net> [2012-11-20 16:00]:

> 1. Is Gruber in or out? He made his first contribution to the list in

>    years to basically say that he is out.


For the purposes of this effort, this question seems irrelevant, based
on several reasons. See next answer.


> 2. If that is true, is everyone else willing to "move past" Markdown

>    and into something new. Even if it's Markdown-like, it will

>    probably have to use a different name, unless Gruber likes what he

>    sees and changes his mind on the back end. Even in that case,

>    I think we would all be shocked if he modified Markdown.pl to be

>    compliant (since it hasn't seen a change in years.) Which brings us

>    back to the beginning of how important is the Markdown "identity."

>    Would it still be Markdown if the original code is non compliant?

>    This is a philosophical discussion that has real-world

>    implications.


The “Markdown Extra” model applies. Consider how many implementations
support its syntax extensions – in some form! (there is no formal
specification for it either after all) –, and, less widely, the
MultiMarkdown extensions (same caveat applies). Gruber’s blessing was
not required for these to spread.

And all of these implementations implement Markdown primarily – though
extensions as well.

None of them are bug-for-bug compatible with Markdown.pl.

They all still have a legitimate claim to the “Markdown” name – in fact
Gruber’s de-lurk posting essentially sanctioned this use.

If the implementations of this new standard still process documents in
the spirit of Markdown.pl, I see no problem in them claiming a name that
includes “Markdown”. They *are* Markdown implementations – only ones
that are consistent amongst each other, and optionally with some stuff
on top. Just like Markdown Extra.

It won’t matter if Markdown.pl is never updated since normal users will
almost never see difference between its output and that of one of these
newer tools (as long as they’re not relying on “Markdown Plus” features
obviously) – same as Markdown Extra.

As for applications that support Markdown, few of them use Markdown.pl
any more, from what I can tell. So no concern there either.


> 3. Similarly, you now have to "herd cats" and convince the developers

>    (and users) of various implementations that it's worth the days

>    (weeks?) of effort it might take to bring their own code into

>    compliance. And at the end, what do they have to show for it? Old

>    documents that no longer work as expected?


If you and Michel implement it I think the rest will be history. Get the
GitHub, StackExchange and/or Reddit guys on board, and it’s a wrap. Make
sure the needs of these biggest users are heard, whatever you do; which
shouldn’t be hard since they’re all implementers too.

Above all make sure the effort yields as a primary deliverable besides
the standard a large test suite. That will make it irresistible to
a certain cohort of implementers all by itself. Esp if it separates the
tests for the formalised version of Gruber’s Markdown from those of the
syntax extensions from the new standard.


> 4. I don't agree with the command line switch approach that has been

>    discussed. If something like this is going to work, I think

>    everyone needs to jump in with both feet. Keep old code around for

>    older documents (it doesn't stop working, after all). But trying

>    to maintain two separate behaviors is going to be more challenging

>    -- new versions should use the new behavior.


IMO libraries should support both “Markdown Formalised” and “Markdown
Plus” and leave it up to the application to decide which one it will
offer, but applications should pick yes or not and stick with that
choice: no user-facing preference.

The design of the syntax extensions should attempt to be both a) natural
and b) unlikely to be part of a document that isn’t explicitly using
them. That way applications *can* choose to support “Markdown Plus”
only, because the incompatibility with plain Markdown is minimised.


> 5. The biggest danger, IMHO, is that someone puts all the time and

>    effort into developing a standard, but that standard has serious

>    conflicts with the needs of each Markdown-variant developer. For

>    example, I wrote MultiMarkdown to fit my needs (footnotes, tables,

>    LaTeX, etc). If the new standard doesn't work for me, why would

>    I go through the effort to standardize? Now repeat this discussion

>    for each variant you're trying to bring into line.


Standards succeed when they formalise what is already widely supported.
Standards bodies are not the place to innovate.

If that is kept in mind, then this danger will be of no concern.

Of course the temptation to invent features in committee is always huge.


> 6. I think we all agree that standardization, in theory, is a "good

>    thing." The details will be critical in determining whether it works.


Keep it conservative: stick to existing implicit consensus, concentrate
on working out the edge cases and formalising. That is what will provide
value. Anyone who is after new features can implement them independently
and if a feature works out it will then be heard of anyway.


> 7. As for XML, LaTeX, PDF, etc --- I would suggest standardizing the

>    plain text input and HTML output first. If there is a need to

>    standardize more than that, it can be handled down the road. These

>    are probably not worth worrying about now.


I actually think these should be of no concern at all. I believe the
nature of Markdown to be a shorthand notation for HTML, so purely as
a model, the concept is obviously that all other formats flow from
a HTML-to-whatever conversion in a post-processing step after Markdown
has be expanded to HTML.

The exception to that is support for the one feature that is likely to
be added which has no direct support in HTML, precisely because of that
lack of direct expressibility in HTML, namely footnotes. (Or has HTML 5
provided a solution here (and one that isn’t still evolving)?)

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>