Markdown flavors

[joshbruce]

Marked version: 0.3.17

Proposal type: project operations

What pain point are you perceiving?

See comment from @intcreator for context.

I think it would also be a good idea to mention which Markdown specifications Marked will adhere to and whether or not Marked can add features with flags or maintain itself as an easily extensible base.

The README mentions that both CommonMark and GFM are supported, but I would go into a little more detail on the mechanics. For example, these questions come to mind:

1. Do we always start to adhere to the latest version of the spec immediately or wait to adopt it at a certain version/milestone?
2. What happens when a user uses CommonMark vs GFM under the hood?
3. Do we have plans for supporting other flavors/dialects of Markdown?

Edit: I just discovered USAGE_EXTENSIBILITY.md, which may be a better home for some of this information.

What solution are you suggesting?

1. Not until the identified version is 100%. Having said that, it does raise the question: Do we continue backward compatibility with previous versions of the spec?
2. From a spec perspective, GFM just adds some concepts to CommonMark. Which raises a question of, do we really support specs; or, do we support certain implementations of concepts (tables, for example, are a concept available in both GFM and MultiMarkdown). This is why we have that statement under the supported specs re possibly "accidentally" supporting other flavors. For 0.x I would say it's kind of a mess under the hood.
3. I would say plans, but definitely something to consider moving into 2.x or even 1.x??

[intcreator]

1. Perhaps we can make clear which version of the spec each version of Marked adheres to so if people want compatibility available in a certain version of the spec they can use the corresponding version of Marked? Potentially even syncing Marked versioning to the spec in some way?
2. I think it makes the most sense to adhere to the specs for what Marked says it supports. That means that Marked supports the GFM implementation of tables, not a generic/ambiguous implementation of tables.
3. Totally fine if it needs to be moved to another version, as long as it is clear to users so they have less of a chance of bringing it up.

[joshbruce]

1. See Update release template #1100
2. From an implementation perspective, we could have both, I think? ...see pseudo
3. Agreed.

function Tables() {
  switch (markdownFlavor) {
    case 'gfm':
      doGfmTables();
    case 'multimarkdown':
      doMarkdownTable();
    // if a given flavor has the same implementation as another
    case 'something':
      doGfmTable();
  }
}

Guess the question I have is: Are the rules for the tables different? If not, then that's a "common" implementation of that concept. I don't think there's much difference in the rules related to tables between MultiMarkdown and GFM, for example, could be wrong.

[intcreator]

1. 👌
2. I need to understand the overall architecture more before I can really analyze this. I think documenting how CommonMark and GFM already work in Marked should be done by 1.0. Then we can decide if we want to change it later.
3. For 1.0, I think we should focus just one what Marked supports so far (CommonMark and GFM). With 2.0 we can start supporting other flavors if needed.

[joshbruce]

1. 🎉
2. Fair.
3. Good idea. Tagging Modularization of library #746 and [Proposal]: Marked roadmap update and details #1077

[joshbruce]

Closing