MDN wants to learn about developers like you: https://qsurvey.mozilla.com/s3/MDN-dev-survey

Escribir HTML es fácil, pero ¿Qué pasa si algo va mal y desconocemos donde está el error de codificación? En este artículo veremos varias herramientas que nos ayudarán.

Prerrequisitos: Conocer HTML, ver Comenzando con HTML, Fundamentos de texto con HTML, and Creando hyperlinks.
Objetivo: Aprender el funcionamiento básico de las herramientas de depuración de problemas de código en HTML.

Depurar no debe asustarnos

Cuando escribimos cualquier tipo de código, normalmente todo va bien, hasta ese fatídico momento en el que ocurre un error — hemos hecho algo mal y el código no funciona — o no del todo, no lo suficientemente bien. Por ejemplo, el siguiente dibujo muestra un error de compilación compile de un programa sencillo escrito en lenguaje Rust.

A console window showing the result of trying to compile a rust program with a missing quote around a string in a print statement. The error message reported is error: unterminated double quote string.En el ejemplo, el mensaje de error es fácilmente comprensible — "unterminated double quote string"(comillas indeterminadas en el texto). Si miramos el listado de código, observamos que en println!(Hello, world!"); faltan una comillas. Pero, los mensajes de error pueden complicarse con facilidad y ser menos sencilla su interpretación a medida que los programas van creciendo en tamaño, siendo intimidatorios incluso casos sencillo para alguien que no sabe nada de Rust.

Así, la depuración no nos debe asustar —  la clave para sentirnos cómodos con la escritura y la depuración de cualquier lenguaje o código es la familiaridad — tanto con el lenguaje como con las herramientas.

HTML y depuración

HTML no es tan complicado de entender como Rust — HTML no se compila por separado antes de que el navegador lo analice (es interpretado, no compilado). Y la sintaxis de los elementos element de HTML es mucho más sencilla de entender que la de cualquier lenguaje de programación real como Rust, JavaScript o Python. La forma en que los navegadores ejecutan HTML es más permisiva que la de los otros lenguajes, cosa que es buena y mala a la vez.

Código permisivo

¿Qué queremos decir con permisivo? Bien, normalmente cuando hacemos algo mal al codificar, hay principalmente dos tipos de error:

  • Errores sintácticos: Son errores de escritura en el código que hacen que el programa no funcione, como el error en Rust de arriba. Son normalmente fáciles de arreglar si estamos familiarizados con las herramientas adecuadas y sabemos el significado de los mensajes de error.
  • Errores lógicos: En estos errores la sintaxis es correcta, pero el código no hace lo que debería, por lo que el programa funciona de forma incorrecta. Estos errores son, por lo general, más difíciles de solucionar que los sintácticos, pues no hay mensajes de error que nos avisen de los mismos.

HTML en sí mismo no suele producir errores sintácticos pues los navegadores son permisivos con estos, o sea, el código sigue ejecutándose aun ¡habiendo errores presentes! Los navegadores disponen de reglas internas para saber cómo interpretar incorrectamente los errores de escritura encontrados, por lo que seguirán funcionando aunque no produzcan el resultado esperado. Esto por supuesto puede también ser un problema.

Nota: La ejecución de HTML es permisiva porque cuando se creó la Web por primera vez, se decidió que permitir que la gente publicara su contenido era más importante que la sintaxis fuera totalmente correcta. La Web no sería tan popular como lo es hoy en día si se hubiera sido más estricto desde el primer momento.

Aprendizaje activo: Estudio del código permisivo

Es hora de estudiar la naturaleza permisiva del del código HTML por nosotros mismos.

  1. En primer lugar, hagamos una copia de nuestro ejemplo-demo a depurar y guardémoslo de forma local. Está escrito para producir varios errores para que los descubramos (El marcado de HTML se dice que está mal-formado, como contraposición a bien-formado).
  2. A continuación, abrámoslo en un navegador — veremos lo siguiente:A simple HTML document with a title of HTML debugging examples, and some information about common HTML errors, such as unclosed elements, badly nested elements, and unclosed attributes.
  3. No parece que esté bien; veamos el código fuente para ver qué podemos hacer (solo mostramos el contenido de <body>):
    <h1>HTML debugging examples</h1>
    
    <p>What causes errors in HTML?
    
    <ul>
      <li>Unclosed elements: If an element is <strong>not closed properly,
          then its effect can spread to areas you didn't intend
    
      <li>Badly nested elements: Nesting elements properly is also very important
          for code behaving correctly. <strong>strong <em>strong emphasised?</strong>
          what is this?</em>
    
      <li>Unclosed attributes: Another common source of HTML problems. Let's
          look at an example: <a href="https://www.mozilla.org/>link to Mozilla
          homepage</a>
    </ul>
  4. Veamos qué problemas podemos descubrir:
    • El elemento paragraph y el list item no tienen etiquetas de cierre. Si comprobamos el resultado, no parece que esto haya sido grave, pues es fácil deducir que donde un elemento acaba, otro debería comenzar.
    • El primer elemento <strong> no tiene etiqueta de cierre. Este resulta ser un poco más problemático pues no es fácil deducir donde se supone que termina el elemento. De hecho, se ha aplicado el énfasis fuerte al resto del texto.
    • Esta sección está mal anidada: <strong>strong <em>strong emphasised?</strong> what is this?</em>. No es fácil de explicar la forma en que ha sido interpretado, debido al problema anterior.
    • Al valor del atributo href le faltan las comillas de cierre. Esto parece haber causado el mayor problema — el enlace ha desaparecido totalmente.
  5. Ahora veamos lo que el navegador ha mostrado en contraposición al código fuente. Para ello podemos usar las herramientas de desarrollo del navegador. Para ello, si no estamos muy familiarizados con el uso de estas herramientas, echemos un rápido vistazo a Descubriendo las herramientas de desarrollo del navegador, y luego continuaremos.
  6. En el inspector de objetos (DOM), puedes comprobar la apariencia de cada elemento: The HTML inspector in Firefox, with our example's paragraph highlighted, showing the text "What causes errors in HTML?" Here you can see that the paragraph element has been closed by the browser.
  7. Usando el inspector DOM, vamos a explorar nuestro código en detalle para ver cómo ha arreglado el navegador nuestros errores de código HTML (lo hemos hecho con Firefox; otros navegadores modernos deberían producir el mismo resultado):
    • Se han añadido etiquetas de cierre a los párrafos y las lineas de las listas.
    • Al no estar claro el final del elemento <strong>, el navegador lo ha aplicado individualmente a todos los bloques siguientes de texto, a cada uno le ha añadido su propia etiqueta strong, desde donde está ¡hasta el final del documento!
    • El navegador ha arreglado el anidamiento incorrecto de la siguiente forma:
      <strong>strong
        <em>strong emphasised?</em>
      </strong>
      <em> what is this?</em>
    • El enlace a cuyo atributo le faltan las comillas del final ha sido ignorado. La última lista la ha dejado como sigue:
      <li>
        <strong>Unclosed attributes: Another common source of HTML problems.
        Let's look at an example: </strong>
      </li>

Validación HTML

Con el ejemplo anterior podemos asegurarnos de que nuestro HTML está bien-formado, pero ¿Cómo? En el siguiente ejemplo podemos comprobar que es bastante fácil buscar entre las líneas y encontrar los errores en documentos pequeños, pero ¿Qué pasa cuando trabajamos con documentos HTML enormes y complejos?

La mejor estrategia es comenzar por ejecutar tu página HTML en el Servicio de Validación de etiquetas — fué creado y es mantenido por el W3C, organización que se encarga de definir las especificaciones de HTML, CSS, y otras tecnologías web. Esta página web toma un documento HTML como entrada, lo procesa, y produce un informe de donde están los errores en el documento.

The HTML validator homepage

Para validar el HTML, le podemos proporcionar una dirección web donde apuntar, subirle un archivo HTML, o directamente ingresarle el código HTML a revisar.

Aprendizaje activo: Validación de un documento HTML

Vamos a probar validando nuestro documento ejemplo.

  1. Primero, carguemos el Servicio de Validación en una pestaña del navegador, si no la tenemos ya.
  2. Click en la sub-pestaña Validate by Direct Input.
  3. Copiar el código del documento ejemplo (no solo el cuerpo) y peguémoslo en el recuadro de texto grande.
  4. Click en botón Check.

Esto debería producir una lista de errores y otras informaciones:

A list of of HTML validation results from the W3C markup validation service

Interpretación de los mensajes de error

La lista de mensajes de error que nos presenta el validador suele ayudar a veces, pero otras veces no; con un poco de práctica aprenderemos a interpretar la lista para arreglar nuestro código. Veamos los mensajes de error y su significado. Observamos que cada mensaje se presenta con un número de línea y de columna, para ayudar a localizar el error más fácilmente.

  • End tag li implied, but there were open elements (2 instances): Estos mensajes indican que un elemento que ha sido abierto debe ser cerrado. La etiqueta de cierre se supone, pero no está ahí. La información de la línea/columna apunta a la primera línea después de donde debería estar la etiqueta de cierre, es una buena pista para ver qué pasa.
  • Unclosed element strong: Un elemento <strong> no ha sido cerrado, y la línea/columna apunta directamente al lugar del error.
  • End tag strong violates nesting rules: Este apunta a elementos incorrectamente anidados, y línea/columna nos indica donde están.
  • End of file reached when inside an attribute value. Ignoring tag: Esta es bastante enigmática; se refiere al hecho de que el valor de un atributo no ha sido bien construido, posiblemente cerca del final del archivo pues el final aparece dentro del valor del atributo. El hecho de que el navegador no muestre el link nos debería dar una buena pista de qué elemento es el erróneo.
  • End of file seen and there were open elements: Este es un poco ambiguo, pero básicamente se refiere al hecho de que hay abiertos elementos que necesitan ser cerrados adecuadamente. Los números de línea apuntan a las últimas líneas del archivo, y este mensaje de error viene con una línea de código que indica un ejemplo de un elemento abierto:
    example: <a href="https://www.mozilla.org/>link to Mozilla homepage</a> ↩ </ul>↩ </body>↩</html>

    Nota: Un atributo al que le falten las comillas de cierre puede ser un elemento abierto, pues el resto del documento será interpretado como si fuera parte de este atributo.

  • Unclosed element ul: Este no ayuda mucho, pues el elemento <ul> está cerrado correctamente. Este error es debido a que el elemento <a> no ha sido cerrado, ya que faltan las comillas de cierre.

No debemos preocuparnos si no podemos corregir todos los mensajes de error  — es práctico tratar de arreglar unos pocos errores cada vez y volver a pasar el validador para ver los que quedan. A veces, al arreglar unos cuantos se arreglan automáticamente otros muchos mensajes — con frecuencia muchos errores son causados por uno solo en un efecto dominó.

Sabremos  que todos los errores están arreglados cuando veamos el siguiente mensaje:

Banner that reads "The document validates according to the specified schema(s) and to additional constraints checked by the validator."

Resumen

Pues hasta aquí una introducción al depurado de HTML, esta nos proporcionará habilidades para cuando comencemos a depurar CSS, JavaScript y otros lenguajes más adelante en nuestros trabajos. Este apartado también constituye el final de la introducción al módulo de artículos de aprendizaje de HTML — ahora podemos hacer los test de prueba: el primero de los cuales está en el siguiente link.

Etiquetas y colaboradores del documento

 Colaboradores en esta página: javierpolit
 Última actualización por: javierpolit,