¡Libertad, Igualdad, Validez!

Como una nación o una casa, una página incorrectamente construida no puede mantenerse en pie, no al menos en los navegadores que cumplen los estándares. Cada página tiene una estructura, y si no se es cuidadoso con los métodos utilizados para construirla, la estructura estará dañada, será fragil y potencialmente peligrosa. Si carga una página en Firefox, Opera o Konqueror y se visualiza mal, es probable que sin darse cuenta haya construido una estructura inestable.

Imagínese construir una casa con cimientos asentados sobre arena, o con columnas de goma. La mayoría no lo haría, y quien lo hiciera no se sorprendería al ver grietas en las paredes, irregularidades en el suelo, o incluso el derrumbe de la estructura. Y aún con todo, muchos autores descubren estupefactos que sus páginas se visualizan incorrectamente en navegadores modernos. La reacción habitual es "¡Antes la página se veia bien!" lo cuál es como decir "Mi casa de columnas de goma no se derrumbó nada más construirla!" Quizás no, puede que sólo estuviera a punto de hacerlo.

Por tanto, ¿cómo podemos garantizar un buen y sólido sitio Web? Con código de marcado bien estructurado. Una estructura de documento limpia es absolutamente esencial para asegurarse de que sus páginas se comportarán correctamente en los navegadores actuales y futuros. ¡Afortunadamente, arreglar la estructura de las páginas una vez hechas es más fácil y barato que intentar corregir los defectos estructurales de una casa! De hecho, hay validadores de HTML que ayudan a identificar los problemas y corregirlos rápidamente. Le recomendamos El validador de HTML del W3C, no solo porque es mantenido por la misma gente que es responsable de las especificaciones de HTML y XHTML, sino que además, la mayoría de los mensajes de error proporcionan un enlace a una explicación de su significado. Puede que usted entienda los mensajes de error sin necesidad de leer la explicación, pero para un principiante estos textos de ayuda son muy útiles.

La meta

El objetivo es simple: que su página no genere ningún error. Si usted aspira a más, podría intentar eliminar también las advertencias, pero lo importante es evitar tener errores. En la práctica hay dos clases de errores:

• Alertas sobre elementos, son el problema más serio y realmente pueden estropear una página si no se corrigen. Por ejemplo, un error "element 'TD' not allowed here", significa que usted tiene un 'TD' fuera de un elemento 'TABLE', o bien el Validador piensa que lo tiene. De cualquier modo, es un problema importante, y descubrir la causa debe ser prioritario. Un error en un elemento es equivalente a un constructor que le dice que en su casa hay un pilar torcido.

• Alertas sobre atributos, son menos graves, puesto que la mayoría de los navegadores ignorarán los atributos que no entiendan. Esto no quiere decir que los errores en los atributos puedan ser ignorados, sino que por lo general son menos preocupantes que los errores en los elementos.

Al corregir el código para eliminar un error, puede descubrir que ha generado otros (o que otros errores también desaparecen). Por ejemplo, si usted agrega una etiqueta de fin de tabla (</table>) que faltaba en el documento, puede que corrija todos los errores del tipo "element not allowed here" que había. En cualquier caso, el objetivo de todo autor debe ser no tener errores de ninguna clase.

DOCTYPE y Validación

Cuando usted valida su documento, puede escoger qué DTD (Document Type Definition, Definición del Tipo de Documento) desea utilizar como estándar. Hay muchas opciones disponibles, desde HTML 2.0 hasta el estándar más reciente disponible (XHTML 1.1 en el momento en que se escribió este artículo). Si quiere que sus páginas funcionen en navegadores modernos, la mejor opción es escoger un DTD reciente. Dada la naturaleza de compatibilidad de HTML y XHTML, validar con un DTD reciente significa que no tendrá problemas si se utiliza un navegador antiguo.

En lugar de escoger un DTD de la lista proporcionada, usted también puede establecer un elemento DOCTYPE al inicio del documento, especificando así el DTD que desea usar. Supongamos que desea utilizar el DTD estricto de HTML 4.01. En ese caso, la primera línea de su documento (justo antes de la etiqueta <html> tag) debe ser:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
          "https://www.w3.org/TR/html4/strict.dtd">

Una vez que se ha añadido el DOCTYPE al inicio del documento, podrá usar la opción de Tipo de Documento "(specified inline, especificado en el documento)" y el validador del W3C usará el DTD que ha declarado en su documento para validar el código.

