Escucha

Articulo de prueba 2

Aqui va el resumen

Ríos, Carlos22 de agosto de 20267 min

Prueba completa de Markdown

Este documento sirve para comprobar qué elementos de Markdown funcionan correctamente dentro de Articles.

Debe permitir distinguir entre problemas de parsing, problemas de CSS y funciones que requieren extensiones adicionales como GFM.

1. Párrafos

Este es un párrafo normal. Debería aparecer como texto corrido dentro de la columna editorial.

Este es un segundo párrafo. Entre ambos debería existir una separación vertical clara y consistente.

Este es un párrafo deliberadamente más largo para comprobar la justificación del texto. Una publicación editorial necesita mantener una longitud de línea cómoda, un interlineado suficiente y un comportamiento razonable cuando las palabras deben distribuirse entre ambos márgenes. En pantallas pequeñas puede ser preferible abandonar la justificación y utilizar alineación izquierda.

2. Negrita, cursiva y combinaciones

Esto es texto en negrita.

Esto es texto en cursiva.

Esto es texto en negrita y cursiva.

También debería funcionar negrita con guiones bajos.

Y también cursiva con guiones bajos.

Una frase combinada podría verse así: este concepto es muy importante, este término está enfatizado y este otro está fuertemente enfatizado.

3. Tachado

Esto debería aparecer tachado si GFM está habilitado:

~~Este texto está tachado.~~

Una frase normal puede contener ~~una idea descartada~~ y continuar después.

4. Código en línea

Este es un ejemplo de código en línea.

También podemos escribir nombres técnicos como render(), .article-prose, margin-inline: auto o article-art-0011.

El código inline debería distinguirse del texto sin parecer un botón.

5. Títulos

Heading nivel 1

Heading nivel 2

Heading nivel 3

Heading nivel 4

Heading nivel 5

Heading nivel 6

Después de los headings debería regresar el texto normal.

6. Lista sin ordenar

Primer elemento
Segundo elemento
Tercer elemento
Cuarto elemento

La lista debería mostrar viñetas visibles.

7. Lista ordenada

Primer paso
Segundo paso
Tercer paso
Cuarto paso

La numeración debería aparecer automáticamente.

8. Lista anidada

Instrumentos
- Cuerdas
  - Violín
  - Viola
  - Violonchelo
- Maderas
  - Flauta
  - Oboe
  - Clarinete
Recursos
- Partitura
- Grabación
- Bibliografía

Cada nivel debería tener una sangría claramente reconocible.

9. Lista ordenada anidada

Preparación
1. Reunir fuentes
2. Revisar materiales
Escritura
1. Formular argumento
2. Añadir ejemplos
Revisión
1. Corregir
2. Publicar

10. Task lists

Estas casillas requieren soporte GFM:

También una combinación:

Terminado
- Subtarea terminada
- Subtarea pendiente

11. Blockquote

Esta es una cita sencilla.

Puede contener más de un párrafo y debería mantenerse claramente diferenciada del cuerpo normal.

Texto normal después de la cita.

12. Blockquote con formato

Idea principal: una cita también puede contener énfasis, código y otros elementos Markdown.

13. Blockquote anidado

Primer nivel de cita.

Segundo nivel de cita.

Debería existir una diferencia visual entre ambos niveles.

14. Separador horizontal

Texto antes del separador.

Texto después del separador.

15. Enlaces

Este es un enlace hacia Bolivian Music Editions.

Este es un enlace hacia Astro.

El enlace debería distinguirse claramente del texto normal.

16. URL automática

Si GFM está habilitado, esta URL escrita directamente puede convertirse automáticamente en enlace:

https://example.com

Y también:

https://bolivianmusiceditions.com/

17. Tabla sencilla

| Elemento | Función | Estado |

|---|---|---|

| Markdown | Escritura | Activo |

| LilyPond | Partitura | Activo |

| D3 | Visualización | Futuro |

| MIDI | Escucha | Prueba |

Esta sección es especialmente importante.

Si funciona correctamente, debe existir una tabla real con filas y columnas.

Si aparecen literalmente los caracteres |, entonces las tablas no están habilitadas.

18. Tabla con alineaciones

|:---|:---|:---:|---:|

| Uno | texto | centro | 10 |

| Dos | texto | centro | 250 |

La segunda columna debería usar alineación izquierda, la tercera centrada y la última derecha si el parser respeta alineaciones GFM.

19. Tabla con formato dentro de celdas

| Concepto | Ejemplo |

|---|---|

| Negrita | Importante |

| Cursiva | Término |

| Código | render() |

| Enlace | BME |

20. Línea con salto manual

Esta línea termina aquí.

Esta línea debería comenzar inmediatamente debajo gracias a los dos espacios al final de la línea anterior.

Esta otra línea comienza después de un párrafo normal.

21. Caracteres escapados

Los siguientes caracteres deberían mostrarse literalmente:

*asteriscos*

_guiones bajos_

# numeral

> mayor que

| barra vertical

\ barra invertida

