Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Proposal: Standardize listing of Markdown Flavors used in the MD document: GLFM, GFM, QMD, etc

Abierto
#830 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
markdown

Línea de trabajo

Start by reviewing the proposal in issue #830 and the flavor vocabulary and references in RFC 7764 section 3. The issue names no repository files, tests, or implementation entry point. Done would require agreement on a standardized front matter key, naming vocabulary, and priority semantics before implementation work can be defined.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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:

---
title: Foo
flavors:
  - GFM
  - R-Markdown
---
The markdown body.

The list of flavor names is already tracked in the RFC 7764 , 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, which is a hard challenge too.

What do you think about this idea?

Lenguaje dominante
Python
Estrellas
5.2k
Forks
360
Métricas de merge de PR
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de commonmark/commonmark-spec

Todos los issues de commonmark/commonmark-spec

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.