Uninstallme
Desarrollo front-end, estándares web, accesibilidad y más
Cuestionando los diseños elásticos
Por kcmr, el 17 de julio de 2010 en Accesibilidad, CSS, Usabilidad
Until user agents…
Quienes suelan consultar las WCAG (Web Content Accessibility Guidelines), tendrán esta frase grabada en la memoria: Hasta que los agentes de usuario permitan…
. Pues bien, estoy segura de que con la lenta agonía de Explorer 6, muchos nos habremos preguntado hasta qué punto tiene sentido seguir utilizando unidades relativas para los tamaños de fuente, ya que el resto de navegadores no tiene problemas para escalar fuentes cuando su tamaño ha sido expresado en píxeles. ¿Correcto? Pues no.
Internet Explorer no escala las fuentes en píxeles
Hace relativamente poco tiempo descubrí algo que desconocía por completo: ninguna versión de Internet Explorer escala las fuentes cuyo tamaño ha sido expresado en píxeles:
Es fácil no darse cuenta de este detalle porque cuando utilizamos la combinación de teclas Ctrl + o Ctrl – en Explorer (versiones superiores a la 6), activamos el zoom de página con resultados aparentemente similares a los que obtendríamos aumentando el tamaño de fuente, por lo tanto, sigue teniendo sentido utilizar unidades relativas para los tamaños de fuente.
Zoom de página y escalado de texto
Ahora bien, ¿hasta qué punto es correcto utilizar unidades relativas para todo? La mayoría de navegadores actuales, <ironia>excepto Explorer 6</ironia>, nos proporcionan inteligentemente dos formas de zoom: zoom de página completa o ampliar sólo texto.
Escalado de texto en Firefox
Google Chrome y Opera sólo proporcionan zoom de página completa. Parece que a algunos usuarios de Chrome están algo descontentos: Need a text-only Zoom.
Teniendo en cuenta que la resolución mayoritaria, en portátiles y ordenadores de sobremesa, sigue siendo de 1024, y que las páginas se diseñan para esta resolución, en el momento en que hacemos zoom de página completa aparecen las molestas barras de scroll horizontales.
Si nuestro diseño es elástico, es decir, los tamaños de bloques contenedores se expresan en emes, estamos rompiendo la capacidad del navegador de ampliar sólo texto o hacer zoom de página, ya que al ampliar sólo texto aumentarán también los tamaños de bloques con las consecuentes barras de scroll horizontales, y si hay algo cierto, es que a nadie le gusta el scroll horizontal.
“Low-vision users don’t like horizontal scrolling.” I’ve not done extensive research in this area myself, so it’s hard to counter-argue. Besides, it’s safe to say nobody — good vision or not — likes horizontal scrolling.
We found during usability testing for a site with a large proportion of users with vision problems that most of them preferred to use text zoom instead of page zoom because page zoom almost always means horizontal scrolling.
¿La mejor elección de diseño?
Quizá el diseño perfecto sea el híbrido líquido-elástico (vaya nombrecito), pero es difícil de llevar a cabo y no está libre de problemas. Opera y Webkit (Safari / Google Chrome) comparten un bug: ignoran los decimales en porcentajes. (Demo del bug). Explorer tampoco se lleva especialmente bien con los porcentajes.
CSS 3 nos brinda nuevas posibilidades que nos permiten adaptar el diseño en función de la resolución de pantalla, las Media Queries, opción que podemos usar ya para los navegadores que pueden beneficiarse de ello, especialmente para iPhone y otros dispositivos móviles.
Mi elección
Personalmente, llevo una temporada utilizando la opción de expresar los tamaños de bloques en píxeles y los de fuentes en emes, siendo consciente de que el uso de píxeles está penalizadísimo, tanto por revisores automáticos de accesibilidad como humanos, e incluso diría que mal visto entre maquetadores, pero las “normas” siempre hay que cuestionárselas para llegar a mejoras. Como ejemplo, muchas de las pautas que se cuestionaban de las WCAG 1 en las Samuray Errata, se han modificado en las WCAG 2.
Qué dicen las WCAG
En las WCAG no se dicta una opción concreta a utilizar en cuanto a tipo de diseño, simplemente se ofrecen unas pautas y una serie de técnicas para ayudarnos a conseguirlas. Algunas de estas técnicas:
- Using percentage values in CSS for container size
-
The objective of this technique is to make it possible for users who need to increase the size of text in order to read it will not have to scroll horizontally in order to read a line of text.
- Using relative measurements to set column widths so that lines can average 80 characters or less when the browser is resized
-
The purpose of this technique is to ensure that CSS is used in a way that allows users to view content in such a way that line length can average 80 characters or less. [...] This technique also allows for column width to grow wider as font sizes increase, which will reduce the possibility of clipping as the text size increases..
En ningún momento se propone la técnica de usar unidades absolutas para contenedores, sino más bien todo lo contrario. Si no me equivoco, tampoco se prohibe o desaconseja expresamente el uso de píxeles para contenedores, simplemente se insiste en que el texto pueda escalarse sin que aparezca cortado y a ser posible, sin que sea necesario utilizar el scroll horizontal para leer una línea completa.
Conclusión
Ahí están los problemas de los diseños elásticos y algunas de las recomendaciones para cumplir con las pautas de accesibilidad para que cada uno elija la opción más apropiada, teniendo siempre en cuenta el púbico objetivo de una web y las capacidades de los navegadores más usados en cada momento.
Más información
Uso útil de pseudoprotocolos en enlaces javascript
Por kcmr, el 16 de mayo de 2010 en Accesibilidad, Buenas ideas, Javascript, Usabilidad
El uso del pseudoprotocolo (href="javascript:nombreFuncion();") en enlaces es una mala práctica de acuerdo con las normas del Javascript no intrusivo. Los enlaces deben tener una url válida que funcione sin Javascript. Por ejemplo, un enlace que abre una popup debe tener una url en su atributo href, de manera que sin Javascript siga siendo un enlace válido.
Pero no todos los enlaces que ejecutan alguna función Javascript tienen que tener una url en su atributo href. Algunos sirven para realizar acciones dentro de la propia página, como puede ser mostrar / ocultar una capa, pasar a la imagen siguiente en un carrusel, etc.
En estos casos, lo correcto es crear esos enlaces con Javascript, ya que sólo con Javascript habilitado tienen sentido (no deben estar previamente en el código HTML), y asignarles como atributo href una almohadilla (#) o dejarlo vacío.
En algún blog que no consigo encontrar proponían usar para este tipo de enlaces el pseudoprotocolo javascript: u otro que consideremos más apropiado (inventado), como podría ser imagen:.
De esta forma, estos enlaces proporcionan información acerca de su función al hacer rollover sobre ellos o cuando tienen el foco. Esta información suele aparecer en la barra de estado del navegador. También es útil para usuarios de lectores de pantalla que puedan tenerlos configurados para no leer el atributo title.
Atributo href del enlace mostrado en la barra de estado de Firefox
Habrá quien se preguntará si es correcto asignar este tipo de funciones a enlaces en lugar de a otros elementos HTML. La respuesta es que sí, ya que los enlaces pueden tener de forma natural el foco y ser activados cuando se utiliza el teclado para navegar y moverse por la página.
Iniciar o detener Flash desde HTML con Javascript
Por kcmr, el 27 de julio de 2009 en Accesibilidad, HTML, Javascript, flash
Etiquetas: Accesibilidad, flash
Es una buena práctica, sobretodo cuando se usan vídeos o animaciones flash que contengan sonido, el dejar la reproducción de la película en manos del usuario en vez de iniciarla automáticamente.
Las veces que esto se cumple se suele hacer colocando un control en la propia película flash, como un icono de Play o similar semitransparente.
El uso exclusivo de este método puede suponer un problema para usuarios de navegadores que no sean Internet Explorer y no utilicen ratón, ya que los flashes no pueden recibir el foco mediante teclado a no ser que se activen previamente con el ratón.
Incluir además unos enlaces en HTML para iniciar o detener la reproducción de Flash supondría una pequeña mejora de accesibilidad para estos usuarios.
Los pasos que hay que seguir para conseguirlo son:
- Dar un ID al object que contiene el Flash
- Detener la reproducción automática de la animación:
- Si la animación está en la línea de tiempo principal basta con usar el parámetro play con el valor false en el HTML
- Si la animación está en otra línea de tiempo tendremos que detenerla en el propio flash mediante un nombreDeInstancia.stop() en la línea de tiempo principal.
- Asignar la función de iniciar / detener a los enlaces correspondientes en HTML
Ejemplos de los dos casos
Object película Flash con animación en la línea de tiempo principal
HTML del flash
<object width="155" height="17" id="ejemplo-1" type="application/x-shockwave-flash" data="ejemplo.swf">
<param name="src" value="ejemplo.swf" />
<param name="play" value="false" />
</object>
Controles HTML (lo ideal para una degradación elegante sería pintarlos con Javascript, ya que sólo con Javascript habilitado pueden funcionar)
<ul id="controles-1">
<li><a href="#">Iniciar reproducción</a></li>
<li><a href="#">Pausar reproducción</a></li>
</ul>
Javascript
var control1 = document.getElementById('controles-1').getElementsByTagName('a');
control1[0].onclick = function(){
document.getElementById('ejemplo-1').Play();
return false;
}
control1[1].onclick = function(){
document.getElementById('ejemplo-1').StopPlay();
return false;
}
Demo
Object película Flash con animación en una línea de tiempo distinta a la principal
HTML del flash
<object width="165" height="48" id="ejemplo-2" type="application/x-shockwave-flash" data="ejemplo-2.swf">
<param name="src" value="ejemplo-2.swf" />
</object>
Javascript
En este caso, para iniciar o detener la animación tendremos que usar los métodos TPlay("ruta_a_linea_tiempo") y TStopPlay("ruta_a_linea_tiempo")
var control2 = document.getElementById('controles-2').getElementsByTagName('a');
control2[0].onclick = function(){
document.getElementById('ejemplo-2').TPlay("_root/mc_barra");
return false;
}
control2[1].onclick = function(){
document.getElementById('ejemplo-2').TStopPlay("_root/mc_barra");
return false;
}
Demo
Existen otros métodos predefinidos útiles para controlar la reproducción de una película Flash, como Rewind() o GotoFrame()
Aprovecho este post para recomendar un par de recursos que pueden sernos de gran utilidad a la hora de mejorar la accesibilidad de vídeo Flash (ya que por la página de recursos no se pasa ni GOOGLE):
- JW Player Controls
- Reproductor de Flash Vídeo que permite controlar la reproducción mediante teclado, añadir subtítulos y descripciónes de audio y además añade los atributos apropiados ARIA. Utiliza JW FLV Player junto con un plugin de accesibilidad. Los controles javascript se proporcionan mediante la librería Dojo.
- Ejemplos de control del reproductor JW Player mediante Javascript
- Varios ejemplos de control de la reproducción de contenido multimedia mediante Javascript usando JW Player.
Más información
Habilitar el botón volver del navegador en aplicaciones AJAX
Por kcmr, el 16 de abril de 2009 en Accesibilidad, Javascript, Usabilidad
Etiquetas: ajax, Javascript, RIA's, Usabilidad
Acabo de descubrir varios script que hacen posible, tanto la navegación “normal” mediante el botón volver del navegador, como el añadir páginas a los favoritos o marcadores en aplicaciones AJAX. Una solución a dos de los grandes problemas de usabilidad que presentan este tipo de aplicaciones.
Dejo cuatro enlaces rápidos:
- HistoryManager. Funciona con Mootools.
It solves the typical “Back-Button” and “Ajax Bookmarks” problems for accessible browsing and a better usability in Rich Internet applications.
- Versión de HistoryManager para Prototype.
- History Keeper. No utiliza ninguna librería.
- UpdateControls: UpdateHistory and AnimatedUpdatePanel. Para ASP.NET AJAX.
Un bookmarklet para superar el CSS Naked day
Por kcmr, el 9 de abril de 2009 en Accesibilidad, Buenas ideas, Utilidades
Etiquetas: Accesibilidad, bookmarklets, legibilidad, tipografía, Usabilidad
Yo también me he sumado a esta iniciativa de dejar la web en pelotas, que pretende promover el correcto uso de Estándares Web y marcado semántico. Es el CSS Naked Day.
Me tengo que decir eso de “bueno, un día es un día” para tener la conciencia más tranquila, ya que aunque todo permanece perfectamente utilizable y comprensible sin estilos, la verdad sea dicha… resulta bastante incómodo de leer.
Una buena forma de superarlo, sobretodo cuando tenemos verdadero interés en leer algo, cosa que debe de ocurrir sólo durante un 5% del tiempo en que navegamos, es utilizar un bookmarket que aplica los estilos necesarios para mejorar la legibilidad a la parte de la página que contiene el contenido relevante, ocultando todos los demás elementos que pueden distraer la lectura, como banners, menús de navegación, etc. Se trata de Readability. En su web podemos elegir el estilo que más nos gusta entre varias opciones y una vez configurado, añadir el marcador al navegador.
Es un bookmarklet bastante útil y cómodo, no sólo para superar el día de hoy, sino para cuando nos encontramos con un tamaño de texto diminuto o longitud excesiva de líneas, dos cosas que dificultan y hacen poco apetecible la lectura.
Flash navegable mediante teclado en Firefox
Por kcmr, el 3 de marzo de 2009 en Accesibilidad, Buenas ideas, Navegadores
Etiquetas: Accesibilidad, flash
Sí Flash ya es de por sí bastante problemático en cuanto a accesibilidad se refiere, en Firefox tiene una dificultad añadida: no se puede acceder a su contenido mediante teclado. Para navegar por los elementos de un flash en Firefox necesitamos clicar el flash. Una vez que hemos entrado ya no podemos salir usando el teclado, la tabulación queda atrapada en el flash. La buena noticia es que si hemos podido entrar en el flash, se supone que sólo hemos podido hacerlo mediante ratón, por lo que también se supone que también podremos salir del flash usando el ratón, a no ser que justamente decida fallar en ese preciso momento. En cualquier caso, este comportamiento de Flash en Firefox hace que sea dependiente de dispositivo.
No ocurre lo mismo en Internet Explorer, en el que sí podemos entrar y salir del Flash mediante teclado. Podemos imitar el comportamiento de Flash en Internet Explorer mediante Javascript y Actionscript. En el siguiente ejemplo tenemos un flash al que podemos acceder mediante teclado en Firefox, navegar por sus elementos y salir de él.
Para conseguir esto se han seguido los siguientes pasos:
- Dar un tabindex con valor 0 al object que contiene el flash.De esta manera conseguimos que pueda tener el foco en Firefox. El valor 0 permite que el objeto permanezca en el orden de tabulación en que aparece en la página, es decir, no se altera el orden de navegación de otros elementos. Debemos hacerlo mediante Javascript, porque sin él, podríamos entrar mediante teclado al flash pero no podríamos salir.
- Permitir la comunicación del Flash con Javascript.Para esto usamos el parámetro allowscriptaccess de Flash
<param name="allowScriptAccess" value="always" /> - Desde Flash llamamos a la función Javascript encargada de establecer el tabindex, de esta manera, sólo si hay flash se establecerá un tabindex para el object.
- Añadimos para el primer y último elemento navegables del flash una función para el evento onblur (en actionscript llamado onKillFocus) encargada de llamar a la función Javascript que desenfoca el object.
// primer elemento navegable bot_1.onKillFocus = function(newFocus){ if(newFocus == bot_3){ ExternalInterface.call('AccesibleFlash.desenfocaObject', 'test'); } } // último elemento navegable bot_3.onKillFocus = function(newFocus){ if(newFocus != bot_2){ ExternalInterface.call('AccesibleFlash.desenfocaObject', 'test'); } } - Por último, para evitar el “click para activar” en Explorer, se ha usado el método de publicación dinámica del SWFObject.
Descargar todos los archivos del ejemplo, incluido el .fla, en formato .zip
Una buena parte del “cómo conseguirlo” surgió de una cabeza inquieta de mi antiguo curro y creo, que hasta aquí puedo y debo leer.
El debate del H1
Por kcmr, el 8 de febrero de 2009 en Accesibilidad, Cajón de sastre, HTML
Etiquetas: Accesibilidad, curiosidades
Si no teníamos suficiente con el típico debate sobre usar uno o varios encabezados de primer nivel, ahora tenemos otro para la colección: ¿H1 para el título principal de la página o para el logo del sitio?
La cosa llega al extremo de tener su propia web, en la que podemos ver los argumentos y votos dados a través de Twitter (me temo que nunca participaré.)
De momento va ganando la opinión de usar H1 para el título principal de la página. Yo comienzo a pensar que da un poco igual mientras se hayan hecho otras cosas bien, como usar un título (elemento <title>) descriptivo y una jerarquía de encabezados con sentido.
Preferencias y modos de uso de lectores de pantalla
Por kcmr, el 1 de febrero de 2009 en Accesibilidad, Haciendo amigos, Navegadores, Programas
Etiquetas: Accesibilidad, aplicaciones, web 2.0
Hace cosa de un mes, WebAIM comenzaba a hacer una encuesta sobre el uso de lectores de pantalla, con el objetivo de mostrar las preferencias de usuarios reales y dar un poco de luz a los desarrolladores que normalmente nos basamos en suposiciones a la hora de intentar proporcionar páginas accesibles para este tipo de usuarios.
Ayer se publicaban los resultados, tras realizar la encuesta a un total de 1121 usuarios. A continuación muestro un resumen de cada punto que se analizó en la encuesta.
Datos sobre el tipo de usuario
La mayoría de las personas encuestadas eran usuarios habituales de lectores de pantalla (los usan siempre) debido a alguna discapacidad, de entre las que se dan con más frecuencia, están la ceguera o baja visión.
Sólo una pequeña parte de los encuestados, el 8%, se ha declarado usuario principiante, mientras que la mayor parte se considera usuario avanzado.
El programa más usado con clara diferencia es JAWS con un 74%, seguido de Windows Eyes con un 23%. También la mayoría de estos usuarios utilizan la versión más reciente de su programa.
También es muy interesante saber que los usuarios de lectores de pantalla sí personalizan sus programas y cambian las configuraciones por defecto.
Los navegadores más usados son, en primer lugar Internet Explorer 7 con un 68%, seguido de Firefox con un 39% y Explorer 6 con un 33%
Datos sobre el uso de páginas web
¿Qué hacen cuando llegan por primera vez a la home de un sitio desconocido?
La mayoría prefiere leerla entera y otra parte importante prefiere navegar a través de los enlaces de la página.
¿Se usan los links de saltar al contenido y los accesos directos?
En este caso no hay una tendencia que destaque sobre las otras, ya que casi en proporciones iguales se dan los casos en que estos links se usan siempre que existen, se usan a veces, muy raras veces o nunca. Tampoco hay una preferencia clara en cuanto a cuál debería ser el texto del enlace, si bien el 28% prefiere el literal "saltar al contenido principal".
Lo mismo ocurre con las teclas de acceso directo, los accesskeys, aunque en la página nos aclaran que los principiantes en el uso de lectores de pantalla parecen tener más tendencia a usarlas.
Encabezados
En este caso sí que se ve una tendencia clara a navegar por encabezados siempre que están disponibles. Un 52% eligió esta opción y sólo un 7% en total eligieron las opciones de muy raras veces o nunca.
Formularios de búsqueda
La mayoría de los encuestados mostraron tendencia a usarlos o siempre que existen, o con cierta frecuencia, mientras que sólo un 15% dijo usarlos pocas veces o nunca. En WebAIM aprovechan estos resultados para remarcar la importancia, no sólo de proporcionar estos formularios, sino de hacerlo de una forma en la que resulten fáciles de encontrar y usar.
¿Y cómo encuentran el formulario de búsqueda?
La mayoría lo intenta dirigiéndose al primer elemento FORM de la página o al primer cuadro de edición de texto. Una pista clara para saber dónde colocar estos elementos, tan fácil como no intentar reinventar la rueda.
Mapa Web
No parece haber una tendencia clara sobre el uso de los mapas web, si bien se puede extraer la conclusión de que no son muy usados por los usuarios de lectores de pantalla.
¿Se usan las versiones de sólo texto?
En este caso se muestran dos tendencias opuestas: o usarlas siempre que están disponibles o no usarlas casi nunca.
Dificultad de los pop ups
También en este caso los resultados son muy variados. Un 43% en total dice que los pop ups no le resultan muy difíciles, mientras que un 53% parece encontrar dificultades en el uso de pop ups. El análisis detallado de los resultados muestra una relación directa entre la experiencia en el uso de lectores de pantalla y la dificultad que se encuentra en estos elementos, que como es lógico, es mayor en usuarios principiantes de lectores de pantalla.
Accesibilidad de la Web 2.0 y las aplicaciones web dinámicas
Un 54% respondía "no lo sé".
Yo personalmente interpretaría los resultados como "¿Web 2.0? ¿Qué es eso?" y creo sincéramente que la gente de WebAIM le ha echado cierta imaginación al decir que los usuarios de Firefox parecen tener más tendencia a mostrar una respuesta favorable, quizá motivada por el soporte de ARIA en Firefox. Mi opinión es que WAI-ARIA se usa muy minoritariamente y, a pesar de que Firefox tenga soporte, el comportamiento de JAWS ante eventos javascript en este navegador es peor que en Explorer e incluso algo frustrante. Esto es lo yo veo como la triste realidad.
Imágenes decorativas
Aquí aparece un resultado curioso. Las WCAG nos dicen que proporcionemos un alt vacío para las imágenes meramente decorativas, pero los usuarios de lectores de pantalla prefieren mayoritariamente, con un 59%, que sean descritas. Parece que los usuarios más avanzados son los que prefieren encontrar descripciones para estas imágenes, quizá debido a que estos usuarios son más hábiles a la hora de ignorar la información no deseada.
Identificación de fotografías
Para la pregunta "Si la página web contiene una foto de la Casa Blanca, prefiero que la imagen sea identificada como…", un 80% eligió el literal "Foto de la Casa Blanca".
Desde WebAIM nos aclaran que no debemos interpretar este resultado como que todas las imágenes deben ser identificadas como imágenes, es decir, no debemos usar el lireral "Imagen de..", que resulta redundante, ya que el propio lector de pantalla notifica las imágenes como tal.
Identificación de logos
En cuanto al logo con enlace a la home, la mayoría prefiere que sea descrito como "Logo de -nombre del sitio- con enlace a la home".
Parecen ser los usuarios con discapacidades y los más experimentados los que prefieren una descripción más breve.
Múltiples enlaces a distintos sitios con el mismo texto de enlace
Con este tipo de enlaces hacen referencia a los típicos enlaces de "más información" o "ver más" que se repiten a lo largo de una página web.
Casi a partes iguales se dieron las respuestas de encontrar difíciles estos enlaces como encontrarlos fáciles. Nuevamente hay una relación directa entre la experiencia del usuario y la dificultad que encuentra en estos elementos.
Flash
En este caso sí que se ve una tendencia clara a encontrar el contenido Flash difícil o muy difícil. Nada sorprendente.
Marcos
Otra vez nos encontramos a partes iguales con los usuarios que los encuentran fáciles y los que los encuentran difíciles.
En WebAIM nos aclaran que no se hizo distinción entre frames e iframes.
Se vuelve a repetir una igualdad entre usuarios que lo encuentran fácil y usuarios para los que resulta difícil.
Conclusión
La conclusión que se puede sacar de los resultados de la encuesta es que no existe una formula perfecta que pueda satisfacer por igual a la variedad de usuarios que usan lectores de pantalla y es difícil ofrecer recomendaciones definitivas para muchas cosas, si bien hay puntos que parecen quedar muy claros, como la dificultad del uso de Flash o la importancia de proporcionar encabezados que describan el contenido al que preceden.
Fuente
Encuesta sobre preferencias de usuarios de lectores de pantalla en WebAIM
Ocultación de elementos con la carga del DOM sin usar librerías
Por kcmr, el 11 de enero de 2009 en Accesibilidad, Buenas ideas, Javascript
Etiquetas: Accesibilidad, DOM, Javascript
Como ya he comentado más de una vez por aquí, cuando necesitamos ocultar un elemento HTML para mostrarlo u ocultarlo mediante Javascript (un menú desplegable, una capa colapsable, etc), no debemos ocultarlo previamente en el HTML, ya que ese elemento deberá permanecer visible cuando no haya Javascript.
Para ello se pueden utilizar varias técnicas como ocultar estos elementos mediante Javascript añadiendo el estilo display: none, (sí, en la mayoría de casos no será incorrecto que el elemento oculto también lo esté para lectores de pantalla), o bien añadiendo una clase “oculto”, “hidden” o similar definida en la CSS que se encargue de ocultar elementos.
El problema de esta técnica es que cuando no podemos usar alguno de los métodos que nos ofrecen las librerías Javascript para ejecutar funciones cuando el DOM está disponible (ready de jQuery, domready de Mootools o dom:loaded de Prototype), nos encontramos con el feo efecto de que nuestros elementos ocultos aparecen un instante visibles hasta que toda la página está cargada (onload).
Para evitar esto se suelen utilizar otras técnicas no muy limpias de la vieja escuela, como colocar el código Javascript en el HTML, o lo que es peor, usar estilos en línea en la capa o elemento que se ha de ocultar.
Pues bien, gracias a Scriptia, descubro este otro método para ocultar elementos que se basa en añadir una clase al elemento HTML mediante la propiedad documentElement del objeto document. Y cito lo que nos comenta Choan sobre document.documentElement:
- Para modificar ‘document.documentElement’ no es necesario esperar a que se complete la carga del documento.
- La especificación HTML 4.01 no permite el uso del atributo ‘class’ en el elemento ‘html’. En mi opinión, como la jugada la hacemos por scripting, esto no invalida el documento.
Para utilizarlo nos propone usar una variable en la que detectamos el soporte del DOM por el navegador:
var isSupported = document.getElementById && document.getElementsByTagName;
Y una sencilla instrucción:
if (isSupported) {
document.documentElement.className = "js";
}
Por último, para evitar tener rondando por ahí una variable global, podemos colocarlo todo dentro de una función anónima autoejecutable, o lo que también se conoce como closure, si no estoy equivocada:
(function(){
var isSupported = document.getElementById && document.getElementsByTagName;
if(isSupported){
document.documentElement.className = "js";
}
})();
En la CSS aplicaríamos el display none sólo a los elementos hijos de los que tienen la clase “js”:
.js .oculto{ display: none; }
He probado esta técnica en una página en la que he usado 4 imágenes pesadas, para comprobar que la capa que se oculta mediante Javascript, efectivamente lo hace sin necesidad de que la página esté cargada y ¡funciona!
Demo ocultación de elementos mediante javascript.
Por si alguien se pregunta quién va por el mundo con Javascript deshabilitado, no hace falta irse a buscar al usuario de Lynx o a ese otro que por alguna extraña razón decide rebuscar la opción de deshabilitar Javascript en su navegador aunque no sepa lo que es ni le importe. El individuo que va por ahí sin Javascript existe y puede ser perfectamente un usuario avanzado que usa un lector de feeds, un móvil con soporte limitado de Javascript, o ve una web desde su cliente de correo.