El servicio w3c validator tiene la utilidad de testear una web para encontrar las partes en las que esta puede ser incompatible con los estándares, las partes con errores y los posibles conflictos que se pueden dar.
Este servicio puede validar HTML indicando la URL de la web, subiendo un archivo .html o escribiendo el HTML directamente.
Pasar correctamente estas validaciones y por consiguiente conseguir el logo de «W3C validator» es bastante complicado, sobre todo en el caso de intentar pasar este test una vez finalizada la parte de desarrollo en la página web; a nosotros nos sucedió ese problema: tratamos de solucionar la mayor parte de problemas de compatibilidad posibles, pero no fue posible en todos los casos.
A priori puede parecer que, mientras la página funcione y se vea más o menos bien en la mayoría de los navegadores, es suficiente; pero no deberíamos conformarnos con esto porque el principal motivo para esforzarse en este tema es que Google indexa mejor páginas que sean W3C compatible, esto es debido a que para el robot de Google le es más fácil leer nuestra web, por lo que obtendríamos mejores resultados en las búsquedas de Google.
A continuación voy a detallarle las cosas que suelen dar errores y que hay que tratar de evitar porque dan problemas con el validador de W3C:
Dejarse etiquetas sin cerrar:
Esto puede parecer obvio, pero no lo es tanto. A veces se nos puede olvidar cerrar un div, es normal, y este validador nos lo indicará.
Pero hay casos en los que hay que cerrar las etiquetas aunque no haga falta, por ejemplo, en el caso de utilizar XHTML, las etiquetas img deben terminar con />, las etiquetas meta , link, input, etc. necesitan ser cerradas de manera explícita.
Otro caso es el de las etiquetas que aparentemente no es necesario cerrar, sino que el navegador sobreentiende que ya han finalizado. Este es el caso, por ejemplo de las etiquetas <option> y <li> no son imprescindibles de cerrar, porque cuando empieza la siguiente etiqueta de este tipo ya se sobreentiende que se han cerrado. Esta práctica no cumple con los estándares, por lo que deberíamos evitarla.
Uso excesivo de tablas
Este es un problema dificil de diagnosticar, puesto que el validador nos mostrará un montón de errores cuando una página tiene muchas tablas. Para que las tablas sean compatibles, tienen que estar compuestas de la siguiente manera: <table><tbody><tr><td>, en caso de que el tbody se nos olvide o algo, ya nos dará error.
El consejo sería evitar el uso de las tablas, aunque, como a veces es inevitable, se pueden o bien ignorar los errores, o tratar de usar todas las etiquetas necesarias.
Elementos que están donde no deben
Este problema es típico cuando se define unos estilos dentro del body o cuando se tratan de usar etiquetas meta dentro del body. También da error en caso de introducir una etiqueta que dibuje algo en la pantalla dentro del head.
Estos errores son habitualmente fáciles de solucionar, aunque hay veces que hay problemas inevitables. Se trata de situar cada elemento en su sitio y ya está; si nos es imprescindible que un elemento esté fuera del sitio, tampoco nos tenemos que obsesionar.
Atributos que una etiqueta no tiene
Este tipo de errores se suele dar en páginas en las que se aplica Javascript, como nos es necesario acceder a los elementos de la página a través de atributos id, name, class, etc., a veces podemos tener el caso de que nos hagan falta más atributos o algo así.
Un caso puede ser tener un elemento <td> en el que hemos aplicado un atributo id para ponerle estilo CSS, si este id se repite (más adelante veremos que esto también da problemas), entonces tenemos que tener otro atributo que se refiera a este elemento td. Una posible solución es usar un atributo name, esta práctica no es muy recomendable, puesto que da errores de compatibilidad; siempre hay que tratar de usar un atributo id y que sea único.
El atributo name se debería utilizar solo para formularios y para anclas.
Problemas con IDs
Un ID es un identificador único, por lo tanto, se debe utilizar tan solo para una etiqueta hml. En caso de usarlo para aplicar un estilo CSS, se debe tener en cuenta que si ese estilo solo se va a usar en una etiqueta de la misma página, entonces si se puede usar un ID; en caso de tener que reutilizar el mismo estilo varias veces en el mismo documento, entonces hay que usar una class.
Los IDs no pueden empezar por un número sino que deben empezar por una letra o un guión bajo o similar. Esto puede suponer un problema cuando, para aplicar Javascript nos es necesario aplicar un ID a un elemento que sea su número identificador; por ejemplo, en la pantalla de lista de sorteos cada sorteo tiene en el botón de borrar sorteo asignado un id que es el número de sorteo. En nuestro caso nos es imprescindible, puesto que así se facilitan mucho las operaciones internas; podríamos haber evitado esta práctica, aunque no lo hemos visto necesario.
En resumen, que se evite empezar por un número, aunque tampoco tiene que ser algo que complique mucho la programación interna en Javascript o PHP.
Resumen
Concluyendo, hay que tratar de pasar el W3C validator aunque tampoco debe ser una obsesión que haga que pongamos todos nuestros recursos en pasar con éxito. Es más importante saber como evitar los errores que saber cómo arreglarlos; esto es debido a que a veces es tan avanzada la programación interna, que es muy complicado modificarla a posteriori para que se tomen en cuenta los cambios.
En sortea2 hemos tratado de pasar el W3C validator, aunque en la mayoría de las páginas no nos ha sido posible. Lo importante es saber qué técnicas evitar a la hora de programar y es por eso por lo que os escribo este artículo.
¿crees que faltan errores de compatibilidad comunes? comunícanoslo a través de los comentarios.
