Cómo añadir un checkbox en Markdown:sintaxis de listas de tareas y ejemplos.

Sintaxis de las listas de tareas en Markdown

Una lista de tareas es una lista normal cuyos elementos empiezan con una marca de casilla. La receta tiene tres partes:

1. Un marcador de lista

   Un guion, un asterisco o un más, seguido de un espacio: -. Un elemento numerado como 1. también sirve.

2. Una casilla entre corchetes

   [ ] con un espacio dentro es una casilla vacía. [x] es una marcada; una [X] en mayúscula también cuenta. No va nada más entre los corchetes.

3. Un espacio y después el texto

   Sin el espacio después de ], la línea sigue siendo texto plano con corchetes.

- [x] Draft the spec
- [x] Add the edge cases
- [ ] Get a review
- [ ] Hand it to the agent

Esto es lo que ve el lector:

• Draft the spec
• Add the edge cases
• Get a review
• Hand it to the agent

Checkboxes anidados

Sangra una tarea bajo otra para hacer una subtarea. Dos espacios funcionan en la mayoría de los renderizadores; cuatro son lo más seguro:

- [ ] Release 2.0
    - [x] Update the changelog
    - [ ] Tag the build
    - [ ] Announce it
- [ ] Plan 2.1

Puedes mezclar tareas con viñetas normales en la misma lista, y poner un párrafo, código o una cita bajo una tarea sangrándolo hasta alinearlo con el texto de la tarea. La casilla padre no se marca sola cuando terminan las hijas; la marcas tú.

Dónde se muestran los checkboxes de Markdown

• GitHub muestra las listas de tareas como casillas en archivos Markdown, issues, pull requests y comentarios. En un issue o un pull request puedes marcar una casilla en la página y GitHub edita el texto por ti.
• Las apps de Markdown que siguen GFM también las muestran. En DotMD aparecen como casillas en el lector. Allí son de solo lectura: para marcar una, edita la línea y cambia [ ] por [x].
• Los analizadores mínimos que solo conocen el Markdown original o CommonMark muestran el texto tal cual, con los corchetes. Sigue leyéndose como una lista de tareas, solo que sin casillas.

Si usas DotMD Editor, al pulsar Enter al final de una tarea empieza la siguiente con un - [ ] vacío, para que puedas seguir escribiendo elementos.

Una marca de verificación en Markdown sin lista de tareas

Cuando quieras una marca en una tabla o en una frase, y no en una lista, escribe el propio carácter. Los símbolos Unicode son texto, así que aparecen en cualquier app de Markdown:

GitHub también acepta códigos cortos de emoji como :white_check_mark:. Son una función de GitHub: en otra app pueden verse como texto sin procesar, así que usa mejor el carácter si el archivo se va a leer en otro sitio.

Listas de tareas en planes y specs

Las listas de tareas no son solo para apps de tareas pendientes. Un plan o una spec escrito en Markdown suele terminar con una checklist de lo que queda por hacer, y cada paso es fácil de revisar en su propia línea:

## Tasks
- [x] Add the settings screen
- [ ] Write the migration
- [ ] Update the tests
- [ ] Update the docs

Haz que cada tarea sea una sola acción que se pueda terminar y comprobar. Usa un encabezado para cada grupo y anida subtareas solo cuando pertenezcan a un mismo padre.

Por qué una lista de tareas muestra corchetes en lugar de casillas

• No hay espacio después del corchete: - [x]Done no es una tarea. Escribe - [x] Done.
• Espacios dentro de los corchetes: [ ] con dos espacios, o [ x ], es texto plano.
• No hay marcador de lista: una línea que empieza solo con [ ] no es un elemento de lista.
• Texto que empieza con un paréntesis. La documentación de GitHub dice que hay que escapar el paréntesis: escribe - [ ] \(Optional) Test it.
• El renderizador no tiene GFM. Entonces ves los corchetes escribas lo que escribas.

Para ver cómo queda un plan con tareas, abre el archivo en DotMD, donde leer es gratis. Las specs y los planes suelen escribirse como listas de tareas, y las casillas hacen que una lista larga sea fácil de recorrer.

Preguntas sobre los checkboxes en Markdown

Más preguntas