# Standardize listing of Markdown Flavors used in the MD document: GLFM, GFM, QMD, etc **URL:** \ **Category:** Uncategorized\ **Created:** [May 22, 2026, 5:13am UTC](https://talk.commonmark.org/t/standardize-listing-of-markdown-flavors-used-in-the-md-document-glfm-gfm-qmd-etc/9064 "2026-05-22T05:13:25Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![murz](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/murz/32/3456_2.png) [@murz](https://talk.commonmark.org/u/murz)\ **Post date:** [May 22, 2026, 5:13am UTC](https://talk.commonmark.org/t/standardize-listing-of-markdown-flavors-used-in-the-md-document-glfm-gfm-qmd-etc/9064/1 "2026-05-22T05:13:25Z")
Standardizing a single common Markdown syntax seems like an impossible challenge! So, now we already have a lot of different popular “flavors” for Markdown syntax: CommonMark, GitLab Flavored Markdown (GLFM), GitHub Flavored Markdown (GFM), Quarto (QMD), Markdown Extra, MultiMarkdown, R Markdown, etc. And have a lot of `.md` files that can use different flavors, even more than one in a single document… But we have no standardized approach to describe which flavors should be used to render this specific `.md` file! As a result, file viewers can only guess which flavor to try to apply to render the document correctly! Let’s fix this by proposing a standard to list the flavors, used in the current document, to give the viewers and renderers a clue how to render this Markdown file correctly. My proposal is to recommend using the Front Matter block with the `flavors` key like this: ```auto --- title: Foo flavors: - GFM - R-Markdown --- The markdown body. ``` The list of flavor names is already tracked in the RFC [RFC 7764 - Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations](https://datatracker.ietf.org/doc/html/rfc7764#section-3) , as I understand, so we can use the naming vocabulary from there, and the RFC contains links to the references. Also, we can name this key not as `flavors` but as `extensions` or `plugins` to be clearer. The list of flavors is an array, to make it possible to set the priorities (first is the winner) of how to render specific blocks, if they are covered by more than one flavor. Alternatively, we can put a link to the specifications in addition to the flavor name (unique id) in this list, but in such a case, we should standardise the format of the specification, that is a hard challenge too. What do you think about this idea? ---
**Author:** ![murz](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/murz/32/3456_2.png) [@murz](https://talk.commonmark.org/u/murz)\ **Post date:** [May 22, 2026, 5:20am UTC](https://talk.commonmark.org/t/standardize-listing-of-markdown-flavors-used-in-the-md-document-glfm-gfm-qmd-etc/9064/2 "2026-05-22T05:20:05Z")
Cross-posted to the GitHub issue: [Proposal: Standardize listing of Markdown Flavors used in the MD document: GLFM, GFM, QMD, etc · Issue #830 · commonmark/commonmark-spec · GitHub](https://github.com/commonmark/commonmark-spec/issues/830) ---
**Author:** ![Crissov](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/crissov/32/1455_2.png) [@Crissov](https://talk.commonmark.org/u/Crissov)\ **Post date:** [May 23, 2026, 3:34pm UTC](https://talk.commonmark.org/t/standardize-listing-of-markdown-flavors-used-in-the-md-document-glfm-gfm-qmd-etc/9064/3 "2026-05-23T15:34:47Z")
Since you know about RFC 7764, you probably already noticed yourself that [RFC 7763](https://datatracker.ietf.org/doc/html/rfc7763#section-2) introduces a `variant` parameter for protocols and formats that support ones, e.g. HTTP or MIME email. For some reason, most file systems do not support something compatible, though. I don’t see why you would need a different name for your proposed use within YAML headers. However, the very existence of such headers constitutes an extension to Commonmark or Markdown and therefore cannot occur in every _variant_. In conclusion, it would be the wrong place in the stack of presentation layers to store that meta information in. ---
**Author:** ![murz](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/murz/32/3456_2.png) [@murz](https://talk.commonmark.org/u/murz)\ **Post date:** [May 23, 2026, 6:25pm UTC](https://talk.commonmark.org/t/standardize-listing-of-markdown-flavors-used-in-the-md-document-glfm-gfm-qmd-etc/9064/4 "2026-05-23T18:25:55Z")
The [RFC 7763](https://datatracker.ietf.org/doc/html/rfc7763#section-2) describes a single variant for a document, and I don’t see in the RFC any recommendation on how to define this variant in the `.md` file. Actually, I am okay to use the term “variant” instead of “flavor”. But as I see in reality, we can have a mix of variants in a single document, therefore people call them “flavors”, not “variants”, because one file can use multiple flavors. This is the reason why I recommend allowing the definition of a list of variants, not only a single variant. Maybe this is not a good idea, but we have what we have 😉 So, let’s maybe just rename “flavors” to “variants” and keep the array? ---
**Author:** ![Crissov](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/crissov/32/1455_2.png) [@Crissov](https://talk.commonmark.org/u/Crissov)\ **Post date:** [May 24, 2026, 4:55pm UTC](https://talk.commonmark.org/t/standardize-listing-of-markdown-flavors-used-in-the-md-document-glfm-gfm-qmd-etc/9064/5 "2026-05-24T16:55:33Z")
How would you use multiple _flavors_ or _variants_ within a single document? Several renderers may produce the same output, if configured accordingly, but the author writes the document in accordance to a single specification. Many renderers allow to turn on or off _options_, _extensions_, _modules_, _features_ or something like that (e.g. “pipe tables” or “double-tilde strike-through”). A certain collection of those makes a flavor or variant (together with a base like Commonmark). ---
**Author:** ![vas](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/vas/32/1267_2.png) [@vas](https://talk.commonmark.org/u/vas)\ **Post date:** [October 3, 2026, 7:28pm UTC](https://talk.commonmark.org/t/standardize-listing-of-markdown-flavors-used-in-the-md-document-glfm-gfm-qmd-etc/9064/6 "2026-10-03T19:28:43Z")
Another approach is gracefully degrading stacked file extensions, such as `foo.gfm.md` and `bar.rmd.md`, where the more general specifier is on the right. This has the benefit of graceful degradation, as generic `md` tools will still render the GFM file or R Markdown file, even if some elements aren’t properly or ideally rendered. Since R Markdown is a superset of Pandoc Markdown, `*.rmd.pmd.md` would enable it to be opened by R Markdown editors, Pandoc Markdown editors and any Markdown editors, with graceful degradation in the latter two.