Recomendaciones de carácter general para el desarrollo de las plantillas

datos.gob.es

En colaboración con

Las opiniones recogidas en este documento no se corresponden, necesariamente, con las de ninguno de los organismos públicos participantes en esta iniciativa.

Contenidos 1   Objetivo............................................................................................................................ 3   2   Recomendaciones Generales ........................................................................................ 3   2.1   Código HTML ............................................................................................................... 3   2.1.1   RCG1 - Declaración de documento válida (DOCTYPE) ...................................................... 3   2.1.2   RCG2 - Evitar errores de visualización por el modo de funcionamiento de los navegadores3   2.1.3   RCG3 - HTML 4.01 o superior ............................................................................................. 4   2.1.4   RCG4 - Código (X)HTML válido gramaticalmente ............................................................... 4   2.1.5   RCG5 - Tipos MIME adecuados .......................................................................................... 5   2.1.6   RCG6 - Seguir las reglas de compatibilidad para XHTML servido como HTML .................. 5   2.1.7   RCG7- Gramáticas estrictas ................................................................................................ 6   2.1.8   RCG8 - Ausencia de elementos desaconsejdados .............................................................. 6   2.1.9   RCG9 - Ausencia de elementos propietarios ....................................................................... 6   2.1.10   RCG10 - Evitar marcos .................................................................................................... 6   2.1.11   RCG11 - Código semántico ............................................................................................. 7   2.1.12   RCG12 - Emplear un único encabezado de nivel superior .............................................. 7   2.1.13   RCG13 - Código correctamente estructurado y jerarquizado .......................................... 7   2.1.14   RCG14 - Nombres de clases e identificadores significativos .......................................... 8   2.1.15   RCG15 - Usar únicamente HTML para el contenido ....................................................... 8  

2.2   Código CSS ................................................................................................................. 8   2.2.1   RCG16 - Código (CSS) válido gramaticalmente .................................................................. 8   2.2.2   RCG17 - Usar únicamente CSS para la presentación ......................................................... 8   2.2.3   RCG18 - Ausencia tablas de maquetación .......................................................................... 9   2.2.4   RCG19 - Usar CSS para imágenes decorativas .................................................................. 9   2.2.5   RCG20 - Hacks correctamente identificados, documentados y diferenciados .................... 9   2.2.6   RCG21 - Evitar propiedades propietarias de CSS ............................................................. 10   2.2.7   RGC22 - Estructurar y jerarquizar el código ...................................................................... 10   2.2.8   RCG23 - Usar ficheros externos para las hojas de estilo .................................................. 11   2.2.9   RCG24 - Emplear códigos numéricos para la definición de colores en lugar de palabras clave ................................................................................................................................... 11  

2.3   Scripting ..................................................................................................................... 12   2.3.1   RCG25 – Seguir el estándar EcmaScript ........................................................................... 12   2.3.2   RCG26 - Scripting no intrusivo ........................................................................................... 12   2.3.3   RCG27 - Usar DOM para la manipulación de la jerarquía del documento ........................ 13  

1

2.3.4   RCG28 - Usar scripting únicamente para el comportamiento ............................................ 13   2.3.5   RCG29 - Scripting como mejora progresiva ...................................................................... 13   2.3.6   RCG30 - Detección de objetos en vez de detección de navegador para probar el soporte de capacidades ....................................................................................................................... 14   2.3.7   RCG31 - Evitar document.write ......................................................................................... 14   2.3.8   RCG32 - Ausencia del pseudo-protocolo javascript: ......................................................... 15   2.3.9   RCG33 - Evitar NOSCRIPT ............................................................................................... 15  

2.4   Interoperabilidad ........................................................................................................ 15   2.4.1   RCG34 - Contenido en un orden lógico ............................................................................. 15   2.4.2   RCG35 - Código compatible multinavegador ..................................................................... 16   2.4.3   RCG36 - Maquetación adaptable a distintas resoluciones ................................................ 16   2.4.4   RCG37 - Maquetación adaptable al redimensionamiento del texto sin romperse o volverse ilegible ................................................................................................................................ 16   2.4.5   RCG38 - Contenido adaptable a la impresión ................................................................... 16  

2

1 Objetivo. En el presente documento se incluyen un conjunto de recomendaciones técnicas y buenas prácticas que permitan cumplir con los requisitos de compatibilidad y estándares definidos en el proyecto. Se trata de recomendaciones de carácter general para una correcta codificación en (X)HTML, hojas de estilo y scripting, así como para asegurar la plena interoperabilidad de los documentos. En este documento no se contemplan de forma específica otros requisitos del proyecto relacionados con los aspectos de Independencia de Dispositivo, Usabilidad y Accesibilidad, al tratarse específicamente en otros documentos complementarios.