Por otro lado, los navegadores recientes (Firefox 1.5, Opera 8,...) harán uso del DOCTYPE para decidir el "modo de interpretación" que usted quiere que el navegador utilice al mostrar su documento. Generalizando, cualquier DTD "transicional"(transitional, en inglés) o "flexible"(del inglésloose), así como la ausencia de declaración del DOCTYPE, hará que los navegadores utilicen un modo de representación que emule el comportamiento de los navegadores antiguos. Un DTD "estricto"(strict, en inglés), por el contrario, cambiará los navegadores a un modo de representación de acuerdo a los estándares. Esto permite que los autores decidan fácilmente cómo quieren que los navegadores interpreten su código.

Problemas comunes

Hay ciertos errores con los que los autores se encontrarán frecuentemente si validan sus páginas a menudo. Hay también algunas cosas que un Validador no puede detectar (el software es tan perfecto como las personas que lo escriben). Aquí están algunos de los errores y de las trampas más comunes a evitar.

Olvidar atributos importantes

Si usted obtiene un error relativo a un atributo, es probable que haya olvidado incluir un atributo obligatorio. Como pueden ser:

• el atributo type para los elementos script y style
• el atributo alt para los elementos img y area
• el atributo summary para el elemento table

Los dos últimos son importantes por razones de accesibilidad, pues su inclusión ayuda a los usuarios que están utilizando navegadores en modo texto o hablados. El primer atributo, type, es crítico para la compatibilidad hacia delante. Como ejemplo, muchos navegadores ignorarán cualquier elemento style que no tenga un atributo type; esto generalmente tiene el efecto no deseado de inhabilitar toda la hoja de estilo.

Una situación relacionada es que el DOCTYPE estricto para HTML y XHTML no permite el atributo language, así type es la única manera de marcar qué lenguaje de script se está utilizando. Así, si usted tiene un script que empieza así:

<script language="Javascript">

... es más que probable que el Validator señale un error. Puede arreglarlo modificando el elemento así:

<script type="text/javascript">

Problemas con Scripts

Además de los problemas potenciales relativos al atributo language, hay otras formas de que los scripts causen problemas al validar su HTML.

Si el script contiene etiquetas HTML dentro de cadenas, asegúrese de escapar el símbolo de barra hacia adelante. Por ejemplo, deberá escribir var docEle = "<html><\/html>" (observe el carácter en negrita) para prevenir problemas de validación. En todo caso, es una buena práctica.

También deberían incluirse los contenidos de los elementos SCRIPT en un comentario HTML. Esto es una práctica habitual tanto para scripts como para elementos STYLE, así que es probable que no se encuentre con este problema. La forma habitual de hacerlo tiene una apariencia similar a:

<script type="text/javascript"><!--
   (...el código va aquí...)
//--></script>

Observe el comentario de una sola línea en Javascript en la última línea, que se necesita para que el intérprete de Javascript del navegador ignore la cadena -->.

Elementos anidados incorrectamente

A lo largo de los años, los autores han desarrollado un conjunto de trucos para obtener los efectos deseados con el mínimo de código necesario, para evitar ciertos efectos de visualización. Desafortunadamente, la mayoría de los mismos están basados en marcado totalmente incorrecto y pueden causar la asfixia de cualquier validador. También pueden provocar errores de visualización y funcionamiento en navegadores que cumplen los estándares, como Netscape 6 e Internet Explorer 6 (en modo "strict"), así que deben ser corregidos en todo caso.

Un ejemplo típico es rodear con un elemento FONT uno o más párrafos, tablas o cualquier otro elemento de bloque. Lo cierto es que FONT es un elemento en línea, y por tanto, no puede contener elementos de bloque. Por tanto, el siguiente marcado es estructuralmente incorrecto:

<font color="red">
<p>¡Hey, los párrafos no pueden ir dentro de elementos font!</p>
</font>

Es exactamente la misma situación si se utiliza un elemento FONT alrededor de una tabla. Si se debe colorear todo el texto en la tabla, y se quiere utilizar FONT para ello, en ese caso se debería añadir un elemento font a cada celda de la tabla. Por supuesto, CSS hace esto mucho más sencillo:

<table style="color: red;">

Como nota al margen, algunos autores gustan de evitar el "margen" que el elemento FORM introduce entre celdas de una tabla haciendo algo como lo siguiente:

