Los “heading” y la creación de TOCs en las BBPP LARdT 1.0 (“Buenas Prácticas de LARdT para un ePUB decente”) (Cap. 08)

Las etiquetas “heading” (h1, h2, h3,…) se usan muy frecuentemente en HTML porque dado que jerarquizan el contenido y a la vez suelen tener vinculados formatos de estilo (con tamaño de fuentes creciente, negrita, subrayados, etc..) resultan muy prácticas. Es lo que se llama “marcado semántico”: algo etiquetado como <h1> siempre será más visible que lo que esté etiquetado como <h2>.
Dada esta prevalencia en HTML parece natural que su uso se extienda también al XHTML de los ePUB. Y aquí es donde merece la pena realizar un comentario.

Un uso disperso
Todos los que componemos libros en ePUB usamos los headings. Y de forma distinta, lo cual a veces resulta problemático. Las BBPP LARdT 1.0 también contienen su propio criterio de aplicación, como no. Al menos tiene la ventaja de ser siempre idéntico. Por eso, he pensado que no estaría mal que fuera generalizándose un uso un poco más uniforme de los “headings”, es decir, unas “buenas prácticas”. 

Los headings en las BBPP LARdT 1.0
El criterio de los headings en las BBPP LARdT 1.0 es como sigue:
”h1” – Reservado para el nombre de Autor.
”h2” – Reservado para el título del libro.
”h3” – Primer nivel (mayor) jerárquico existente en la estructura del libro. Si existe la división en “Libro”, “Tomo”, “Parte”, etc… se le aplica este heading. Si no existen subdivisiones mayores entonces se aplica a los capítulos.
”h4” – Segundo nivel jerárquico en la estructura del libro; que según lo expuesto para el nivel de heading anterior se aplicara al “capítulo” o a los “subcapítulos”.
”h5” – Tercer nivel jerárquico. Para las subdivisiones inferiores. Si fuera necesario, esta estructura puede ampliarse hasta el infinito “h6”, “h7”,… pero lo cierto es que no he encontrado un libro que necesite más de 3 niveles jerárquicos de organización.
Y por último, recalcar que no se utilizan los “headings” para ningún otro contenido que no tenga que ver con la estructura y división jerárquica del libro.

Así los usos más frecuentes son:
“h3” – Parte, “Libro”, “Tomo”
   “h4” – “Capítulo”
       “h5” – “Subcapítulo”
ó bien
”h3” – “Capítulo”
     “h4” – “Subcapítulo”

¿Por qué no utilizamos “h1” y “h2” para las partes del libro? Pues simplemente porque cuando empezamos a trabajar con los libros en ePUB utilizábamos el programa de edición SIGIL y este seguía la practica de reservar los dos primeros niveles de heading para envolver el nombre del autor y el título del libro en la portada. Lo que envolvieras entre etiquetas <h1></h1> se incorporaba de forma automática como nombre del autor en los metadatos del libro; y lo mismo ocurría con  <h2>título</h2>.
Así empezamos y luego hemos seguido haciéndolo así. Si los libros tuvieran generalmente muchos subniveles a lo mejor hubiéramos abandonado esta práctica, pero como ya he dicho, normalmente 2 ò 3 niveles son suficientes para expresar la estructura de un libro.
Pero lo bueno del caso es que de este hecho “histórico” más o menos fortuito se ha derivado una consecuencia bastante interesante.

Generar la TOC del libro a partir de los “heading” 
Resulta que SIGIL sigue la convención propia de los programas de tratamiento de texto (Word, OpenOffice) de generar la TOC (tabla de contenido –índice-) automáticamente a partir de la estructura de “headings” del texto. Evidentemente, el programa permite editar y modificar a gusto del usuario la TOC generada automáticamente. Y es lógico que lo haga porque, en principio, una de las características propias del formato ePUB es la posibilidad (en realidad, la obligatoriedad) de crear la TOC del libro. Hasta aquí todo correcto: uno compone el libro, el editor te ayuda generando la TOC automáticamente a partir de las etiquetas “heading” y luego uno hace el ajuste que le parece más conveniente. El libro ePUB queda con su TOC a medida y  todos contentos.

