Uninstallme
Desarrollo front-end, estándares web, accesibilidad y más
Calcular la posición Y de un elemento en pantalla respecto al área visible con Prototype
Por kcmr, el 3 de febrero de 2009 en Cajón de sastre, Javascript, Prototype
Etiquetas: framework javascript, Javascript, Prototype
Supongamos que tenemos las típicas capas emergentes que aparecen al lado de un enlace o icono de ayuda al clicarlo.
Ejemplo de capa emergente que aparece al hacer click sobre un icono de ayuda
Uno de nuestros objetivos es que estas capas siempre aparezcan en el área visible de la ventana del navegador, por lo que, según la posición del enlace que las muestra (más o menos cercano al final de la ventana), deberemos calcular su posición para evitar que puedan aparecer cortadas.
Ejemplo de capa cortada por la ventana del navegador
La librería Prototype nos ofrece unos cuantos métodos para que esta tarea sea más fácil, pero antes de darle demasiadas vueltas (yo por lo menos se las di…), lo mejor es hacerse un esquema.
- document.viewport.getScrollOffsets()[1]
- Devuelve el espacio no visible por encima del área visible (viewport) del documento.
- element.cumulativeOffset()[1]
- Devuelve la posición top (posición Y) del elemento, en este caso la capa emergente, respecto al documento.
- document.viewport.getDimensions().height
- Devuelve la altura del área visible de la ventana del navegador.
- element.offsetHeight
- Devuelve la altura completa del elemento (la capa emergente)
Con estos datos ya tenemos todo lo que necesitamos para saber si la capa emergente podrá mostrarse parcialmente fuera del área visible de la ventana del navegador. Paso a paso…
- Si a la posición top del elemento (element.cumulativeOffset()[1]) le restamos el espacio no visible por arriba (document.viewport.getScrollOffsets()[1]) obtenemos la posición top del elemento respecto al área visible.
- Si a esta resta le sumamos la altura del elemento, obtendremos la posición Y del borde inferior de la capa emergente.
- Si esta medida es mayor que el área visible del documento (document.viewport.getDimensions().height), nuestra capa emergente aparecerá cortada.
Una vez que sabemos cuándo va a aparecer cortada la capa emergente, podemos evitarlo modificando su posición top respecto al documento de la siguiente manera:
Posición top de la capa = altura área visible del navegador + altura del espacio no visible por encima del área visible – altura de la capa.
El código Javascript encargado de hacer todo esto sería:
// posicionTop se ha obtenido previamente mediante element.cumulativeOffset()[1]
// capa hace referencia a la capa emergente (element)
posicionarCapaEnAreaVisible: function(posicionTop, capa){
var posicionRespectoViewport = posicionTop - document.viewport.getScrollOffsets()[1] + capa.offsetHeight;
if(posicionRespectoViewport > document.viewport.getDimensions().height){
posicionTop = document.viewport.getDimensions().height + document.viewport.getScrollOffsets()[1] - capa.offsetHeight;
}
return posicionTop;
}
Supongo que habrá formas más sencillas de hacer lo mismo, y para quien lo quiera “listo para llevar”, siempre le puede echar un vistazo a las capas emergentes y tooltips personalizables de Prototip.
Más información
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
Fragmento de “El Extranjero” (Off topic total)
Por kcmr, el 22 de enero de 2009 en Cajón de sastre, Personal
Aun en el banquillo de los acusados es siempre interesante oír hablar de uno mismo. Durante los alegatos del Procurador y del abogado puedo decir que se habló mucho de mí y quizá más de mí que de mi crimen. ¿Eran muy diferentes, por otra parte, esos alegatos? El abogado levantaba los brazos y defendía mi culpabilidad, pero con excusas. El Procurador tendía las manos y denunciaba mi culpabilidad, pero sin excusas. Una cosa, empero, me molestaba vagamente. Pese a mis preocupaciones estaba a veces tentado de intervenir y el abogado me decía entonces: «Cállese, conviene más para la defensa.» En cierto modo parecían tratar el asunto prescindiendo de mí. Todo se desarrollaba sin mi intervención. Mi suerte se decidía sin pedirme la opinión. De vez en cuando sentía deseos de interrumpir a todos y decir: «Pero, al fin y al caso, ¿quién es el acusado? Es importante ser el acusado. Y yo tengo algo que decir.» Pero pensándolo bien no tenía nada que decir. Por otra parte, debo reconocer que el interés que uno encuentra en atraer la atención de la gente no dura mucho. Por ejemplo, el alegato del Procurador me fatigó muy pronto. Sólo me llamaron la atención o despertaron mi interés fragmentos, gestos o tiradas enteras, pero separadas del conjunto.
Si he comprendido bien, el fondo de su pensamiento es que yo había premeditado el crimen. Por lo menos, trató de demostrarlo. Como él mismo decía: «Lo probaré, señores, y lo probaré doblemente. Bajo la deslumbrante claridad de los hechos, en primer término, y en seguida, en la oscura iluminación que me proporcionará la psicología de esta alma criminal.» Resumió los hechos a partir de la muerte de mamá. Recordó mi insensibilidad, mi ignorancia sobre la edad de mamá, el baño del día siguiente con una mujer, el cine, Fernandel, y, por fin, el retorno con María. Necesité tiempo para comprenderle en ese momento porque decía «su amante» y para mí ella era María. Después se refirió a la historia de Raimundo. Me pareció que su manera de ver los hechos no carecía de claridad. Lo que decía era plausible. De acuerdo con Raimundo yo había escrito la carta que debía atraer a la amante y entregarla a los malos tratos de un hombre de «dudosa moralidad.» Yo había provocado en la playa a los adversarios de Raimundo. Este había resultado herido. Yo le había pedido el revólver. Había vuelto sólo para utilizarlo. Había abatido al árabe, tal como lo tenía proyectado. Había disparado una vez. Había esperado. Y «para estar seguro de que el trabajo estaba bien hecho», había disparado aún cuatro balas, serenamente, con el blanco asegurado, de una manera, en cierto modo, premeditada.
«Y bien, señores», dijo el Abogado General: «Acabo de reconstruir delante de ustedes el hilo de acontecimientos que condujo a este hombre a matar con pleno conocimiento de causa. Insisto en esto», dijo, «pues no se trata de un asesinato común, de un acto irreflexivo que ustedes podrían considerar atenuado por las circunstancias. Este hombre, señores, este hombre es inteligente. Ustedes le han oído, ¿no es cierto? Sabe contestar. Conoce el valor de las palabras. Y no es posible decir que ha actuado sin darse cuenta de lo que hacía».
Yo escuchaba y oía que se me juzgaba inteligente. Pero no comprendía bien cómo las cualidades de un hombre común podían convertirse en cargos aplastantes contra un culpable. Por lo menos, era esto lo que me chocaba y no escuché más al Procurador hasta el momento en que le oí decir: « ¿Acaso ha demostrado por lo menos arrepentimiento? Jamás, señores. Ni una sola vez en el curso de la instrucción este hombre ha parecido conmovido por su abominable crimen.» En ese momento se volvió hacia mí, me señaló con el dedo, y continuó abrumándome sin que pudiera comprender bien por qué. Sin duda no podía dejar de reconocer que tenía razón. No lamentaba mucho mi acto. Pero tanto encarnizamiento me asombraba. Hubiese querido tratar de explicarle cordialmente, casi con cariño, que nunca había podido sentir verdadero pesar por cosa alguna. Estaba absorbido siempre por lo que iba a suceder, por hoy o por mañana. Pero, naturalmente, en el estado en que se me había puesto, no podía hablar a nadie en este tono. No tenía derecho de mostrarme afectuoso, ni de tener buena voluntad.
Comentarios cerrados
Javascript Module Pattern: métodos y propiedades públicas o privadas
Por kcmr, el 22 de enero de 2009 en Javascript
Etiquetas: Javascript, module pattern
Una de las ventajas que se me escapaba en una entrada anterior sobre el uso de la programación orientada a objetos en javascript, frente a la programación orientada a funciones (sintaxis tradicional), era el de la ocultación de funciones y variables, que permite evitar posibles conflictos entre scripts, sobrescritura accidental, etc.
Cuando creamos una función en javascript al estilo tradicional, (function muestraAlert(){alert(‘Hola mundo’)}), estamos añadiendo implícitamente un método al objeto global window. De hecho, podríamos llamar a nuestra función mediante window.miFuncion(), aunque nunca lo hagamos así. Las variables globales pueden ser accedidas desde cualquier parte del código o desde otro script, como comentaba en el párrafo anterior, con los riesgos que esto supone.
La POO minimiza este riesgo al englobar las variables y funciones dentro de un objeto, convirtiéndo las variables en propiedades y las funciones en métodos del objeto, de manera que sólo podamos acceder a ellas a través del objeto al que pertenecen.
Ejemplo:
MiCoche = {
// propiedades
color: 'rojo',
combustible: 'diesel',
// métodos
acelerar: function(){
// instrucciones...
}
}
Sólo puedo acceder desde fuera del objeto a la variable “color”, propiedad del objeto “MiCoche”, a través de MiCoche.color
De esta forma nuestros métodos y propiedades están “suficientemente” protegidos, pero todavía es posible acceder a ellos desde el exterior mediante Objeto.propiedad u Objeto.metodo()
Es posible que nos interese que determinadas propiedades o métodos no puedan ser accedidos desde el exterior nunca, de ninguna manera posible. Por ejemplo, podemos tener unas variables que sean usadas por un método privado y no tengan por qué ser visibles ni modificables desde el exterior en ningún momento. Esto podría ser comparable con lo que en los lenguajes que se consideran realmente orientados a objetos, se conoce como encapsulación:
hacer las variables que son innecesarias para el tratamiento del objeto pero necesarias para su funcionamiento privadas, asi como las funciones que no necesitan interacción del usuario o que solo pueden ser llamadas por otras funciones dentro del objeto
Esto se puede conseguir gracias a lo que en Javascript se llama Module Pattern, que consiste en la asignación de una función anónima a una variable y su autoejecución inmediata. Todas las variables y funciones que se encuentren dentro de esta función serán sólo accesibles desde la propia función, es decir, actuarán como métodos y propiedades privadas.
Ejemplo:
var MiCoche2 = function(){
var color = 'rojo';
var combustible = 'diesel';
}();
^^ Estos paréntesis provocan la ejecución inmediata de la función
La buena noticia es que devolviendo un objeto, conseguiremos también proporcionar métodos y propiedades públicas, accesibles mediante MiCoche2.metodo() o MiCoche2.propiedad
Ejemplo:
var MiCoche2 = function(){
// propiedades privadas
var acelerador = 'pedal derecho';
[...]
// métodos y propiedades públicas
return { // devolvemos un objeto
color: 'rojo',
acelerar: function(){
// instrucciones
},
frenar: function(){
}
}
}();
^^ provocamos la ejecución inmediata y la devolución de los métodos y propiedades contenidos dentro del objeto devuelto por return.Como se puede ver en el ejemplo, dentro de return usamos la notación literal de objetos como en el primer ejemplo expuesto (MiCoche), ya que de un objeto se trata. Para quien no le guste o prefiera la sintaxis tradicional, siempre se puede recurrir al método que proponen en wait-till-i.com, que consiste en la creación de un objeto vacío dentro del objeto principal, al que se le van añadiendo métodos y propiedades y que finalmente se devuelve mediante return.
Ejemplo:
var MiCoche2 = function(){
// propiedades privadas
var acelerador = 'pedal derecho';
var obj = {}; // objeto vacío
obj.acelerar = function(){
// instrucciones
}
return obj;
}();
Sigo llamando a los métodos públicos mediante MiCoche2.acelerar(), etc.
¿Qué hay de la reutilización de código?
La técnica mola, pero tiene un pequeño problema: no podemos crear instancias del objeto MiCoche2 mediante new MiCoche2().
La solución es eliminar los paréntesis finales que causan la ejecución inmediata. Nuestro ejemplo final quedaría así:
var MiCoche3 = function(){
// propiedades y métodos privados
var propiedad = 'valor';
[...]
// propiedades y métodos públicos
return {
color: 'rojo',
metodo: function(){
},
[...]
}
}
// creamos una instancia de MiCoche3
var MiNuevoCoche = new MiCoche3();
// y redefinimos sus propiedades
MiNuevoCoche.color = 'negro';
Más información
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.
Diseños elásticos, Internet Explorer y font-size
Por kcmr, el 7 de enero de 2009 en Accesibilidad, CSS
Etiquetas: Accesibilidad, CSS, css bugs, font-size, How to, ie bug, internet explorer
Los diseños elásticos en CSS son aquellos en los que se utilizan unidades relativas para las medidas de fuentes y capas contenedoras de manera que, manteniendo la apariencia y ventajas de los diseños fijos frente a los diseños líquidos, permiten redimensionar el tamaño de todos los elementos de la página al aumentar o disminuir el tamaño de fuente en el navegador.
Este comportamiento es posible gracias a la utilización de emes como unidad de medida para definir las dimensiones de todos los elementos de la página. Las emes son una unidad relativa, es decir, no se puede decir que tengan una equivalencia en píxeles de por sí, sino que su valor depende del tamaño de fuente del elemento en base al que son declaradas.
Por suerte, el tamaño de fuente por defecto en todos los navegadores (creo que esto no siempre ha sido así), es de 16 píxeles, con lo que a partir de esto se puede decir que 1em = 16px.
Calcular tamaños relativos a 16 píxeles no es nada apetecible, sin embargo, calcular tamaños en base a 10 píxeles es tan sencillo como dividir la medida en píxeles por 10, de manera que lo que en píxeles son 400, en emes sean 40.
Con el objetivo de establecer el valor de 1em en 10px, surge esta conocida regla:
body{ font-size: 62.5%; } // 100% = 16px => 62.5% = 10px
Y ya tenemos la equivalencia deseada de 1em con 10px en todos los navegadores. En todos menos en Internet Explorer (todas las versiones, incluso el “superestándar” Internet Explorer 8 )
Toda esta explicación e introducción, probablemente innecesaria, viene a cuento de una nueva herramienta on line que he visto unas cuantas veces durante los últimos días en mis feeds. Se trata de PXtoEM.com, que se basa en la anterior regla para hacer la conversión de píxeles a emes.
Si no somos demasiado pejigueros, la regla del 62.5% es aceptable cuando sólo se van a usar emes para los tamaños de fuente, pero no es válida para hacer un diseño elástico, ya que en el momento que se empiecen a usar imágenes de fondo en capas, las cosas empezarán a no cuadrar en Internet Explorer.
¿Cuál es el problema en Internet Explorer?
Cómo comentan en un mail en la lista de correo de css-discuss.incutio.com, Internet Explorer ignora el decimal en el porcentaje (62.5%), con lo que la equivalencia conseguida es de 9.92px en vez de 10px.
Se puede comprobar utilizando una imagen de fondo en una capa a la que damos las dimensiones de la imagen de fondo. En esta página test, hay una capa con una imagen de fondo de 300 x 200 píxeles (el borde es interior). El estilo para esta página contiene solamente dos reglas:
body{ font-size: 62.5%; background: #ccc;}
.capa-test{width: 30em; height: 20em; background: url(fondo.gif) 0 0 no-repeat;}
Si vemos esta página con cualquier versión de Internet Explorer, veremos que la imagen de fondo no aparece completa, le faltan los bordes derecho e inferior.
Captura de Internet Explorer 6
Captura de Internet Explorer 7
Captura de Internet Explorer 8 Beta 2
La solución peligrosa.
Hay una solución que funciona, basada en establecer el tamaño de fuente del elemento HTML en 62.5%, el del BODY en 100% para los navegadores que no son Explorer y en 101% para Explorer, lo que supone tener que usar hacks o selectores para uno u otro navegador con los riesgos que esto conlleva. No sabemos si una futura versión de Opera, Firefox o cualquier otro navegador, soportará estos selectores CSS usados como filtros.
La solución más simple.
Si el problema de Internet Explorer es que ignora el decimal en el porcentaje, simplemente podemos solucionarlo buscando una medida redonda. Esta medida es 125%, que equivale a 20 píxeles.
Dando al BODY un font-size de 125% y al bloque contenedor de todos los elementos de la página un tamaño de fuente de 0.5em (la mitad de 20), conseguimos la equivalencia buscada de 1em = 10px sin usar hacks ni medidas erróneas.
En esta otra página test se puede ver el resultado y comprobar que Internet Explorer interpreta correctamente el tamaño de fuente. En este ejemplo se ha añadido una capa que contiene a la capa con la imagen de fondo, a la que se le ha dado un tamaño de fuente de 0.5em:
body{font-size: 125%; background: #ccc;}
#contenedor{font-size: .5em;}
.capa-test{width: 30em; height: 20em; background: url(fondo.gif) 0 0 no-repeat;}
Los resultados en Internet Explorer usando esta técnica:
Captura de Internet Explorer 6
Captura de Internet Explorer 7
Captura de Internet Explorer 8 Beta 2
Actualización (12/01/2009)
No es necesario dar un tamaño de fuente de 0.5em a la capa contenedora más externa, ya que podemos dar diréctamente el tamaño de 125% al elemento HTML y el de 0.5em al BODY. De esta forma nos ahorramos dar un tamaño de fuente para cada capa que se genere fuera del bloque contenedor, como suele ser el caso de ventanas modales, capas que contienen iconos de cargando, etc.
La CSS quedaría finalmente así:
html{ font-size: 125%; }
body{ font-size: .5em; }
Se puede ver el resultado en esta página.
Fuentes y más información
Descubriendo los códigos QR y sus posibilidades
Por kcmr, el 3 de enero de 2009 en Accesibilidad, Buenas ideas, Personal
Etiquetas: Accesibilidad, QR-Code, tecnología, web móvil
Hace cosa de un mes descubría esto de los códigos QR. Me he sentido algo aliviada al leer este post en el blog de QR Code, ya que parece que en España nos lo estamos tomando con cierta calma y no soy la última en enterarme 
Los códigos QR pueden contener un máximo de 256 caracteres alfanuméricos. Esta información puede ser leída y decodificada por un teléfono móvil con cámara y un programa para leer estos códigos mediante una fotografía. Esto permite acceder directamente a una URL o copiar los datos de un contacto en la agenda sin tener que introducirlos manualmente.
Puedes descargar un programa para leer códigos QR compatible con tu terminal en Kaywa Reader. La web de Kaywa también ofrece un generador de códigos QR.
Código QR de Uninstallme.
En Japón, el uso de estos códigos ya está muy extendido, y no sólo es frecuente encontrarlos en cualquier cartel publicitario por la calle, sino que llegan al extremo de usarlos en lápidas para proporcionar la URL de una web con datos sobre el difunto, fotos, etc.
Aunque, como comentaba anteriormente, en España su uso no está tan extendido, ya hay quien ha visto las posibilidades de esta tecnología para ofrecer mejoras de accesibilidad a personas invidentes o con visión reducida.
Accesibilidad en edificios
Me ha llamado la atención la iniciativa del CRE de San Andrés del Rabanedo (León), de colocar estos códigos QR en las puertas del edificio con la información que normalmente suele aparecer en un cartel expresada mediante texto o símbolos. (Ejemplo: aseos de señoras.)
En este vídeo se explica cómo una persona invidente puede escuchar la información de estos códigos usando un teléfono móvil equipado con un lector de pantalla.
Tarjetas de visita accesibles
Estas tarjetas incluyen el código QR con los detalles del contacto, de manera que con hacer una foto a la tarjeta, ya tenemos registrados todos los detalles de contacto en la agenda del móvil sin escribir una sola letra y, de paso, evitando posibles errores tipográficos. Más cómodo imposible.
Otros usos
Idealista.com ofrece un servicio de generación de fichas para imprimir y pegar en farolas, cristales, etc. Estas fichas llevan un código QR con una URL en la que se proporcionan fotos y otros datos sobre el inmueble en alquiler o venta.
En la tienda on line de QR-Code, se pueden encontrar camisetas, bolsos o tazas con todo tipo de mensajes graciosos para descifrar.
A mí se me ocurren ahora mismo usos relacionados con la geolocalización (ZXing ya está incorporando esta característica en su generador de códigos.) Por ejemplo, aprovechando que muchos móviles de última generación suelen incorporar GPS, estos códigos podrían conducirnos directamente hasta un determinado restaurante o, colocados en los típicos carteles de información (“Usted está aquí”), conectarnos con un servicio que nos diga qué tenemos a nuestro alrededor en una ciudad desconocida.
Fuentes y más información
- Código QR en la Wikipedia
- Generador de códigos QR para uso personal (detalles de contacto, links, mensajes)
- Blog sobre QR en español Su generador de códigos permite generarlos en color o en formato PDF.
- Extensión para Firefox para generar códigos QR a partir de URL’s o selecciones de texto
- Los códigos QR conectan a todas las cosas
Aplicaciones útiles para una revisión de accesibilidad (contraste de color)
Por kcmr, el 29 de diciembre de 2008 en Accesibilidad, Programas, Utilidades
Etiquetas: Accesibilidad, aplicaciones
Dejo un par de aplicaciones gratuitas de Fujitsu, descubiertas a través de Utilidades para Webmasters, de gran utilidad para detectar y prevenir problemas de accesibilidad causados por un contraste de color insuficiente o la transmisión de información basada sólo en el color.
ColorSelector permite comprobar el contraste de color de cualquier imagen o texto con bastante más precisión que el ya conocido Color Contrast Analyser. Otra ventaja respecto a este, es que nos proporciona una información “más amigable” sobre las deficiencias visuales para las que una combinación de colores puede ser problemática.
Una aplicación muy útil para comprobar el contraste de imágenes con contenido textual en la fase de diseño.
La otra aplicación es ColorDoctor, que muestra una página web simulando varias deficiencias visuales o en escala de grises. Esta última opción es especialmente útil para detectar información transmitida sólo mediante el color, como podrían ser los típicos iconos con banderas de países para seleccionar el idioma o enlaces diferenciados del texto solamente mediante un color distinto.
Esta aplicación permite hacer la transformación en tiempo real (marcando la opción Real-time conversion), con lo que no sólo obtenemos una simple captura de pantalla como hacen otras aplicaciónes, sino que podemos ver también los cambios de color para el estado hover, animaciones, etc.
Internet Explorer 8 usará Webkit como motor de renderizado
Por kcmr, el 28 de diciembre de 2008 en Navegadores
Etiquetas: Navegadores
Pasado el día de las inocentadas, debo advertir que este post contiene un 25% de verdad y un 25% de afirmaciones sacadas fuera de contexto. El resto es completamente falso
Los que nos dedicamos a esto de la maquetación estamos de enhorabuena con la noticia que se hacía pública ayer en el blog de IE de MSDN, y es que Microsoft pone fin a 13 años de “maltrato” a los estándares web, apostando por Webkit como motor de renderizado para el futuro Internet Explorer 8, que se lanzará finalmente a mediados del 2009.
Los rumores sobre la adopción de Webkit para Internet Explorer 8, comenzaban hace algo más de un mes, durante una conferencia en Australia, en la que Steve Ballmer, CEO de Microsoft, afirmaba estar interesado en el Open Source, y más concrétamente en Webkit.
Finalmente se ha confirmado que Internet Explorer mantendrá su interfaz propietaria y usará Webkit como motor de renderizado:
Each browser will have its own proprietary interface, unique set of features, but at least the rendering engine will be essentially the same.
No es la primera vez que algo así ocurre en la historia de los navegadores. Netscape tuvo una iniciativa parecida con su Netscape 6, con el que se saltaron la versión 5 apostando por una renovación completa y el uso de Gecko como nuevo motor de renderizado.
Aunque la noticia es esperanzadora, la lentísima actualización a la versión 7 por parte de los usuarios de Explorer y el desatino por parte de Microsoft al usar Internet Explorer 6 como navegador para la próxima generación de móviles basados en Windows Mobile, hacen que lamentablemente, tengamos que ver el desestancamiento en la implementación de nuevos estándares web como un futuro lejano.
Disparar el evento onclick sobre elementos input de forma remota
Por kcmr, el 22 de diciembre de 2008 en Javascript
Etiquetas: Javascript
En Mocilla Developer Center he encontrado un método cuya existencia desconocía, pero que puede ser de gran utilidad. Se trata del método click, que ejecuta el evento onclick sobre elementos input (botones), checkboxes y radio buttons. En navegadores no basados en Gecko también ejecuta el evento onclick sobre enlaces.
Utilizando este método podemos conseguir de una manera sencilla que un formulario se envíe cuando un campo de texto pierda el foco, por poner un ejemplo.
Su uso es igual al de focus: elemento.click()