Addressing the Markdown-flavor issue

[bnb]

I've spent some time thinking about how to address the Markdown flavor issue, and I'd like to present my best (well, only, really) idea that could solve the problem.

I suggest we add another required property called flavor. The general idea is that the app that creates the essay will add one of several decided, standardized values to this field, and then the display app will read those values and apply the appropriate stylings.

I know that there are more than just several Markdown flavors, but I think selecting a few popular ones will be good. I suggest, Tent flavored Markdown (tent value in the flavor field), Github flavored Markdown(gh value in the flavor field) (simply because this is the most popular and well known flavor I know of; there are definitly superfluous features that wouldn't be needed outside GitHub), and standard markdown (std in the flavor field).

I know that this post type was inspired by a desire to integrate tent posts with Ghost. I was just looking through their planned feature list, and found that they're planning to have their own flavor of Markdown (see first list item). This raises the question about future operability. In my experience, Markdown flavors degrade gracefully.

For example, in TFM, italics are denoted by an underscore, and boldface by an asterisk. In regular Markdown, these both denote italics. While it's not ideal, it does still convey emphasis. In GitHub Flavored Markdown, you can link to an issue simply by putting a # followed by a number of an issue in the same repo, or even an issue in a specific outside repository by putting the owner's name, the repo name, and the issue number. These both degrade gracefully into standard text or list items.

In any case, this graceful degradation makes the different Markdown flavors compatable enough that even if new flavors are added to the standard which aren't supported by some applications, or someone uses a non-standard flavor that is unreadable to other applications, we can generally degrade down to std Markdown.

[joakim]

Thanks for adding to the discussion! And sorry for the late answer, I've been thinking about it for a week :)

What you suggest is a sound way to add support for flavors. But the more I think about it, it appears to me that supporting different flavors is a road fraught with peril.

• My main reservation is inconsistency. An app's Markdown renderer would have to support all possible flavors to be able to render posts correctly. Because posts will be used by a number of different apps built in different languages, support for flavors would vary a lot.
• It would also add complexity for developers wanting to support this post type, continuously having to update their app to support new flavors as they appear.
• Degradation would work in some cases as you mention. But there are other cases where it wouldn't be so graceful, for example how flavors handle line breaks in paragraphs differently. Some flavors also add completely new syntax parts that would be rendered as-is (messy) or even worse, as corrupt elements when degraded to standard Markdown.

In conclusion, what seemed like a good idea (to me as well) won't really work in practice. Unfortunately!

Like I said in this reply to Ian Jeffries, I now lean towards a "standard" Tent Flavored Markdown variant for long texts, extending Tent Flavored Markdown for Status with the most common/relevant features from other flavors such as GitHub Flavored Markdown, Markdown Extra, MultiMarkdown. Haunted Markdown is also relevant.

I think this has a number of advantages.

• For one, it would be consistent across renderers (a good spec and test cases would help get it right).
• Assuming Tent succeeds, popular renderers should eventually support it out-of-the-box, making it easy for app developers to add support for post types that use the flavor.
• End users would always know what to expect when encountering a long text field supporting Markdown in a Tent app. It's Tent Markdown. By building upon the Markdown syntax used by Status posts, it could become a natural part of the Tent ecosystem.

If going down this route, the problem becomes; which Markdown features should the flavor support?

[danielsiders]

I'd like to see a list of all the "features" people would want in a markdown flavor. Obviously everyone has their own preference on syntax, but what are the main features necessary for longer posts?

[joakim]

I'm keeping an eye on Haunted Markdown for just that (it's currently under development)..