22. Entidades y símbolos normales

Estos símbolos deberían aparecer sin problemas:

También caracteres españoles:

á é í ó ú ü ñ ¿ ¡

Y algunos símbolos musicales escritos como texto:

♭ ♯ ♮ ♪ ♫

23. Texto entre comillas

“Esta es una cita entre comillas dobles.”

‘Esta es una cita entre comillas simples.’

«Esta utiliza comillas angulares.»

24. Código en bloque


Este es un bloque de código.

No debería interpretarse como Markdown.

# Esto NO debe convertirse en heading

- Esto NO debe convertirse en lista

**Esto NO debe convertirse en negrita**

25. Código JavaScript


const article = {

  title: "Prueba de Markdown",

  published: true,

};

console.log(article.title);

Debe aparecer como código, no ejecutarse.

26. Código JSON


{

  "title": "Prueba editorial",

  "status": "published",

  "year": 2026

}

27. Markdown dentro de código


# Este heading es solamente código

- Esta lista también es solamente código

> Esto tampoco es una cita renderizada.

| A | B |

|---|---|

| 1 | 2 |

Todo lo anterior debe permanecer literal dentro del bloque.

28. HTML arbitrario

La siguiente prueba NO deberías publicarla si la política de seguridad está funcionando.

Por esa razón la dejamos solamente descrita como código:


<div>HTML de prueba</div>

El contenido dentro del fence debe ser permitido como código literal.

En cambio, HTML escrito directamente fuera de un fence debería seguir siendo rechazado por readiness.

29. Lista con párrafos largos

Este es un elemento de lista bastante largo para observar qué sucede cuando el contenido ocupa más de una línea. La segunda línea debería mantener correctamente la sangría correspondiente al marcador.
Este es otro elemento extenso. Sirve para comprobar el interlineado, la justificación o alineación del texto dentro de listas y la relación entre el marcador y las siguientes líneas.

30. Énfasis dentro de listas

Elemento con negrita.
Elemento con cursiva.
Elemento con código.
Elemento con enlace.
Elemento con ~~tachado~~ si GFM funciona.

31. Numeración no consecutiva en source

Uno
Dos
Tres
Cuatro

Markdown normalmente debería producir una lista numerada secuencial aunque el source use 1. repetidamente.

32. Tabla más ancha

|---|---|---|---|---|---|---|

En móvil esta tabla debería poder desplazarse horizontalmente dentro de su propio contenedor sin provocar overflow de toda la página.

33. Párrafo después de tabla

Este párrafo sirve para comprobar que el flujo normal vuelve correctamente después de una tabla y que no queda atrapado dentro de su contenedor responsive.

34. Definición visual mediante negrita

Tradición. Una práctica transmitida y transformada a través del tiempo.

Archivo. Un mecanismo de conservación y consulta.

Interpretación. Una realización concreta de una obra o práctica.

35. Mezcla de elementos

Una pequeña sección

Este párrafo contiene negrita, cursiva, código y un enlace.

También contiene una cita.

Luego una lista:

una idea;
otra idea;
una tercera idea.

Y después una tabla:

| Pregunta | Respuesta |

|---|---|

| ¿Funciona Markdown? | Deberíamos saberlo después de esta prueba |

| ¿Funcionan tablas? | Depende de GFM |

| ¿Funcionan listas? | Deberían |

36. Prueba de caracteres que podrían confundirse con HTML

Estos caracteres están escritos como código inline y NO deberían interpretarse:

<c e g>

<div>

<script>

Dentro de un bloque de código tampoco:


<c e g>

<div>

<script>

Fuera de código, la política editorial debe continuar bloqueando HTML arbitrario.

37. Texto largo final

Una prueba editorial no solamente necesita comprobar si determinada sintaxis produce una etiqueta HTML. También necesita observar si el resultado continúa siendo agradable cuando todos estos recursos aparecen dentro de una misma publicación. El comportamiento de títulos, párrafos, listas, tablas, citas y bloques de código debe responder a una jerarquía consistente para que el lector no tenga que interpretar constantemente qué tipo de contenido está viendo.

La función del Markdown es precisamente separar la escritura de la presentación. El autor escribe estructuras relativamente sencillas y el sistema editorial decide después cómo representarlas. Si esta separación funciona correctamente, BME puede modificar su diseño en el futuro sin obligar a reescribir los artículos existentes.

Por eso esta prueba también sirve para confirmar una decisión arquitectónica: el contenido debe conservar una estructura semántica estable mientras la identidad visual pertenece a la capa de presentación.

38. Checklist visual final

Después de publicar esta página, comprobar:

Fin de la prueba

Si esta página representa correctamente todos los elementos anteriores, podemos considerar estable el soporte general de Markdown de Articles.

Los elementos que no funcionen deberían clasificarse en una de tres categorías:

Markdown básico no renderizado correctamente.
Extensiones GFM no habilitadas.
HTML correcto pero sin estilo CSS adecuado.

Con esa distinción podremos corregir únicamente lo que realmente falta.