Nota del Traductor:El presente documento es la traducción al castellano del documento original (en inglés) titulado «My Web site is standard! And yours?».
La única versión normativa es la versión original en inglés, en los términos por ella especificados.
Puede enviar cualquier comentario sobre esta traducción a la siguiente dirección de correo electrónico ferguweb@sidar.org.
Gracias.
Fernando Gutiérrez Ferrerías
Introducción· Estándar· Validación· Herramientas·
QA Inicio· Últimas Noticias· QA Recursos· QA IG· QA WG· QA Calendario·
Este artículo ha sido producido como parte del trabajo del Grupo de Interés de Aseguramiento de la Calidad del W3C. Por favor, envía cualquier comentario público sobre el mismo a la lista de correo archivada públicamente public-evangelist@w3.org o para comentarios privados a karl@w3.org. El autor reconoce a las personas que han dedicado tiempo para revisar y aportar ideas.
Aquí encontrarás técnicas e ideas fáciles e indoloras para mejorar la calidad de tu sitio Web y hacer que tu sitio Web sea válido. Este documento está destinado a usuarios de HTML, desarrolladores que trabajan en aplicaciones Web, y Webmasters.
La mayoría de sitios Web no son válidos. Podemos asumir que se encuentran en este caso el 99% de las páginas Web, pero no existen estadísticas para corroborarlo. Sería interesante realizar una encuesta para probar que este caso es realmente cierto.
¿Porqué?
He oído muchos comentarios y monserga sobre este asunto. La mayor parte de ellos se deben, a menudo a una carencia de conocimiento y comprensión de lo que es la validación HTML. Lo siguiente son algunos ejemplos:
Steve, CEO, dijo: Si mi sitio Web está hecho con estándares, será aburrido y perderé clientes.
Con los estándares W3C, podrás tener sitios Web muy atractivos. Crear un sitio Web que respete los estándares no tiene nada que ver con generar páginas Web únicamente textuales.
El W3C propone en la actualidad un conjunto de tecnologías integradas muy divertidas. Puedes experimentar un sitio Web completamente multimedia con las existentes tecnologías interoperables del W3C utilizando XHTML (Marcado XML estructurado), CSS (Hojas de estilo), SVG (Gráficos vectoriales animados en 2D), y SMIL (Multimedia Sincronizada). Estas tecnologías han contado con el consenso de los diferentes actores del mercado Web.
Alan, Director Técnico, dijo: No tengo los medios financieros para preocuparme por los estándares en mi sitio Web. ¡Costará demasiado!
Diseñar con estándares simplificará el mantenimiento del código del sitio Web porque no tendrás múltiples versiones para diferentes navegadores. Tus páginas tendrán una vida más larga y no dependerán de tecnologías vaporosas. Por tanto, diseñar con estándares Web te costará menos en realidad.
Dean, Director Artístico, dijo: si respeto los estándares, invadirán mi creatividad.
Las limitaciones técnicas existen en cualquier medio artístico, bien estés dibujando, esculpiendo, o diseñando páginas Web. Las acuarelas o las pinturas al óleo tienen sus propias limitaciones, pero esas técnicas no bloquean la creatividad, sino que proporcionan una estructura para la expresión creativa.
Crear con los estándares Web abrirá un mundo nuevo con técnicas particulares al medio, la tecnología, la audiencia. Aún hay mucho que explorar en este dominio. Estamos sólo comenzando a explorar los beneficios de las experiencias multimedia basadas en estándares.
Claudia, Diseñadora Gráfica, dijo: No me importa la accesibilidad. Las personas con discapacidades no se encuentran en mi audiencia objetiva.
Tú te beneficiarás de diseñar con respeto a la accesibilidad. Las personas con discapacidades representan del 8% al 10% de la población total. Es más fácil mantener un sitio Web que sigue las pautas de accesibilidad (y por tanto los estándares Web). El tráfico de tu sitio Web se incrementará, y una más amplia variedad de navegadores tendrán acceso al contenido del sitio.
Algunos países requieren la accesibilidad por ley, como Australia (Notas Consultivas sobre el Acta de Discriminación de Discapacitados Versión 3.1 Mayo 1999) o USA (Sección 508 - Aplicaciones e Información en Intranet e Internet basadas en Web) o Europa está trabajando en un plan similar (e-accessibilidad).
Aminata, Programadora Web, dijo: ¿Porqué debería respetar los estándares? La Web es un lugar libre.
La Web es un lugar libre compartido por muchos usuarios cuyas necesidades no necesariamente conoces. Los estándares han sido diseñados para tener en mente a todas las audiencias potenciales. Es un reto a la comunidad Web el crear con estándares Web. No estarás ligado a ninguna compañía o tecnología propietaria. Puedes usar tecnologías que son independientes de los requerimientos de las plataformas.
Karl, Desarrollador Web, dijo: Me he limitado a seguir las instrucciones de los libros.
Desafortunadamente, muchos libros no enseñan buena programación Web. Cuando creas un sitio Web, deberías comprobar la corrección de tu marcado. Si eres un desarrollador Web, se cuidadoso al utilizar los libros para desarrollar tu aplicación y lee las especificaciones particulares que estás tratando de implementar.
Algunos sitios Web están recogiendo buenos materiales para ayudar a la gente a diseñar de acuerdo a los estándares W3C. En el sitio Web del W3C, encontrarás una lista creciente de tutoriales promoviendo buenas prácticas.
Algunas personas del W3C han desarrollado software libremente accessible para tu propio uso. Te animamos a usarlo cuando sea posible. Estos paquetes de software implementan las tecnologías del W3C.
Tim, Contable, dijo: Mi editor Web genera marcado no válido.
Muchas herramientas de autor no generan marcado válido. Algunos tienen incrustados correctores de sintaxis, otros hacen lo correcto, y muchos no generan marcado válido. Como una solución intermedia, tienes que comprobar tu página Web con un validador HTML. Al mismo tiempo, contacta con el manufacturador del software (por email, teléfono o carta) y házselo saber. Las compañías harán lo correcto si se lo pides.
Valérie, Desarrollador de Contenido Web, dijo: No es culpa mía. Es la forma en que ha sido diseñado el motor de plantillas. (A menudo un sistema con una interfaz basada en Web).
Estás en lo cierto. A menudo no es culpa tuya. Si es un simple formulario donde tú núnca escribes HTML a mano, escribe al desarrollador de tu interfaz o al mantenedor de su sitio hasta que el problema sea solucionado. Si no estás seguro de si el contenido producido respeta los estándares del W3C, valida el contenido con el validador HTML, y envía el informe a tu Wemmaster, o la persona a cargo del sistema de gestión de contenido.
Ning, Desarrollador de Software, dijo: No existe información para ayudarme. Todos los materiales que he encontrado están en Inglés.
Algunas personas han traducido documentos y especificaciones a otras lenguas. El W3C mantiene una lista de traducciones.
HTML ha evolucionado durante su desarrollo y está disponible en varias versiones. Todas ellas son estándares, y puedes elegir una que se adapte a tus necesidades. La mayoría de las veces, la última versión será la mejor elección, a menos que te dirijas a una audiencia muy específica, o los navegadores más antiguos, o interrumpidos. La versión que elijas define los elementos y atributos que puedes usar.
Por ejemplo, en HTML 4.01, encontrarás la lista de elementos y la lista de atributos que puedes usar en tus páginas. Puedes editar tus páginas manualmente, un medio usualmente referido como "codificación a mano" o "escribir el código fuente."
HTML 4.01 te permite escribir un párrafo y un identificador de ancla a ese párrafo, como éste:
<p id="ref">Esto es un parrafo</p>
Presta atención a la forma en que anidas los elementos. Algunos elementos no pueden incluirse dentro de otros, y algunos atributos pertenecen únicamente a ciertos elementos.
Los elementos que puedes escribir en tu documento o implementar en tu software dependen de la versión HTML. Esta tabla contiene una lista de definiciones HTML, o tipos de documento (DOCTYPEs), que puedes utilizar:
| Versión | Lista de DTD | Declaración DOCTYPE en los documentos |
|---|---|---|
| HTML 2.0 | DTD |
<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN"> |
| HTML 3.2 | DTD |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> |
| HTML 4.01 | Strict, Transitional, Frameset |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd"> |
| XHTML 1.0 | Strict, Transitional, Frameset |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/hhtml1-transitional.dtd"> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-framesetddtd"> |
| XHTML 1.1 | DTD |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> |
No puedes validar tu documento si no usas uno de estos DOCTYPEs al inicio de tu documento. No lo olvides si escribes tus documentos a mano.
Aquí, tienes un ejemplo de una plantilla de documento XHTML 1.0 Estricto.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Una plantilla XHTML 1.0 Estricto</title>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
</head>
<body>
... Aqui tu contenido HTML ...
</body>
</html>
Una plantilla XHTML Estricto es muy fácil de conseguir. La modificación y validación del documento es sencilla y directa.
Un validador HTML simplemente comprueba la corrección de tu documento frente al DOCTYPE declarado.
Si quieres verificar la validez de tu documento final al ser mostrado por un agente de usuario (por ejemplo, un navegador Web), puedes usar el validador HTML del W3C. El validador HTML devolverá una lista de errores de acuerdo al DOCTYPE HTML elegido. Si tu documento no tiene errores, devolverá un mensaje de ¡No se encontraron errores!
.
Si editas tu sitio Web con la ayuda de formularios (y no escribes etiquetas HTML en tu formulario), puedes informar de los errores al Webmaster de tu sitio y pedirle que arregle el generador de marcado HTML.
Si creas tu sitio Web a mano o componiendo directamente el código de marcado, y el validador te devuelve errores en tu página, simplemente corrige tu marcado. El validador HTML te proporciona el número de línea en que se encuentra el error.
El validador HTML proporciona el número de línea donde ocurren los errores, ayudándote así a localizar los problemas en tu documetto. Comprueba el fichero línea a línea, comenzando por la primera. Esto quiere decir que un error que esté al comienzo de tu documento puede resultar en más errores adicionales a lo largo de lappágina. Una buena forma de trabajar los errores es corregir el primer error mostrado, y entonces revalidar la página. A menudo descubrirás que corrigiendo un problema al inicio del documento se resuelven unos cuantos errores a la vez. Continúa haciendo esto hasta que todos los errores estén corregidos, y el documento resultante será válido.
Si usas una herramienta de autor HTML y tus páginas no son válidas tras la validación, por favor informa de ello a la compañía o al desarrollador del software. Deberías ser capaz de contactar con el personal de soporte técnico de la compañía.
Si eres el desarrollador de un motor de plantillas, herramienta de autor, o sistema de gestión de contenido, usa el validador HTML para corregir los problemas de tu implementación. También puedes incorporar el validador HTML en tu software o aplicación en ejecución. El código fuente del validador HTML se encuentra libremente disponible.El validador está siendo mejorado cada día y puedes participar en su desarrollo.
Nota: Algunos documentos son válidos con respecto a la DTD y al mismo tiempo son incorrectos con respecto a la especificación HTML. En un futuro cercano, presentaremos una lista de posibles errores no detectados por el validador HTML.
Lista de validadores HTML
Otra cuestión importante con muchos sitios Web es la persistencia de las URIs. Cuando en tus documentos incluyes enlaces a otros sitios Web, esperas que aquellos enlaces permanecerán estables y persistentes. Esto significa que la información a la que quieres apuntar aún estará allí cuando alguien que lea tu sitio Web haga clic en uno de los enlaces que tú proporcionaste. También querrás verificar y garantizar que los enlaces que has proporcionado a otras páginas Web u otras secciones de tu propio sitio Web tampoco contienen errores. Hay una herramienta que ha sido desarrollada con este propósito: W3C Link Checker.
Checklink genera un informe sobre los enlaces. La longitud del informe depende del tiempo que lleve alcanzar y verificar todos los enlaces contenidos en tu página. Para verificar el enlace, el programa maneja las peticiones de CABECERAS HTTP del documento. Si el servidor está mal configurado, puedes obtener un informe erróneo aunque el enlace sea correcto, pero sólo porque el servidor es incapaz de proporcionar la CABECERA. En este caso, deberías escribir al Webmaster del sitio Web para pedirle que arregle la configuración del servidor.
Checking link http://webstandards.org/ HEAD http://webstandards.org/ fetched in 0.1s
Lo anterior es un ejemplo de lista. Proporciona el tiempo que tarda en alcanzar el enlace.
Tras la lista de enlaces, tendrás un informe de los enlaces que están rotos o redireccionados, lo cual te ayudará a corregir enlaces incorrectos.
Si quieres tener más información sobre la importancia de los enlaces, te invitamos a leer el documento Las URIs guays no cambian
escrito por Tim Berners-Lee.
Si tú, como Webmaster, deseas instalar un programa en tu sitio Web para ayudar a la gente a comprobar sus páginas Web, el código fuente del W3C Link Checker está disponible gratuitamente.
Desde 1996, las Hojas de Estilo en Cascada (CSS) han proporcionado una forma de separar la estructura del estilo de una manera elegante y efectiva. En el último año (2001), muchos agentes de usuario (navegadores) han implementado soporte para CSS 1 y CSS 2. Usar hojas de estilo te ayuda a mantener toda la información sobre el estilo de tus documentos en un único lugar.
A la fecha de escribir este artículo, puedes elegir entre CSS 1 y CSS 2 para dar estilo a tus documentos.
Diseñar con hojas de estilo tiene muchos beneficios, como reducir el coste de diseño de tu sitio Web e incrementar su interoperabilidad (legibilidad de tu sitio Web en muchos agentes de usuario diferentes). Diseñar tu sitio Web para múltiples versiones de agentes de usuario con tablas y JavaScript incrementa el coste inicial de construcción en un 30%.
No uses el elemento FONT con el atributo FACE. Se considera dañino desde un punto de vista de internacionalización. Si quieres aprender cómo liberarte del elemento font y adoptar las hojas de estilo te animamos a leer el tutorial de Todd Fahrner Más allá de la etiqueta FONT:
Estilización práctica de texto HTML
Igual que con el Servicio de Validación HTML y Servicio de Validación CSS, podrás comprobar la validez de tu hoja de estilo. Puedes comprobar la validez de hojas de estilo externas llamadas por tu documento. Si deseas instalar tu propia versión en tu sitio Web, el código fuente del validador CSS está disponible gratuitamente.
Hacer un sitio Web no es suficiente. La mayoría de veces no conoces a tu audiencia. Las personas que acceden a tu sitio Web tienen diferentes materiales, navegadores y/o discapacidades específicas. Existen un montón de beneficios empresariales para hacer un diseño de sitio Web accesible. Desafortunadamente, es menos directo validar tus documentos respecto a la accesibilidad. Algunas herramientas, como Bobby, pueden ayudarte, pero no son la respuesta final en lo que concierne a la accesibilidad. Necesitarás hacer una revisión humana de tu contenido. La Iniciativa de Accesibilidad a la Web mantiene una lista de recursos que te ayudarán a diseñar sitios Web accesibles.
A menudo la gente se desanima a hacer sitios Web válidos a causa del número de páginas inválidas que tienen o porque no saben por dónde empezar. Es muy sencillo, sé LISTO: Pequeño, Meticuloso, Accesible, Regular, Plantilla [ Nota del Traductor: Juego de palabras que el autor hace con las siglas de las palabras para formar la palabra «SMART: Small, Meticulous, Accessible, Regular, Template» ]. Dar pasos pequeños te ayudará a tener un sitio Web válido sin sufrimiento ni desánimo. Así que piensa progresivamente y encuentra soluciones que harán tu trabajo más fácil, como el uso de un motor de plantillas.
Esta es una lista de herramientas que te ayudarán a tener un sitio Web mejor.
Tidy fue desarrollado inicialmente por Dave Raggett. Te ayudará a hacer una página Web válida. A veces Tidy es incapaz de arreglar todos los errores. Tidy no es una herramienta de edición—sólo te ayudará a solucionar cosas.
A veces es muy difícil saber qué páginas de tus sitios Web son inválidas. Si ejecutas un script que recorra todas tus páginas, tendrás una lista bastante grande de páginas inválidas.
Entonces, ¿cuál es la solución?
En el W3C, Gerald Oskoboiny ha desarrollado una herramienta de QA progresiva para sitios Web que no sobrecarga al Webmaster de un sitio. Dicha herramienta envía un informe de las diez documentos inválidos con más accesos, proporcionando una notificación para que puedan ser corregidas. Cada semana, el Webmaster recibirá un nuevo informe con el listado de los 10 documentos más inválidos. Esta herramienta ha sido liberada al dominio público. Puedes adaptarla a tus propias necesidades.
Olivier Théreaux, W3C, ha desarrollado una versión más portable y conectable de esta herramienta: LogValidator
Esta herramienta toma los ultimos archivos de registro de un servidor Web y los procesa a través de módulos de validación. Estos módulos de validación comprueban la validez de los documentos más populares frente a una determinada tecnología. El módulo por defecto es la validación HTML, pero habrá otros disponibles.
Así, serás capaz de corregir la ortografía de tus páginas Web, si has incluído metainformación, si los enlaces siguen siendo válidos, etc. La documentación de la API te ayudará a crear nuevos módulos dependiendo de tus necesidades.
Gracias a las personas que han revisado este artículo: Ian Jacobs, Susan Lesch, Olivier Théreaux, Stephanie Troeth, Jeffrey Zeldman y la gente de la lista de correo public-evangelist.
Este artículo no habría sido posible sin la participación de Kim Nylander, escritor técnico, quien lo ha revisado y ayudado.
