Markdown, la mejor opción para crear contenidos web

Públicado el sáb 02 abril 2011

Normalmente cuando se crea contenido en un blog o CMS, como Wordpress, Blogger, Drupal, Joomla, Plone, Typo, etc, se hace a través de un editor visual (WYSIWYG). Algunos editores de este tipo son TinyMCE, CKeditor, NicEdit, WYMEditor, markItUP!, openWYSIWYG, etc.

Yo mismo he empleado varios de ellos durante años, en varias plataformas como Blogger, Wordpress, Joomla, Drupal, etc. Y si, hay que reconocerlo, te hacen la vida muy fácil, sobre todo para aquellos que no quieran preocuparse más que de añadir contenido en su página. E incluso usuarios más avanzados como administradores o diseñadores web, lo suelen emplear por comodidad frente a un área de texto plano. Y si, es cómodo, muy cómodo, a corto plazo. A largo plazo... a largo plazo es cuando empiezas a verle los peros y los problemas, que los tienen, y bastantes. Veamos cuales son esos problemas y la alternativa, que para mi personalmente, es la solución.

Los problemas de los editores WYSIWYG

Los editores visuales están pensados para que de una forma muy fácil, se pueda editar el contenido de forma visualmente atractiva, sin tenerse que andar preocupando del HTML que se genera a partir de él, esto es, no es necesario conocer nada de HTML para usar un editor WYSIWYG. Puedes añadir negritas, cursivas, alinear el texto, cambiar el tamaño, el color, crear tablas, etc, sin conocimiento alguno de HTML o CSS. Se supone que el editor genera HTML valido correctamente por ti. Y aquí es donde empiezan los problemas:

  • Los editores visuales generalmente crean el formato con CSS embebido dentro del HTMl, es decir mezclando el contenido y el estilo de la página. Algunos incluso te permiten incluir tus propias hojas de estilo para que el contenido se ajuste al estilo actual de tu web.

    ¿Pero que ocurre cuando al cabo de un tiempo, con decenas o más de artículos generados quieres cambiar el estilo de tú página? Pues dependiendo de como haya realizado el trabajo tu editor WYSIWYG, te puedes encontrar con el desagradable problema de que todo queda desencajado o no se ajusta al estilo actual. Yo me he tenido que enfrentar con este problema en el pasado al actualizar una versión de Drupal y cambiar completamente el tema, y no fue nada cómodo de solucionar, o al importar contenido de un CMS a otro.

  • Los editores visuales se crearon inicialmente para impresión en papel, no para HTML. Y HTML se emplea en multitud de dispositivos (desde móviles hasta ereaders) y bien empleado proporciona una flexibilidad que se rompe al mezclar la estructura del documento (HTML) con el estilo del mismo (CSS) en el mismo archivo. Así que a la hora de crear versiones para dispositivos móviles, con todas esas etiquetas CSS embebidas, puede ser un verdadero quebradero de cabeza.

  • Se supone que tienen que generar HTML válido, pero durante mucho tiempo esto no ha sido siempre así, sobre todo si el editor no está bien configurado o tiene algún plug-in que no respeta este tema. Además, generan HTML valido ahora, ¿que pasa en el futuro? Es decir, si quieres pasar contenido antiguo para por ejemplo pasar de HTML 2.0 a HTML 4.0 o incluso 5 y eliminar etiquetas obsoletas y generar HTML que cumpla con el estándar, prepárate, porque te espera una ardua tarea. Por no decir que muchos de estos editores tienen errores en su propio código javascript, lo que lleva a frecuentes actualizaciones de los mismos.

  • Pueden generar cantidades absurdas de HTML, sobre todo si no están correctamente configurados. Algunos editores (a veces con la configuración por defecto hacen esto, y tienes que ser tú quien lo ajuste para que no ocurra) crean toneladas de <div>,<p> y <span> sin sentido y totalmente superfluos. Cuando no emplean tablas para formatear algunas presentaciones complejas. Y ni que decir tiene de aquellos editores visuales que te dejan pegar contenido desde un procesador de textos como Word, el HTML generado en estos casos, bueno, hay que verlo para creerlo, un absoluto despropósito.

  • Es incluso factible que un usuario inexperto pueda romper el diseño de una página a través de un editor WYSIWYG, creando párrafos o <div> de forma inadecuada. Incluso al reescribir un texto es posible que se mezclen estilos CSS embebidos antiguos con nuevos, generando unos embrollos inmensos a nivel de HTML. Y ya no digo nada de los que rompen el estilo visual de un tema abusando de colores en las fuentes, tamaños, etc

  • El contenido que se guarda en la base de datos esta mezclado con las etiquetas HTML y CSS, todo junto, vamos que no se parece en nada a lo que has introducido en tu editor. Todo esto en principio carece de importancia, pero puede suponer hasta el 20% del tamaño de las páginas de tu sitio, espacio absurdamente desperdiciado en tu BDD. De hecho el contenido XHTML se genera por lo normal cada vez que se visualiza la página de forma dinámica. Si te preocupa el rendimiento, tranquilo, los sistemas de cache están ahí para echarte una mano y que te dejes de preocupar por eso.

  • Distraen la atención, el problema de absolutamente todos los editores visuales, incluidos procesadores de texto, el centrarse en el formato y no en el contenido. Una gran mayoría de usuarios desperdicia un tiempo notable preocupándose por más el aspecto visual del documento, que por el contenido del mismo. Que si esto en negrita, que si mejor con esta fuente, que si mejor con la otra... Se desvía la atención de lo importante, el contenido. Mal amigo de la productividad, se tarda bastante más en general, por esta razón, en generar el mismo contenido en un editor WYSIWYG.

  • Son bastante poco flexibles, si quieres introducir tu propio HTMl en el contenido (e.g. para tener un control más fino sobre las tablas, yo lo hago en este articulo) puede que te encuentres que lo genera como lo tiene preestablecido, eliminado la estructura que tu quieras darle. Y embeber contenido multimedia o scripts también es frecuentemente un problema, siendo hasta habitual que existan plugins para estos editores para insertar contenidos de sitios como YouTube.

  • Todos los editores WYSIWYG aumentan el peso por página y disminuyen la velocidad de carga, al necesitar pesado código javascipt que necesita tanto ser descargado como ejecutado por tu navegador. Ya de por si los CMS suelen emplear bastante código javascript, como para encima añadirle un editor visual. Además realizan bastantes llamadas HTTP, ralentizando aún más la velocidad de carga. Ejemplo: tienes un articulo de 80 lineas de texto cuyo contenido XHTML puede pesar tranquilamente de 10 á 20 veces menos que el javascript del editor, ¿no es un poco ridículo?. Aunque muy pocos editores web se preocupan de esto, la verdad, es que hay que pensar que no todo el mundo disfruta de buenas conexiones a la red.

  • Por último y no menos importante, no cuidan la accesibilidad. El HTML valido que cumpla con los estándares, es esencial para crear páginas con una buena accesibilidad, pensando en aquellos que no lo tienen tan fácil para navegar por nuestros sitios web. Deberían tenerse al menos en cuenta un mínimo de puntos sobre este tema al crear contenidos en la web.

