Este episodio de Vergecast (maravillosamente titulado, por cierto) con John Gruber, el creador de Markdown (entre otras cosas), y el siempre interesante Anil Dash me lleva a hacer una entrada de esas de «señor mayor gritándole al sol», y es que debo ser el único ser humano al que Markdown no le parece una buena idea [en muchos de los casos en los que se usa actualmente].
(Markdown es un sistema para marcar texto ideado por Gruber para poder poner **negritas**, __cursivas__ y hacer otros cambios tipográficos sin morir en el intento en los inicios de la blogocosa, con el beneficio adicional de que, si se te muestra sin procesar, no se pierde gran cosa.)
La cuestión, claro, es que ahora el sistema se ha hecho más ubicuo que el agua (bueno, casi :-P). Markdown **era** necesario, y sigue siendo útil en algunos muchos casos (por ejemplo, para los que detestamos profundamente que en el correo haya cualquier cosa que no sea texto plano). Pero me alegra que hasta el propio Gruber esté de acuerdo conmigo en que en la actualidad se usa demasiado Markdown (somos dos, al menos, pero no sé yo si seremos muchísimos más de dos, y el mercado, claramente, mete Markdown hasta en la sopa sin que haya grandes protestas).
Gruber comenta cómo, hace mucho, muchísimo tiempo (en una galaxia muy muy lejana) para poner unas negritas había que recurrir a poner una etiqueta HTML escrita a mano, cosa que era cualquier cosa menos amigable (i) en ausencia de editores ni mínimamente adecuados y (ii) siendo el HTML un lenguaje maravilloso pero que no ganará ningún premio por lo compacto y que requiere millones de caracteres (o casi) para cualquier marcado. Y también comenta cómo el tema de los editores se ha resuelto bastante desde entonces y que ahora mismo escribir **esto** cuesta el mismo esfuerzo que pulsar una combinación de teclas para poner negritas (y quitarlas después). Y coincido con él. Pero.
Es la semántica, amigos.
En un texto moderno, estamos bastante acostumbrados a que dentro de un párrafo se destaquen textos con negritas y con cursiva. Nada nos impide cambiar el color del texto, o de su fondo, usar otra tipografía, o subrayarlo (bueno, esto último sí nos lo limita bastante la voluntad de que el texto continúe siendo legible, y por eso cuesta verlo más que en el caso de los enlaces), pero lo habitual son negritas y cursivas.
Pero la cantidad de significados que tienen esas negritas y cursivas es más que considerable: uno puede usar las cursivas para dar énfasis, pero también para referirnos a títulos de obras o poner extranjerismos, por ejemplo. Y las negritas se usan para dar un énfasis más fuerte que el de las cursivas, pero también lo he visto yo usado para marcas comerciales, por ejemplo. Nuestro cerebro, que es muy apañado, procesa y decide. Pero en este mundo nuestro, no debería ser demasiado complicado hacer explícita esa semántica. Y, es más, HTML lo permite bastante: tenemos elementos para dar énfasis (em y strong), pero también tenemos el elemento cite, el atributo lang o los pobres b e i, que ya no saben ni ellos para qué deberían usarse (y code, claro, como habéis podido comprobar, os hayáis dado cuenta o no, igual que os ha pasado con s hace un par de párrafos ;-)). Que em, cite e i se muestren por defecto en cursiva, que a strong y b les toque la negrita, que al pobre lang no suela hacerle caso nadie (qué poco habría costado que cualquier cosa marcada con un idioma diferente al del documento raíz se mostrase en cursiva por defecto, oiga) y que a code le toque una tipografía monoespaciada está bien (o no), pero nada nos impide elegir cualquier otra forma de formatear cada elemento. ¿Queréis los anglicismos resaltados en inglés? Feel free (pero yo no voy a hacerlo). Os dejo también que le cambiéis el aspecto a s, a del y hasta a ins, pero andad con cuidado, que es fácil hacerse daño. Con la tontería, sí que hay semántica en el marcado de texto de HTML, ¿eh?
¿Que quién se va a tomar la molestia? Pues somos pocos los que nos hemos tomado la molestia de instalar un plug in en WordPress para marcar el idioma de un fragmento sin tener que poner a mano un span lang="en"… pero haberlos haylos. Y si estas cosas viniesen por defecto, pues igual más gente lo haría, quién sabe.
¿Que qué ganamos? Tampoco tanto, cierto es… pero qué poco costaría y, en un mundo en que cada vez las máquinas nos hablan más, que el lector de pantalla no nos ponga énfasis en lo que es el título de una obra, o que sepa cambiar al idioma correcta para leernos una cita sin traducir de Shakespeare o de Molière, estaría bien, ¿no? Y, en cualquier caso, a un editor le cuesta lo mismo trabajar en Markdown que en HTML, y este último da más juego1.
Pues eso, que no es que andemos cortos de elementos semánticos. Y no debería costar mucho poder asignar teclas rápidas para las cosas que usemos más. Pero, en la práctica, la batalla está perdida con los editores de texto.
Y es que me da igual que hagáis ctrl+b o cmd+i para poner negritas y cursivas (¿De verdad me había olvidado de kbd? Imperdonable, lo sé.), que vuestros editores HTML os van a clavar un strong o un em, respectivamente, y se van a quedar tan anchos, a pesar del crimen de lesa semántica, y si se les confunde con un limitado editor de Markdown, pues qué se le va a hacer.
Más de mil palabras para básicamente quejarme de algo que ni es tan importante ni se va a solucionar. Profundamente señor, profundamente cincuentón, sí. Disculpen las molestias.
(Y todo esto, lo sé, sin hablar de LaTeX, que es muy presentacional para muchas cosas y del que no me quejo… pero porque no me han dado la ocasión. En mi mundo, las fórmulas matemáticas se escribirían en MathML semántico :-P.)
- Sí, es cierto: Markdown puede extenderse… pero si lo extiendes, vas a perder buena parte del espíritu original. ↩︎