<table>
<form action="script.cgi" method="get">
<tr><td>(...elementos de formulario aquí...)</td></tr>
</form>
</table>

Esa práctica generará un error, porque no se puede poner FORM en el interior de una tabla pero fuera de una celda. Se podría rodear la tabla por completo con el elemento form, o poner el formulario dentro de la celda y utilizar CSS para poner sus márgenes a cero. En este último caso, el formulario debe estar completamente contenido en una sola celda. Si se utiliza una tabla para maquetar un formulario, el formulario debe estar rodeando a la tabla por completo, o a una sección entera del documento, si es factible.

Mayúsculas y minúsculas en los valores para class e id

A pesar del hecho de que HTML ha sido históricamente insensible a las mayúsculas, en HTML moderno y XHTML (así como XML) los valores sí son sensibles a mayúsculas. Esto incluye los valores de los identificadores class e id. Por ello, Enlace no es lo mismo que ENLACE o enlace. Los navegadores que siguen los estándares, como Firefox, cumplen esta pauta. Sin embargo, el validador de HTML no comprueba si, tanto en el documento, como en una hoja de estilo asociada o en un script, los valores repetidos tienen siempre el mismo 'valor' (incluidas las mayúsculas), y por tanto, no detectará algunas inconsistencias que podrían interferir en la correcta visualización de la página.

Para más información sobre este asunto, lea la nota técnica: "Case Sensitivity in class and id Names."

Comentarios incorrectos

Aunque pueda parecer una tontería, es importante asegurarse de que los comentarios HTML estén correctamente formateados. La forma correcta de un comentario de HTML es:

<!-- comentario -->

Esto es, dos guiones al principio y al final, no tres como a algunos autores les gusta incluir. En general, se debería evitar cualquier secuencia de guiones dentro de un comentario, y limitarse al par de guiones permitido para marcar el principio y el final del comentario. (Ver HTML 4.01, section 3.2.4 o HTML 4.01, sección 3.2.4 (español)para más información.)

Ampersands

El carácter ampersand (&) está reservado para marcar entidades de carácteres, por ello los autores nunca deben utilizar signos Ampersands tal cual en su código HTML, y esto incluye los signos Ampersands dentro de URLs. Así, cualquier URL que necesite un ampersand debe escribirse así:

https://www.site.web/path/doc.html?var1=val1&var2=val2&var3=val3

Cada aparición de & será traducido por el navegador como un ampersand, sin causar alertas al validar.

Valores explícitos y entrecomillados

Si está validando un DOCTYPE XHTML, todos sus atributos deben tener valores, y todos estos valores deben estar entre comillas. Debe también cerrar cada elemento que abra, incluso los elementos que no tienen etiqueta de cierre. En estos casos, el final de la etiqueta del elemento debe incluir una barra hacia adelante "/". Éstos son requisitos de XHTML (y en general de los lenguajes basados en XML), por lo que el Validador señalará con una alerta cualquier infracción de estas reglas. Un ejemplo del código XHTML válido que se diferencia claramente del HTML tradicional:

<input type="checkbox" checked="checked" name="prefSys" value="MacOS" />

Observe la adición de un valor (entre comillas) para checked, y la barra al final de la etiqueta. Sin estos añadidos, este fragmento de código no sería XHTML .

Conclusión

Aunque al principio pueda parecer más trabajoso, validar su código ahora dará sus frutos más adelante en tiempo y esfuerzo ganados. No sólo sus documentos tendrán mayores posibilidad de ser correctamente mostrados en todos los navegadores actuales y futuros, sino que además su mantenimiento será mucho más fácil, o incluso su conversión de HTML a otro lenguage de marcado como XML.

Aunque lo ideal es que las páginas no generen ni errores ni advertencias en la validación, su principal preocupación debe ser la eliminación de errores reales. Asimismo, usted debe preocuparse más por los errores en los elementos que por los errores en los atributos, aunque en realidad no puede permitirse ignorar estos últimos. Una vez que usted haya limpiado todo de modo que no queden errores, podrá volver a la tarea de estilizar el documento, confiando en que la página se mostrará correctamente en cualquier navegador conocido, así como en cualquier navegador decente por venir.

Enlaces relacionados

• El validador de HTML del W3C
• W3C Lista DTD
• HTML 4.01, sección 3.2.4
• Explicación del DOCTYPE

Interwiki, vínculos a otros idiomas