Entradas de noviembre 2008

Desarrollo con estándares web 1

26 de noviembre, 2008 - por | | Desarrollo, Estándares

Roger Johansson mantiene actualizada una introducción, ya clásica, al desarrollo con estándares web en su sitio 456bereastreet.com: Developing With Web Standards – Recommendations and best practices. Con el tiempo se han ido haciendo numerosas traducciones a otros idiomas, aunque todavía no contamos con una en español. Así que voy a ir publicando aquí, en diferentes entradas, una traducción completa que, finalmente, también se encontrará en la sección de traducciones de su sitio.

Por cierto, siempre es un placer colaborar con personas tan profesionales y generosas como Roger.


Desarrollando con estándares web. Recomendaciones y buenas prácticas

1. Introducción

Este documento intenta explicar cómo y por qué el uso de estándares web te permitirá construir sitios web de un modo tal que el desarrollador ahorre tiempo y dinero, y el usuario tenga una mejor experiencia. Se discuten, también, otros métodos, guías y buenas prácticas que ayudarán a producir sitios web de alta calidad, accesibles y usables para el mayor número de personas y dispositivos posibles.

2. Historia

Cuando Internet y la Web se popularizaron en la segunda mitad de los 90, las compañías de navegadores web no habían implementado aún CSS (Cascading Style Sheets) de forma suficiente como para que los desarrolladores web tuviesen la capacidad de usarlas para controlar la presentación de un documento HTML. La falta de implementación es en cierto modo comprensible, teniendo en cuenta que la especificación para CSS Nivel 1 fue publicada en 1996, y que la correspondiente al Nivel 2 fue publicada en 1998.

La falta de soporte para CSS en los navegadores web, combinada con las demanda de los diseñadores gráficos en relación con el nivel de control que es posible cuando se trabaja con material impreso, condujeron al abuso de HTML hacia una forma de controlar la presentación visual de una página web.

Un ejemplo de ésto es la “fuga” que se produjo cuando los diseñadores descubrieron que mediante el uso del atributo border="0" para ocultar los bordes de una tabla HTML, fue creada una celda invisible que podía usarse para controlar el layout. Otro ejemplo es el uso de imágenes transparentes, por tanto invisibles, llamadas “spacer GIFs” para el control de los espaciados y los márgenes.

Puesto que HTML nunca fue ideado para controlar la presentación de un documento, fueron, y siguen siendo, utilizados hacks, código inválido y elementos y atributos específicos de algunas compañías. La validación era algo que muy poco conocían o utilizaban. Este tipo de código HTML suele denominarse sopa de tags.

A medida que se fueron publicando nuevas versiones de navegadores web, el soporte para CSS mejoró y se extendió, pero no en la proporción que debería. Sin embargo, aunque las compañías de navegadores son lentas en la implementación correcta de CSS, hemos alcanzado un punto donde los navegadores web con buen soporte para CSS están siendo utilizados por tantas personas que ya no hay razón para no utilizar el HTML en la forma en que debe ser usado: para describir la estructura y el contenido de un documento, y no su presentación. Para eso, podemos actualmente utilizar CSS, que fueron diseñadas específicamente para tal propósito.

Probar, probar, probar

6 de noviembre, 2008 - por | | Desarrollo, Frontend

En el desarrollo web una de las áreas posiblemente más descuidada es la de probarlo todo con diferentes navegadores. Descuidar cualquier cosa que tenga que ver con el elemento más crucial de todos (el navegador) es un problema bastante gordo. Aunque no hay una solución perfecta, sí existen formas de corregir parcialmente el problema.

Lo primero, antes de nada, es familiarizarse mucho con los navegadores; convivir con ellos; hacerse cargo de su diversidad; entender los distintos motores de renderización (“layout engines”) y cómo se apoyan los navegadores en ellos; comprender la forma en que se produce esa renderización… Todo esto siempre es mejor hacerlo, aunque sea un poquito, que no hacerlo. El resultado, además de los conocimientos concretos, es una actitud desde la que es más fácil resolver problemas y crear cosas, y desde la cual la diversidad dejará de ser percibida como un obstáculo para ser explotada como un beneficio.

Podemos empezar por echarle un ojo al listado que de navegadores que ofrece Wikipedia.

Una vez que ya estamos con esa “mochila”, podemos afinar un poco, distinguiendo las cosas que pueden variar de unos a otros navegadores: marcado, hojas de estilos, nivel del DOM, soporte de imágenes, etc.

Con todo eso, es razonable crear una plataforma mínima de pruebas. La complejidad y coste de la plataforma de pruebas estará en función de nuestras necesidades. En la red hay algunas cosas interesantes.

Por ejemplo, si queremos hacer alguna prueba puntual, y no necesitamos resultados inmediatos, browsershots.org está bastante bien. Es abierto, gratuito y fácil de utilizar, e íntegramente web. Utiliza una nube de ordenadores voluntarios a los que envía las peticiones, y que escupen capturas de pantalla que luego puedes visitar directamente en la web. No es muy rápido, y la captura es plana. En esta misma línea, hay soluciones comerciales como browsercam.com, y litmusapp.com, que funcionan bastante bien, y son más rápidas que la primera. El principal problema que le encuentro a todas ellas es que necesitan trabajar con urls públicas, lo que en entornos de desarrollo no es habitual.

Si, por el contrario, necesitamos realizar periódicamente pruebas y no sólo disponer de una captura de pantalla, sino poder analizar/modificar directamente el código, lo mejor es montarse un entorno de pruebas instalando diferentes sistemas operativos (so), diferentes navegadores y distintas versiones de cada uno de éstos. Esta gama puede variar; si se trata de algo que ya está en marcha y tiene unas estadísticas de uso muy concretas (por ejemplo, Windows XP con IE6 y Windows Vista con IE7), podemos concentrarnos en ese grueso; si se trata de algo nuevo (un portal, una aplicación, etc.), entonces dependería de la orientación que se le quisisera dar (¿pcs? ¿dispositivos móviles?…). En cualquier caso, es bueno habituarse a mirar las estadísticas de uso globales (por ejemplo, el XiTi Monitor), y de ahí extraer una idea sobre lo que se necesita.

La forma de montar un banco de pruebas de este tipo pasará casi siempre por tirar de máquinas virtuales, para correr los diferentes sistemas operativos, e intentar instalar el número máximo de versiones de un mismo navegador en una misma máquina virtual, de forma que minimicemos las complicaciones y la pesadez de tener levantadas varias.

Un tercer elemento importante es el de los dispositivos. Es bueno, para simplificar, considerar los monitores como un dispositivo más, como podría serlo un móvil, una pda o un tablet. Lo más importante es tener en cuenta la resolución de pantalla y la profundidad de color (bits por píxel). En ésto tambien es bueno habituarse a consultar las estadísticas sobre uso de dispositivos, que suelen incluir su resolución de pantalla y su profundidad de color. Como en el caso de los navegadores, hay diversidad; y como entonces, no debemos interpretarla como un obstáculo sino como un beneficio, adaptándonos a ella. Quizás la prueba más importante sea la de comprobar que la paleta cromática que estamos utilizando se ajusta igual de bien a profundidades de 24, 16 y 8. Y es ahí donde el uso los llamados “colores seguros para la web” así como de los “browser-safe colors” (Lynda Weinman) adquiere toda su importancia.

Como hay un montón de chicha en todos estos temas, voy a intentar ir escribiendo entradas para ir complementando esta información.