En conclusión, que los editores WYSIWYG pueden no dar problemas hasta que tus necesidades cambian, entonces pueden darte más de un quebradero de cabeza.


Texto plano y Markdown

¿Cual sería entonces la solución para esquivar estos problemas? Texto plano, nada más, que se transforme automáticamente en HTML valido respetando el formato que nosotros queramos darle. Esto existe, y es posible gracias a los lenguajes de marcado ligero, entre los que se encuentra Markdown. Nada mejor que empezar demostrándolo con un ejemplo:

MarkdownResultado

Documento de ejemplo ====================

Lorem ipsum [dolor sit amet](#mark), consectetur adipiscing elit. Curabitur eget ante nunc. Pellentesque a tortor ipsum, id rhoncus orci. Quisque leo sapien, rutrum id convallis id, rutrum in ligula. Vestibulum **semper adipiscing leo** et blandit.

Sed nibh quam, hendrerit _sit amet aliquam_ vel, pulvinar molestie augue.

> Integer cursus, nunc eu ultrices pellentesque, eros leo malesuada turpis, vel convallis neque dolor a nunc. Sed lacus risus, condimentum vitae posuere quis, ultrices pharetra nunc.

Lista numerada (ordenada)

1. Este es el primer elemento 2. Este es el segundo elemento * Una lista de puntos anidada * Se llama también desordenada * Tercer nivel de anidamiento 3. Este es el tercer elemento

![avatar](pictures/avatar.png)

### Cabecera ###

- - -

Morbi erat augue, feugiat eu pellentesque eget, hendrerit quis lectus. Fusce dignissim pretium nibh sed dignissim. Pellentesque lobortis ante eu dui fermentum vitae blandit risus aliquet.

| | solo texto | HTML Limpio | | -------------- | -- | ------- | | Markdown | Si | Si | | Editor WYSISWG | X | A veces |

    :::python     import lifetime          for each_day in lifetime.days():         carpe_diem()

Suspendisse posuere velit et velit vehicula at scelerisque orci suscipit. Nulla facilisis lorem eu sem viverra varius nec ut felis.

Esto es un texto con nota al pie [^prima] y esta es otra nota [^secunda]

*[vehicula]: automobila [^prima]: Esto es una nota al pie. [^secunda]: Esto es la segunda nota.

Documento de ejemplo

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Curabitur eget ante nunc. Pellentesque a tortor ipsum, id rhoncus orci. Quisque leo sapien, rutrum id convallis id, rutrum in ligula. Vestibulum semper adipiscing leo et blandit.

Sed nibh quam, hendrerit sit amet aliquam vel, pulvinar molestie augue.

Integer cursus, nunc eu ultrices pellentesque, eros leo malesuada turpis, vel convallis neque dolor a nunc. Sed lacus risus, condimentum vitae posuere quis, ultrices pharetra nunc.

Lista numerada (ordenada)

  1. Este es el primer elemento
  2. Este es el segundo elemento
    • Una lista de puntos anidada
    • Se llama también desordenada
      • Tercer nivel de anidamiento
  3. Este es el tercer elemento

avatar

Cabecera


Morbi erat augue, feugiat eu pellentesque eget, hendrerit quis lectus. Fusce dignissim pretium nibh sed dignissim. Pellentesque lobortis ante eu dui fermentum vitae blandit risus aliquet.

solo texto HTML Limpio
Markdown Si Si
Editor WYSISWG X A veces
import lifetime

for each_day in lifetime.days(): carpe_diem()

Suspendisse posuere velit et velit vehicula at scelerisque orci suscipit. Nulla facilisis lorem eu sem viverra varius nec ut felis.

Esto es un texto con nota al pie 1 y esta es otra nota 2


  1. Esto es una nota al pie.

  2. Esto es la segunda nota.

Es así de sencillo, el texto plano que se escribe en la columna de la izquierda genera el HTML que se puede ver representado en la derecha. Es además HTML valido, sin CSS embebido (exceptuando el código con resaltado de sintaxis, pero esto es necesario y tampoco es generado por Markdown si no por GeSHi anteriormente y ahora por Pygments) y empleando el mínimo necesario, siendo lo más limpio posible. Pero el contenido que se guarda en la base de datos y el que tú editas es el de la izquierda. Este contenido generará HTML valido hoy y mañana, es totalmente independiente del estilo que emplees en tu página y puedes migrarlo de un CMS a otro sin problema alguno. Todo son ventajas, el único inconveniente es que tienes que aprender a usar Markdown, algo que es sumamente sencillo, a la par que incrementa la legibilidad del texto plano.

La legibilidad del texto es uno de los pilares fundamentales de Markdown, tal y como el mismo autor, John Gruber, lo cuenta1:

El objetivo fundamental de diseño para la sintaxis de Markdown es hacerlo tan legible como sea posible. La idea es que un documento formateado con Markdown debería poder ser publicado tal y como está, como texto plano, sin que parezca que ha sido marcado con etiquetas o instrucciones de formateado. Mientras que la sintaxis de Markdown ha sido influenciada por muchos filtros texto-a-HTML existentes, la principal fuente de inspiración es el formato de los correos electronicos en texto plano.

No voy ahora, en este articulo, a enseñarte a emplear Markdown, pero tienes una guía de prácticamente todas las posibilidades que te brinda en Markdown & Pygments Lexers Cheat Sheet. Además, si somos así de vagos, podemos emplear también algunos editores visuales que generan y emplean markdown, como markItUP! o el conocido WMD que empleamos en python majibu. Aunque ambos editores solo soportan Markdown estándar, cuando en este sitio también soporto las capacidades adicionales de Markdown Extra.

Todo el contenido de este sitio (exceptuando el automático, como las búsquedas, etiquetas, acerca de, ...) está generado empleando Markdown y todo está en HTML 5 valido. Un ejemplo del HTML que genera Markdown sería el siguiente:

MarkdownHTML
Documento de ejemplo
====================

Lorem ipsum [dolor sit amet](#mark), consectetur adipiscing elit. Curabitur eget ante nunc. Pellentesque a tortor ipsum, id rhoncus orci. Quisque leo sapien, rutrum id convallis id, rutrum in ligula. Vestibulum **semper adipiscing leo** et blandit.

Sed nibh quam, hendrerit _sit amet aliquam_ vel, pulvinar molestie augue.
    
<h1>Documento de ejemplo</h1>

<p>Lorem ipsum <a href="#mark">dolor sit amet</a>, consectetur adipiscing elit. Curabitur eget ante nunc. Pellentesque a tortor ipsum, id rhoncus orci. Quisque leo sapien, rutrum id convallis id, rutrum in ligula. Vestibulum <strong>semper adipiscing leo</strong> et blandit.</p>

<p>Sed nibh quam, hendrerit <em>sit amet aliquam</em> vel, pulvinar molestie augue.</p>
     

Como se puede ver es el HTMl justo, limpio y cumpliendo estándares, ni más ni menos. Este es un ejemplo muy sencillo, y posiblemente cualquier editor WYSIWYG sea capaz de dar el mismo resultado, el problema aparece con documentos más complejos, con sucesivas re-ediciones del texto y con editores mal configurados. Eso si, lo que se almacena en la BDD con Markdown es texto plano, con los otros editores, el texto, las etiquetas HTML y CSS embebido.

¿Porque Markdown y no otros?

Evidentemente Markdown no es el único lenguaje de marcado ligero, existen otros también conocidos y extendidos como Textile, BBCode, reStructuredText, Texy!, Txt2tags o los empleados en los Wikis como Creole o el de MediaWiki.

En primer lugar Markdown es uno de los que más características soporta, uno de los que más salidas puede generar (no solo HTML, también LaTeX, RTF, PDF, EPUB, ...) y además es probablemente el más extendido y soportado de todos (exceptuando BBCode y los de los Wikis, empleados en sus nichos particulares). Pero también es uno de los más fáciles de emplear (saliendo del formato básico como negritas, etc) y que produce un texto plano más vistoso y legible.

Comparativa

Como no, lo mejor, es ver una comparativa con un ejemplo del mismo documento y el texto empleado por cada uno de los lenguajes para generarlo. Para ello he creado un articulo aparte para mostrarla.

Comparativa

¿Quién emplea Markdown?

Una de las razones para emplear Markdown es porque es uno de los más extendidos, sobre todo en el mundo de la programación. Por ejemplo, Stack Overflow y todos los sitios de Stack Exchange emplean una variante de Markdown para la entrada de texto. Repositorios de código como GitHub y Bitbucket también lo emplean para ciertas funciones. También lo emplea el sistema de seguimiento de incidencias LightHouse.

Fuera del ámbito de la programación, sitios tan conocidos como Reddit lo emplean. Plataformas para la educación online como Moodle o Podmedics también hacen uso de él. Un Wiki como Instiki permite emplear Markdown. Plataformas de blogs y contenidos como Posterous, Tumblr y Squarespace lo ofrecen como opción. Y seguro que me estoy dejando en el tintero muchos más lugares donde es empleado habitualmente.

Hay que tener en cuenta de que aquí no he hablado de software CMS que lo soporta, eso lo contemplo en el próximo punto, si no más bien de organizaciones/compañías.

Excusas para no emplearlo

La primera que dice todo el mundo, es un incordio usarlo y aprenderlo, la pregunta es: ¿Has intentado emplearlo? Créeme se aprende en nada, sobre la marcha, y una vez que te acostumbras a él, lo elegirás frente a los editores WYSIWYG, casi con toda seguridad. Una vez aprendido no tienes que separar los dedos de tu teclado, no necesitas para nada el ratón para crear tu contenido. Ganarás mucho tiempo para ti mismo y lo agredeceras, créeme.

La segunda, no puedo usarlo en mi CMS o blog. ¿Seguro? A continuación te detallo las opciones que conozco para publicar contenidos empleando Markdown.

CMS y Blogs:

Generadores de sitios con contenido estático (HTML):

Plataforma de Blogs con contenido estático (HTML):

  • Calepin.co es un Pelican hospedado, que lee ficheros markdown desde DropBox

Wiki:

Foros:

Conversor Markdown desde/a otros formatos:

Editores de Texto que lo soportan (marcado de sintaxis):

Editor Markdown:

Editor Offline para blogs:

Editores Online para probar Markdown:

Y si eres desarrollador, tienes disponibles distintas implementaciones de Markdown:

Lenguaje Implementaciones
Python Python-markdown
PHP PHP Markdown y PHP Markdown Extra
Perl Original y MultiMarkdown
Ruby BlueCloth, Maruku y Kramdown
C# Markdown.NET
C Discount y Peg-Markdown
C++ Cpp-markdown
Java MarkdownJ
Javascript Showdown
Lua markdown.lua
Haskell Pandoc
Common Lisp CL-Markdown
Scala Knockoff y Actuarius

Entonces, habiendo tantas opciones, ¿por qué no lo pruebas?

Y si hay más excusas, pues la verdad, no las conozco, dímelas tú.


  1. The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. While Markdown’s syntax has been influenced by several existing text-to-HTML filters, the single biggest source of inspiration for Markdown’s syntax is the format of plain text email. fuente 

Etiquetado como: markdown, wysiwyg, textile, editores, marcado, html, xhtml.

Comentarios !