Las sorpresas de ADOBE MOBILE READER
Pero resulta que en este mundo cruel de los libros electrónicos nada es lo que parece. Resulta que hemos encontrado que algunas implementaciones del programa más extendido para la lectura de ePUB, el ADOBE MOBILE READER (es decir, la contraparte e-book del ADOBE DIGITAL EDITIONS de tu PC); en vez de utilizar la TOC incrustada en el ePUB siguen la misma práctica que Word; es decir CREAN LA TOC A PARTIR DE LAS ETIQUETAS HEADING existentes en el texto.
El problema que aparece es que si utilizas expresiones “heading”, por ejemplo, para separadores del texto del tipo de las típicas estrellitas…

<h5>* * *</h5>

…te puedes encontrar con que el TOC de tu libro aparece así:








o así;





lo que no es plan, vamos.


Así pues, la práctica que adoptamos un poco por casualidad, por fortuna luego ha resultado bastante útil.


Recapitulando: Aunque en teoría no debería ser así, resulta conveniente utilizar la etiqueta “Heading” sólo y únicamente para aquellos contenidos que se desee que aparezcan en la TOC.




¿Y por qué utilizar una ”escala móvil” en lugar de una fija?


Dejando aparte toda esta incidencia del ADOBE MOBILE READER, también me han preguntado porqué no asocio los niveles de “heading” a subdivisiones fijas del libro. Es decir, por ejemplo y empezando en <h3> (“escala fija”):


”h3” - siempre para 

Capítulos

”h4” - siempre para Subcapítulos


”h5” – siempre para divisiones dentro de capítulos o subcapítulos


”h6” – Subtítulos


”h7” – siempre para cualquier otra división de menos importancia.

Nota: a efectos de este ejemplo, es trivial empezar en h1 o en h3.





Sin embargo en las BBPP LARdT 1.0 como los distintos niveles de heading se asocian de mayor a menor con las subdivisiones existentes en cada libro, los capítulos unas veces serán <h3> y otras <h4> dependiendo si existe un nivel de división por encima (tipo “Libro”, “Parte”, “Tomo”,…) o no.


Yo soy partidario de este tipo de “escala móvil” porque me parece que es mucho más fácil el que todos coincidamos en que un libro tiene 2,3, ó n niveles de división; a que coincidamos en la definición de “subcapítulo”, “subtítulo” etc…


Tampoco me parece conveniente el que la numeración de los “headings” tenga “huecos”; en el ejemplo anterior de escala fija un libro podría no tener “h5” (no hay subdivisiones en los capítulos) y si “h6” (subtítulos); dependiendo además de cómo se defina cada parte.





Por todos estos motivos, las BBPP LARdT 1.0 utilizan los “headings” para etiquetar:


- únicamente los contenidos que deben aparecer en el TOC

- asociando cada nivel de forma biunívoca y de mayor a menor a los distintos niveles de división y organización (partes); de forma correlativa (sin huecos) y empezando en <h3>


- respetando el concepto de etiquetado semántico: <h1> siempre será más visible (fuente de mayor tamaño, negrita, etc..) que <h2>; <h2> será más visible que <h3>; y así sucesivamente.


- <h1> y <h2> en realidad quedan sin uso porque el nombre de autor y el título del libro; ya están suficientemente gestionados e identificados con su inclusión en los metadatos del libro.

En cualquier caso, como ya sabéis los que seguís este BLOG, esto son las BBPP LARdT 1.0 y no las tablas de la ley. Son completamente opinables y, seguramente, mejorables. Espero abrir el debate.

Para terminar, este POST ha sido inspirado por una interesante discusión vía mail con Javier Maray al que podéis considerar como co-autor (¡aunque a lo mejor no coincidimos en todo!).