2 Recomendaciones Generales 2.1 Código HTML 2.1.1 RCG1 - Declaración de documento válida (DOCTYPE) La declaración de tipo de documento identifica la gramática formal empleada y permite validar el código de la página según los estándares utilizados. Debe estar al comienzo del documento para indicarle al navegador cual es la versión de (X)HTML que se está usando. La sintaxis de la declaración de tipo de documento debe ser exacta. A continuación se indica una serie de DTDs recomendados por el W3C.

Listado de DTDs recomendados para usar en documentos web: http://www.w3.org/QA/2002/04/valid-dtd-list.html

Si la declaración es incorrecta o no se incluye, algunos navegadores interpretarán los documentos en modo Quirks, pudiendo dar lugar a diferencias en la interpretación de los mismos. 2.1.2 RCG2 - Evitar errores de visualización por el modo de funcionamiento de los navegadores Con la mejora del soporte de los estándares por parte de los navegadores algunas páginas antiguas puede que no se visualicen correctamente. Para asegurar que todas las páginas se muestran según la intención original de los autores, tanto las nuevas que siguen los estándares como las antiguas que no los respetan, los navegadores suelen incluir dos modos de funcionamiento: estándar y quirks. En el modo estándar el navegador respeta

3

los estándares mientras que en el modo quirks trata de emular el comportamiento de los navegadores antiguos. Generalmente, el método que emplean los navegadores para cambiar entre un modo de funcionamiento u otro es en base a la declaración del tipo de documento (ver punto anterior). Si no existe una declaración de tipo de documento o ésta es incorrecta, entrarán en modo quirks, por eso es importante que nos aseguremos que la declaración que usemos es correcta para que los navegadores se ejecuten en modo estándar.

Enlaces de interés: http://www.quirksmode.org/css/quirksmode.html http://developer.mozilla.org/en/docs/Mozilla_Quirks_Mode_Behavior http://www.opera.com/docs/specs/doctype/ http://msdn.microsoft.com/en-us/magazine/cc163763.aspx

2.1.3 RCG3 - HTML 4.01 o superior El principal objetivo de las especificaciones del W3C es el de asegurar la máxima compatibilidad futura de los documentos así como su correcto funcionamiento para la mayoría de los usuarios, independientemente de la plataforma o navegador usado. Para incorporar a nuestros documentos los mayores beneficios se recomienda emplear las últimas versiones soportadas, considerando como mínimo exigible HTML 4.01 y recomendable XHTML1.0 para este proyecto. 2.1.4 RCG4 - Código (X)HTML válido gramaticalmente Debemos comprobar que los documentos son válidos según la especificación de (X)HTML indicada en la declaración de tipo de documento. No debemos limitarnos a verificar los documentos simplemente comprobando cómo se visualizan en un conjunto de navegadores, porque estos están diseñados específicamente para poder mostrar la mayor cantidad de documentos, sean válidos o no.

Debemos validar la gramática de los documentos con alguna de las herramientas disponibles, como el servicio de validación (http://validator.w3.org/) proporcionado por el W3C, para localizar y corregir los errores que se encuentren.

Si no validamos el código frente a una gramática formal estaremos comprometiendo la compatibilidad del código tanto con los navegadores actuales como futuros.

4

2.1.5 RCG5 - Tipos MIME adecuados Cuando se solicita un archivo a un servidor web éste nos lo entregará proporcionando en la cabecera del protocolo HTTP información sobre el tipo MIME asociado. Los navegadores usan esa información para saber cómo tratar los datos enviados ya que no se tratará de igual manera un documento de texto (por ejemplo, código HTML) que un archivo de imagen. XHTML, al ser una reformulación de HTML como una aplicación XML, debe seguir las reglas de XML y estar bien formado (cumplir reglas como anidación correcta de los elementos, entrecomillado de atributos, minúsculas para los elementos, etc.). Para que los navegadores procesen XHTML como XML es necesario identificarlo con el tipo MIME adecuado. El tipo MIME application/xhtml+xml es el que se debería usar para documentos XHTML servidos a navegadores y agentes de usuarios compatibles con XHTML (XHTML servido como XML). Cuando un documento se envía con este tipo MIME los agentes de usuario deben procesarlo y comprobar que sigue las reglas de XML y comprobar que está bien formado. Si un documento que usa application/xhtml+xml no está bien formado el navegador debería informar del error y no mostrar el documento. Los tipos MIME application/xml y text/xml son otros dos tipos genéricos para documentos XML. Aunque se pueden usar para documentos XHTML servidos como XML es preferible usar el tipo MIME application/xhtml+xml. Por otro lado, el tipo MIME text/html es el usado por los documentos HTML y no se debería usar para documentos XHTML. Sin embargo, se puede usar cuando queramos servir documentos XHTML que sean compatibles con HTML 4.01 (que sigan las reglas de compatibilidad para XHTML servido como HTML (ver punto siguiente) de forma que se visualicen correctamente en navegadores antiguos que no soporten XHTML. Con este tipo MIME los navegadores mostrarán los documentos aunque no estén bien formados.

Tipos MIME para XHTML: http://www.w3.org/TR/xhtml-media-types/

2.1.6 RCG6 - Seguir las reglas de compatibilidad para XHTML servido como HTML Algunos agentes de usuario HTML antiguos no son compatibles con XHTML y no lo interpretan correctamente si no se siguen las recomendaciones de compatibilidad para XHTML propuestas en el Apéndice C) de la especificación.

Recomendaciones de compatibilidad de XHTML servido como HTML http://www.w3.org/TR/xhtml1/#guidelines

5

El tipo MIME text/html para documentos XHTML solo debería usarse con el propósito de que estos documentos se muestren en agentes de usuario HTML y que, por tanto, sigan las reglas de compatibilidad del Apéndice C). Cuando

