Formateador de HTML

La mayoría del HTML tolera que un formateador reorganice sus espacios en blanco libremente — indentación adicional entre elementos de bloque como `<div>` y `<p>` no tiene ningún efecto visible, porque los navegadores colapsan las secuencias de espacios en blanco entre esos elementos al renderizar. Tres casos específicos rompen esa suposición por completo: el contenido dentro de `<pre>` renderiza cada espacio y salto de línea literalmente, exactamente como está escrito; `<textarea>` trata su contenido de la misma forma ya que está pensado para reproducir texto exacto editable por el usuario; y cualquier elemento que lleve `white-space: pre` en CSS hereda el mismo tratamiento literal. Un formateador que reorganiza los espacios en blanco dentro de cualquiera de esos bloques cambia lo que la página realmente muestra, no solo cómo se ve el código fuente — por eso este formateador los deja completamente intactos en lugar de aplicar sus reglas habituales de indentación.

Los elementos en línea situados directamente junto a texto son un caso más sutil: un espacio entre dos elementos en línea a veces es visualmente significativo — el espacio entre dos palabras que abarcan etiquetas `<span>` separadas, por ejemplo — así que el formateador es deliberadamente conservador con el contenido en línea, prefiriendo dejar el espacio en blanco ambiguo tal cual en lugar de arriesgarse a colapsar un espacio que estaba haciendo un trabajo visual real.

Una página ensamblada como un solo archivo HTML comúnmente incrusta su propio CSS dentro de un bloque `<style>` y su propio JavaScript dentro de un bloque `<script>`, y un formateador que solo entiende etiquetas HTML dejaría ese código incrustado como un bloque sin formatear o, peor, lo estropearía tratando las llaves y puntos y coma como sintaxis HTML. Entregar el contenido de esos bloques a un analizador CSS real y un analizador JavaScript real respectivamente significa que todo el archivo — marcado, estilos y comportamiento juntos — vuelve formateado de forma consistente, en lugar de solo la estructura HTML externa.

Los navegadores están construidos con un modelo de recuperación de errores diseñado específicamente para renderizar algo razonable incluso a partir de marcado gravemente malformado — una etiqueta sin cerrar, una comilla faltante, elementos anidados en un orden inválido — porque la web tiene décadas de HTML imperfecto en producción que todavía necesita mostrarse. Un formateador no puede adoptar esa misma indulgencia: para reformatear un documento tiene que construir una comprensión estructural precisa de qué está anidado dentro de qué, y un documento con etiquetas genuinamente desbalanceadas no tiene una única estructura correcta que recuperar. Por eso una página que se muestra completamente normal en un navegador puede seguir siendo rechazada por este formateador — el navegador reparó silenciosamente la ambigüedad a su manera, mientras una herramienta que intenta reformatear correctamente tiene que señalar la ambigüedad en lugar de adivinar.

Un archivo que falla al formatear muy a menudo no es HTML roto en absoluto, sino una plantilla — Handlebars, Jinja, Blade, EJS o similar — que mezcla directivas de plantilla con marcado, produciendo un documento que no es HTML independiente válido por sí mismo y que nunca necesita serlo. La plantilla solo se convierte en HTML real y bien formado después de que su motor de plantillas se ejecuta y sustituye los datos reales. Formatear la salida renderizada, capturada después de que el motor de plantillas la procesa — desde el "Ver código fuente" de un navegador, por ejemplo — evita esto por completo, ya que esa salida es HTML real sin ninguna sintaxis de plantilla restante.