un

documento

XHTML

es

servido

como

XML,

con

el

tipo

MIME

application/xhtml+xml, no es necesario que siga estas reglas de compatibilidad.

2.1.7 RCG7- Gramáticas estrictas Las gramáticas de tipo "Strict" están ideadas para lograr la máxima separación entre contenido y presentación. Este tipo de gramáticas no permiten el uso de elementos y atributos desaconsejados, principalmente con carácter presentacional (FONT, CENTER, U), estando orientadas principalmente para su uso junto con hojas de estilo (CSS). Por tanto, las gramáticas estrictas son más recomendables por las ventajas que aportan frente a otras menos restrictivas como "Transitional" o "Frameset". 2.1.8 RCG8 - Ausencia de elementos desaconsejdados Un elemento o atributo desaconsejado (deprecated) es aquel que ha quedado anticuado. Los elementos desaconsejados quedarán obsoletos en futuras versiones de HTML y por tanto los desarrolladores deben evitar su uso. Generalmente se trata de elementos o atributos de presentación (FONT, border, bgcolor, align, height, width, language, etc...) que deben desaparecer en beneficio de las hojas de estilo. 2.1.9 RCG9 - Ausencia de elementos propietarios El gran éxito del HTML hizo que evolucionase demasiado rápido y de forma desordenada, en ocasiones sin un criterio claro. Así, los diferentes navegadores, con la intención de aportar ventajas sobre sus competidores, crearon de forma independiente una serie de elementos o atributos nuevos que sólo ellos soportaban. Algunos de estos elementos pasaron posteriormente a forma parte del estándar (las gramáticas formales definidas por el W3C) pero otros quedaron como elementos propietarios de estos navegadores. No debemos usar este tipo de elementos debido al limitado soporte que tienen entre todos los navegadores y a la falta de compatibilidad con las especificaciones, impidiendo la validación de los documentos. 2.1.10

RCG10 - Evitar marcos

Los marcos son problemáticos ya que pueden alterar la forma de navegación habitual en algunos agentes de usuario (uso del botón "atrás", marcadores, etc.) o pueden no estar soportados. Para usar marcos es necesario emplear una gramática de tipo "Frameset". Esta gramática es igual que la gramática "Transitional" salvo por el uso de los elementos específicos de marcos, perdiendo las ventajas del uso de gramáticas estrictas ("Strict"). Los marcos están desaconsejados por el W3C. Sólo están disponibles para HTML o para XHTML 1.0, pero no para XHTML 1.1. Si queremos asegurar la máxima compatibilidad futura deberemos, por tanto, evitar el uso de marcos. 6

2.1.11

RCG11 - Código semántico

Un marcado (X)HTML adecuado debe usar los elementos de forma que describan el tipo de información que contienen. Es decir, que aporten información estructural o semántica (significado) sobre el contenido. Así, por ejemplo, usaremos el elemento H1 para el encabezado de mayor nivel, los elementos H2-H6 para el resto de encabezados del documento o el elemento P para los párrafos; identificaremos el texto enfatizado con EM (énfasis) o con STRONG (énfasis fuerte), marcaremos las listas ordenadas con OL y las desordenadas con UL, las citas con Q (cita en línea) o BLOCQUOTE (cita en bloque), etc. Debemos usar todos estos elementos según el tipo de contenido y de acuerdo a la especificación. Nunca debemos basarnos únicamente en características presentacionales para diferenciar los contenidos. Por ejemplo, en vez de usar un párrafo y estilos para simular un encabezado (letra grande y en negrita) usaremos el elemento de encabezado correspondiente. 2.1.12

RCG12 - Emplear un único encabezado de nivel superior

Los documentos se deben estructurar adecuadamente en diferentes secciones, capítulos, apartados, etc., con los elementos de encabezado de HTML (H1-H6) sin saltarse niveles intermedios. El encabezado de mayor nivel es el H1, por el que se debe comenzar y en el que se proporciona un título principal que identifique el contenido de todo el documento. El uso de varios encabezados de nivel H1 no es incorrecto desde un punto de vista gramatical pero no es adecuado semánticamente. Si existen varios encabezados de nivel superior es porque tienen "algo" en común que los engloba y, por tanto, ese "algo" debería ser el encabezado de mayor nivel. 2.1.13

RCG13 - Código correctamente estructurado y jerarquizado

El código (X)HTML debe estar correctamente estructurado y jerarquizado, usando los elementos adecuados para cada ocasión tanto desde un punto de vista estructural como semántico. No debemos usar elementos con un propósito diferente del que tienen en la especificación y usaremos aquellos que sean los más apropiados para cada contenido. Así, un párrafo lo marcaremos con el elemento P, en vez de con saltos de línea (BR) o con el elemento genérico DIV. En (X)HTML se pueden usar los elementos genéricos DIV y SPAN para marcar contenido que no se puede describir con otros elementos más significativos (con mayor carácter semántico). Sin embargo, debemos evitar caer en la "divitis" o abuso de los elementos contenedores con carácter genérico. Este abuso puede deberse a una carencia del correcto marcado estructural y semántico (usar DIV en vez de P, o SPAN y estilos en vez de elementos más adecuados como EM o STRONG). También puede tener su origen para delimitar contenido de forma innecesaria (p.e, usar DIV para identificar un menú de navegación, pudiendo hacerlo sobre un elemento ya existente, como el elemento de lista UL).

7

2.1.14

RCG14 - Nombres de clases e identificadores significativos

Los nombres de las clases e identificadores de los elementos deben indicar su función y no escogerse en base a características de presentación. De esta forma aseguraremos una completa separación entre contenido y presentación y facilitaremos la mantenibilidad del código. Por ejemplo, si definimos una clase con el nombre .menurojo para un menú de navegación que se muestra en rojo, y más adelante tenemos que cambiar el color a azul, se producirá una inconsistencia entre el nombre de la clase y el estilo mostrado. Por tanto, si usamos nombres significativos según el contenido y no según la presentación, por ejemplo .menusecundario, evitamos este tipo de problemas. 2.1.15

RCG15 - Usar únicamente HTML para el contenido

El contenido debe incluirse en el código (X)HTML y no debemos generarlo desde las hojas de estilo o con lenguajes de script. De esta forma aseguramos que, aunque no se soporten estas tecnologías, todo el contenido está presente en el documento. Por ejemplo, si vamos a generar texto o imágenes desde las hojas de estilo (con propiedades como backgroung-image, list-style, content, pseudo-elementos :before y :after, etc.) debemos tener en cuenta que debe ser únicamente con fines decorativos, sin aportar información o, en su defecto, deben disponer de la adecuada alternativa en el código (X)HTML para cuando no se soporten las hojas de estilo.

2.2 Código CSS 2.2.1 RCG16 - Código (CSS) válido gramaticalmente De igual forma que debemos comprobar la validez de los documentos (X)HTML también debemos validar las hojas de estilo según la especificación. Validar las hojas de estilo no solo permite encontrar errores sintácticos y usos incorrectos de CSS que pueden provocar problemas de maquetación o inconsistencias entre navegadores, sino que también permite identificar problemas potenciales de accesibilidad o de usabilidad.

Se debe comprobar la corrección de las hojas de estilo validándolas con alguna de las herramientas disponibles, como el servicio de validación (http://jigsaw.w3.org/css-validator/ ) proporcionado por el W3C.

2.2.2 RCG17 - Usar únicamente CSS para la presentación Debemos usar únicamente las hojas de estilo para controlar la presentación y la maquetación de los documentos, en lugar de elementos y atributos (X)HTML de presentación o de imágenes decorativas o de maquetación (espaciadoras) incluidas en el código (X)HTML. La utilización de hojas de estilo, especialmente las externas, para separar el contenido de la presentación proporciona importantes ventajas, como una mayor facilidad para modificar 8

el estilo de un sitio Web, un mantenimiento más sencillo o un código más claro y compacto que reduce los tiempos de carga. 2.2.3 RCG18 - Ausencia tablas de maquetación Una maquetación sin tablas facilita el mantenimiento del código, mejora la indexación de los documentos al producir un código más limpio y fácil de entender por los buscadores y mejora la accesibilidad, al facilitar la lectura a los lectores de pantalla y aumentar la semántica del documento. La finalidad de las tablas es la de proporcionar datos tabulares, de forma que emplearlas como herramienta de maquetación va contra su propósito original y, por tanto, en perjuicio de la semántica del documento. 2.2.4 RCG19 - Usar CSS para imágenes decorativas En ocasiones las imágenes tienen una función únicamente decorativa o como mero instrumento de ayuda para la maquetación de los sitios Web, sin aportar ningún tipo de información y/o funcionalidad para los usuarios. Aquellas imágenes que no aporten un contenido necesario para el buen funcionamiento o comprensión de la página o el sitio Web, es decir aquellas cuya finalidad pueda considerarse puramente decorativa, deben incluirse como fondos mediante las hojas de estilo o, en el caso de aquellas imágenes cuya única finalidad es la realización de efectos de maquetación o posicionamiento de elementos, deben ser sustituidas por las propiedades de estilo correspondientes. 2.2.5 RCG20 - Hacks correctamente identificados, documentados y diferenciados En ocasiones los navegadores tienen incompatibilidades entre sí a la hora de interpretar las propiedades de las hojas de estilo empleadas. Esto es debido a que el soporte del estándar es insuficiente o incorrecto en algunos de ellos. Para solventar estas inconsistencias y lograr que el contenido se visualice correctamente en todos los navegadores a veces se emplean trucos en las hojas de estilo, denominados comúnmente hacks o filtros CSS. Los hacks pueden ser de varios tipos, siendo algunos de ellos poco respetuosos con el estándar mientras que otros respetan la sintaxis de las hojas de estilo. Lo recomendable es no usar hacks o usar el menor número posible de ellos, pero si los usamos debemos usar aquellos que no impidan la validación de las hojas de estilo. Asimismo, no debemos usar hacks a no ser que estemos seguros que nos encontramos ante un bug conocido y documentado. Muchas veces se emplean hacks para arreglar problemas de visualización que no se corresponden con un problema real de interpretación de las hojas de estilo. Es también conveniente que los hacks estén debidamente identificados y documentados mediante comentarios (si puede ser, adjuntando direcciones URL donde se expliquen en detalle). De esta forma serán reconocibles y podrán tratarse de forma oportuna, tanto para modificar las hojas de estilo como para eliminar dichos hacks cuando el soporte de los estándares por parte de los navegadores lo permitan.

9

Tabla con algunos de los filtros CSS más conocidos y su funcionamiento en diferentes navegadores y versiones: http://centricle.com/ref/css/filters/

2.2.6 RCG21 - Evitar propiedades propietarias de CSS Algunos navegadores incorporan propiedades de CSS que no están en ninguna versión final de la especificación. Las propiedades de estas extensiones pueden ser específicas del navegador o bien estar basadas en versiones en desarrollo de la especificación de CSS. Por ejemplo, algunas propiedades CSS propietarias del navegador Mozilla Firefox (que comienzan con el prefijo -moz-, por ejemplo -moz-opacity) se basan en propiedades de la futura especificación de CSS 3. Por otra parte, la propiedad filter del navegador Internet Explorer es específica de este navegador y no es conforme al estándar actual o futuro. Estas propiedades, al ser propietarias, provocan que el código no valide según las especificaciones y que las hojas de estilo no se interpreten de forma consistente entre navegadores. Sólo son reconocidas por los navegadores correspondientes. 2.2.7 RGC22 - Estructurar y jerarquizar el código Usar hojas de estilo correctamente estructuradas, organizadas y comentadas, así como emplear propiedades y selectores de forma coherente aprovechando las propiedades de las hojas de estilo, facilita su legibilidad y el futuro mantenimiento. A continuación se dan algunas recomendaciones básicas para ayudarnos a estructurar y organizar el código. □ Organizar los estilos según sus características: a. En varias hojas de estilo para separar los estilos genéricos aplicables a todo el sitio web de aquellos específicos para plantillas o secciones. b. Dentro de la misma hoja de estilos, en diferentes secciones. Por ejemplo, según la maquetación (cabecera, contenido, pie), el tipo de contenido (listas, formularios, texto, tablas), etc., e incluso una combinación de agrupaciones. □ Agrupar selectores con estilos similares y aprovechar el poder de la cascada en CSS (http://www.w3.org/TR/CSS21/cascade.html). Cuando tengamos varios selectores que compartan las mismas propiedades debemos agruparlos para no repetirlas varias veces en las hojas de estilo. Si alguno de los selectores necesita un estilo específico adicional lo especificaremos aparte. □ Aprovechar el poder de la herencia de las propiedades de CSS, definiendo estilos básicos en algunos elementos que se reaprovecharán en aquellos elementos que hereden sus propiedades. Por ejemplo, al igual que el tipo de fuente se puede definir

10

para BODY y será aplicable a todo el documento (redefiniéndose sólo cuando sea necesario) también podemos aprovechar la herencia de otras propiedades. □ Usar selectores contextuales (descendientes) siempre que sea posible en vez de abusar de identificadores (id) y nombres de clase. El uso de selectores contextuales (incluso los más largos) facilita la lectura de las hojas de estilo y permite reducir el uso de clases, identificadores, etc. Por ejemplo, para aplicar estilos a partir del segundo nivel de elementos de una lista anidada, en vez de usar clases o identificadores se puede usar el selector contextual: li li. □ Usar notaciones abreviadas para definir grupos de propiedades relacionadas (márgenes, paddings, fuente, etc) Así, por ejemplo, en vez de usar (margin-top: 1em; margin-right: 0; margin-bottom: 2em; margin-left: 0.5em;) se puede usar (margin: 1em 0 2em 0.5em;). □ Usar comentarios en las hojas de estilo que ayuden a identificar y separar las diferentes secciones empleadas, así como para comentar técnicas o hacks empleados. 2.2.8 RCG23 - Usar ficheros externos para las hojas de estilo Para aprovechar todas las ventajas de las hojas de estilo en cuanto a separación de estructura y presentación debemos usar hojas de estilo externas en vez de estilos en línea (atributo style) o estilos incluidos en la cabecera de los documentos (elemento STYLE) Los estilos incluidos en línea o en la cabecera de los documentos dificultan el mantenimiento, ya que no se pueden modificar simultáneamente para todo el sitio Web, teniendo que hacer las modificaciones de forma individual para cada documento. Además, los estilos incluidos en el documento aumentan el tamaño de los mismos y, por tanto, el ancho de banda consumido y el tiempo necesario para descargarlos. Sólo deberíamos emplear estilos en línea para estilos que sean una excepción al estilo general del sitio y de la página. 2.2.9 RCG24 - Emplear códigos numéricos para la definición de colores en lugar de palabras clave Los colores en las hojas de estilo se pueden definir mediante especificaciones numéricas RGB (por ejemplo #FF0000 para el rojo) o bien mediante palabras clave (red para el color rojo). Siempre es mejor emplear una especificación numérica, en cualquiera de sus notaciones, que palabras clave ya que es posible que algunos navegadores no comprendan las palabras clave usadas o no las interpreten correctamente.

11

2.3 Scripting 2.3.1 RCG25 – Seguir el estándar EcmaScript El lenguaje JavaScript lo introdujo el navegador Netscape como una tecnología propietaria para permitir incorporar funcionalidad e interacción en los sitios Web y destacarse así del resto de navegadores de la época. Posteriormente, cada navegador incorporó su propia versión del lenguaje de scripts de cliente (por ejemplo JScript de Internet Explorer) basados en JavaScript pero con diferencias significativas lo que generó grandes problemas de incompatibilidades entre navegadores. Para intentar solucionar todos estos problemas, en 1998 la organización ECMA (European Computer Manufacturers Association), cuyo fin es estandarizar el uso de las Tecnologías de Información y Comunicación, creó una especificación de dominio público basada en JavaScript y JScript pero con algunas características de los lenguajes orientados a objetos y basándose en el estándar DOM (Modelo de Objetos de Documento) para la manipulación de los documentos. Actualmente, la gran mayoría de navegadores incluyen una implementación de ECMAScript y del Modelo de Objetos de Documento. Aunque cada navegador tenga su propia versión de lenguaje de Script (JavaScript, JScript, etc.) o añada extensiones propias a ECMAScript, todo el código realizado en el estándar ECMAScript funcionará correctamente en los navegadores que lo soporten.

Standard ECMA-262 ECMAScript Language Specification 3rd edition (December 1999) http://www.ecma-international.org/publications/standards/Ecma-262.htm

2.3.2 RCG26 - Scripting no intrusivo De igual forma que separamos estructura y presentación eliminando todos los elementos y atributos de presentación del código (X)HTML y sustituyéndolos por sus propiedades equivalentes en las hojas de estilo, deberemos también usar scripting no intrusivo separando la capa de comportamiento al trasladar todo el código de scripting a ficheros externos. Para lograr esta separación entre estructura (HTML), presentación (CSS) y comportamiento (scripts) debemos evitar también las llamadas a funciones de script desde eventos directamente en el código (X)HTML (onload, onclick, onmouseover, etc.). Si mantuviésemos estos eventos en el código (X)HTML necesitaríamos cambiar todos los documentos donde se llamase a una función que queramos renombrar. Usando el Modelo de Objetos de Documento (DOM) podemos manipular el código (X)HTML para seleccionar el elemento adecuado y generar dinámicamente el evento con la llamada a la función correspondiente.

12

Mantener todos los scripts totalmente independientes del código (X)HTML permite aplicarlos a cualquier página del sitio Web sin tener que modificar el código de las mismas.

Más información sobre JavaScript no intrusivo: http://www.onlinetools.org/articles/unobtrusivejavascript/ http://www.disenorama.com/articulos/dhtml-no-intrusivo http://icant.co.uk/articles/from-dhtml-to-dom/

2.3.3 RCG27 - Usar DOM para la manipulación de la jerarquía del documento El DOM o Modelo de Objetos de Documento (http://www.w3.org/DOM/) es un interfaz (API) en un lenguaje neutro definido por el W3C para permitir que programas y scripts puedan acceder y modificar dinámicamente el contenido, estructura y estilo de los documentos. En el DOM se representan los documentos como una estructura de árbol. Cada parte del documento (texto, elementos, atributos) está representada en los nodos del árbol. Existen métodos que permiten obtener cualquier elemento y sus atributos, modificarlos, eliminarlos, navegar por el árbol desde ellos y crear nuevos nodos con nuevos elementos. Es decir, usando DOM podemos manipular de forma dinámica contenido estructurado en documentos (por ejemplo, usando lenguajes como ECMAScript) y es el medio fundamental para la creación de scripts no intrusivos. 2.3.4 RCG28 - Usar scripting únicamente para el comportamiento Los scripts deben respetar la separación entre estructura, presentación y comportamiento. Esta separación no sólo implica una separación “física” del código, sino también una clara diferenciación en la función de cada una de las capas. Los scripts, además de no incluirlos en el código (XH)TML, deben usarse únicamente para añadir comportamiento a los sitios web con el objetivo de mejorar la experiencia de los usuarios. No usaremos los scripts para generar contenido, el cual debe estar siempre disponible en el código (X)HTML sin depender de la ejecución de los scripts para mostrarse correctamente. Tampoco los usaremos para definir características de la presentación, dejando esta tarea para las hojas de estilo. De igual forma, no debemos usar los scripts para añadir lógica de aplicación compleja, ni lógica simple que no tenga su adecuada alternativa para cuando no exista soporte de estas tecnologías. 2.3.5 RCG29 - Scripting como mejora progresiva Todo el contenido y funcionalidad básica de los documentos debe estar disponible cuando no se soporten los scripts, aunque se presenten de forma diferente a la original. Estas tecnologías deben considerarse como una mejora, no como un requisito, de

13

forma que los documentos se muestren y funcionen correctamente cuando no estén soportadas. Para lograr este objetivo, debemos empezar con el documento en (X)HTML plano en el que incluiremos todo el contenido de forma que tenga sentido y funcione correctamente sin scripting. Sobre ese contenido iremos añadiendo progresivamente scripting no intrusivo para añadir funcionalidades que mejoren la experiencia de los usuarios. Como inicialmente el contenido y la estructura es ya la correcta, si eliminamos los scripts solo perderemos la capa de comportamiento, pero el contenido original permanecerá intacto. Este método se denomina Mejora Progresiva ya que estamos mejorando la funcionalidad de la página de forma progresiva en base al soporte de los agentes de usuario de las tecnologías empleadas (en este caso, scripts). 2.3.6 RCG30 - Detección de objetos en vez de detección de navegador para probar el soporte de capacidades Para evitar errores de programación y aplicar de forma segura scripts como mejora progresiva usando el Modelo de Objetos de Documento debemos asegurarnos de que los navegadores lo soportan. En vez de usar el método antiguo de detección del navegador (con document.all, document.layers, navigator.userAgent) debemos usar la detección de objetos. Técnicamente significa que antes de usar algún objeto comprobamos primero si está soportado por el navegador, en vez de intentar averiguar cuál es el navegador usado y usar versiones diferentes del código para cada caso. Por tanto, la detección de objetos es independiente del navegador, mientras que la detección del navegador funciona sólo con los navegadores detectados y puede depender de las versiones. Al usar la detección de objetos comprobamos primero si los navegadores soportan el Modelo de Objetos de Documento (por ejemplo, comprobando que se soporta el método getElementById) y luego comprobaremos el soporte de los objetos a usar.

Ejemplo: if(document.getElementById && document.createTextNode){ /* Código a ejecutar */ }

Si no se soportan los objetos el script no se ejecutará y se mostrará el documento original. 2.3.7 RCG31 - Evitar document.write La función document.write escribe contenido directamente en el documento y para usarse debe estar mezclada con el código (X)HTML. Por tanto, su uso va en contra de los principios del scripting no intrusivo. En vez de usar document.write debemos usar el Modelo de Objetos de Documento para obtener el elemento que queramos modificar, por ejemplo mediante getElementById o 14

getElementsByTagName, e insertar el nuevo contenido creado con createElement o createTextNone.

Únicamente se podría aceptar el usar esta función en circunstancias excepcionales cuando no queramos dejar rastros de código que sólo debe ejecutarse cuando hay soporte de scripts y sólo si aporta ventajas significativas a su inclusión mediante DOM. Por ejemplo, para incluir en un documento extenso un elemento LINK con estilos que sólo deben ejecutarse si hay soporte de scripts (p.e. ocultar parte del contenido) de forma que si se incluyesen mediante DOM tardarían en aplicarse (cuando acabase de cargarse el documento). 2.3.8 RCG32 - Ausencia del pseudo-protocolo javascript: Los enlaces para vincular unos documentos con otros utilizan protocolos de Internet (mailto:, ftp:, http:), pero entre estos no existe ningún protocolo javascript:. Además de que no se trata de un protocolo real, si usamos javascript directamente en el atributo href de los enlaces estos dejarán de ser funcionales cuando no se soporte javascript. Por tanto, para asegurar la accesibilidad del código, su respeto por los estándares y el uso de javascript no intrusivo, no debemos usar el pseudo-protocolo javascript:. 2.3.9 RCG33 - Evitar NOSCRIPT El elemento NOSCRIPT permite a los desarrolladores proporcionar una alternativa para cuando no se ejecuten los scripts, porque no estén soportados o porque se encuentren desactivados. En teoría, es un mecanismo útil para asegurar una degradación adecuada del contenido. Es decir, se proporcionan opciones alternativas para aquellos navegadores que no soportan los scripts. Sin embargo, existen problemas de compatibilidad del elemento NOSCRIPT con algunas ayudas técnicas. Algunos lectores de pantalla no leen el contenido de este elemento, incluso cuando no existe soporte de javascript. Por tanto, debemos evitar usarlo para asegurar el correcto funcionamiento de los documentos empleando la mejora progresiva en vez de proporcionando alternativas diferentes.

2.4 Interoperabilidad 2.4.1 RCG34 - Contenido en un orden lógico El contenido de los documentos dentro del código (X)HTML debe seguir un orden lógico coherente. No debemos basar el orden lógico únicamente en la presentación de los contenidos, según la disposición y maquetación realizada mediante hojas de estilo, ya que cuando éstas no se soporten (porque estén desactivadas, sean malinterpretadas o se hayan sobrescrito por las hojas de estilo de usuario) se perderá el orden lógico y, por tanto, la legibilidad. Asimismo, la secuencia lógica de navegación mediante el tabulador debe permitir acceder a todos los enlaces y controles de formulario en el orden correcto.

15

2.4.2 RCG35 - Código compatible multinavegador Para asegurar la interoperabilidad debemos cerciorarnos de que nuestras páginas y sitios Web son compatibles con los navegadores y agentes de usuario más comunes, en diferentes versiones y sobre distintas plataformas y sistemas operativos. El uso adecuado de los estándares, verificando la validez del código usado tanto (X)HTML, CSS como JavaScript, facilitará la compatibilidad entre navegadores. 2.4.3 RCG36 - Maquetación adaptable a distintas resoluciones Debido a la variedad de dispositivos de acceso a la Web existentes, y la variabilidad de configuraciones disponibles en cada dispositivo, es imposible conocer con exactitud las características de configuración de nuestros usuarios. Por este motivo es preferible que se utilicen diseños fluidos o flexibles utilizando, en la medida de lo posible, unidades relativas que permitan la adaptación de los contenidos a distintas configuraciones sin que haya necesidad de realizar desplazamiento horizontal para acceder a los contenidos y además no se produzcan solapamientos que impidan el acceso a la información. 2.4.4 RCG37 - Maquetación adaptable al redimensionamiento del texto sin romperse o volverse ilegible Debemos permitir el redimensionado del texto según las necesidades de los usuarios. Para ello expresaremos el tamaño de los textos en unidades relativas para facilitar su redimensionamiento (%, em ó ex). También debemos usar unidades relativas en todas aquellas características que afecten directamente al texto, tales como la altura de línea, el espaciado entre letras y la indentación para que mantengan la coherencia cuando se produzca el redimensionamiento. La maquetación del sitio deberá adaptarse adecuadamente a los diferentes tamaños del texto, de forma que no se produzcan desbordamientos o solapamientos del contenido que dificulten o impidan su percepción. 2.4.5 RCG38 - Contenido adaptable a la impresión Al proporcionar la información de forma que se ajuste a las preferencias de los distintos usuarios, medios de interacción y dispositivos, también debemos tener en cuenta la impresión de los documentos. Debemos adaptar los contenidos para su correcta impresión. Sólo deberíamos imprimir la información principal de cada documento, eliminando todo aquel contenido que sólo es útil para la Web y no para impresión, como cabeceras, menús de navegación, anuncios, etc. La adaptación de los contenidos la podemos realizar mediante las hojas de estilo de impresión (medio print).

16