A casi un año de la preparación del escrito original de Diseño Web y estándares, para PsicoFXP, (en especial para el subforo de Diseño que moderaba por esos días), me doy cuenta de lo difícil que es mantener las propias convicciones, en un ámbito laboral muy competitivo, donde el usuario final de un sitio web rara vez es tenido en cuenta; donde los tiempos nunca son los deseados y cuando la aplicación de una metodología de trabajo acorde a ésta profesión se hace casi imposible. ¿Y por qué digo esto? Porque la necesidad de un diseño y desarrollo rápido nos hace, muchas veces tener que ser más flexibles en la labor diaria, para caer en una triste conclusión de la cual tal vez, tengamos también parte de culpa: no todos los clientes están dispuestos a aceptar un diseño accesible y acorde a los estándares.
Cuando comencé a recopilar la información para esta segunda parte, fui incluyendo conceptos varios sobre CSS: pensaba hablar un poquito sobre historia, sobre los navegadores más modernos, las ventajas y desventajas de su actual implementación. Pensé en agregar algunas ideas para trabajar con los editores html, etc. Pasó el tiempo y creo que ese primer acercamiento al tema se puede encontrar en muchos sitios en Internet. Y siguió pasando el tiempo y las revisiones a estas frases se sucedían casi semanalmente, hasta quedar archivadas durante unos meses. Sigo dándole vueltas al asunto con la finalidad de escribir algo un poco más original sobre el tema.
Por estos días mis inquietudes están más cerca de las cuestiones metodológicas de los proyectos multimediales que de otra cosa... y por eso me pregunté en qué parte de este proceso yo incluiría mis estilos (cabe decir, mis css, como si fueran de propiedad exclusiva, je!).
Acá fue que recordé algo que había leído hace un tiempo en Sinelogic (lástima que el artículo actualmente, ya no es gratuito. Lo fue al momento de su lanzamiento): Budget Design.
Budget Design presenta una visión de cómo habitualmente un diseñador y un desarrollador comienzan un proyecto.
El diseñador, empieza a trabajar desde un editor gráfico, mientras
que el desarrollador, arma todo el esqueleto del sitio basándose en
el código XHTML y CSS. Esto me hizo pensar en mi propia experiencia
laboral (escasa tal vez), y junto con las pautas que venimos estudiando en
el postítulo, analizar mi forma de trabajar. Llegué a la conclusión
que me encuentro en el grupo de los desarrolladores (¿?) ![]()
El razonamiento fue muy simple: ¿Qué necesito informar o transmitir? ¿Cómo
ubicaría yo esa información en la ventana de un navegador? Y
acá no hay muchas opciones: una columna central, o dos columnas, o tres
o cuatro, dependiendo del tipo de información. Entonces deberé diseñar
en base a un esquema de una columna central, o dos o tres o cuatro. En caso
de ser necesario se creará otro bloque que una o divida esas columnas
básicas. Resultado: se crea un layout previo donde la información
se ajusta a cualquier combinación de estos formatos (piece of cake!)
. Es decir, mi neurona funciona pensando en el documento final dentro del cual
voy a ingresar la información: así estoy incluyendo todos los
elementos de texto, gráficos y animación, dentro de ese esquema
mental que tiene su equivalente en un template tipo creado en base a una hoja
de estilo. Suena tirado de los pelos. Si, puede ser. Pero a las mujeres se
nos permiten estas cosas raras de vez en cuando. Se trata de imaginar de antemano
como se organizará el contenido de un sitio basándonos en formatos
genéricos.
Esto me hace analizar el proceso creativo desde otra perspectiva. Y para decirlo acorde a las distintas etapas metodológicas del proceso multimedia, que vengo estudiando desde hace un tiempo, si ya poseo la IDEA, con todas las pautas que este primer paso involucra, y me siento a desarrollar un DISEÑO, durante la preparación del guión técnico interactivo y del mapa de navegación ya puedo ir relacionando las diferentes interacciones con la manera en que se pueden implementar por medio de CSS, sin dejar de lado el uso de otras técnicas.
Al llegar así a la etapa de realización del PROTOTIPO podré aprovechar las ventajas de haber pensado en los elementos gráficos necesarios para mi documento base o template.
Esto no solo nos facilita las tareas al momento de hacer modificaciones sino que, elaborando con todo detalle, la cantidad de hojas de estilos necesarias, podremos disponer de varios modelos para ofrecer a nuestro cliente.
Aun no creo estar en condiciones de afirmar esta teoría con total convicción, pero puede ser uno de los tantos temas pendientes para someter a prueba, en mi investigación (y sigo sumando…!)
Volviendo al tema de CSS veamos algo de historia (que bien se puede leer, aunque en inglés desde el sitio del W3C)
Las hojas de estilo existen de una forma u otra desde los comienzos del HTML a principios de los '90. Qué, ¿¿qué??
Si. Hace rato que existen. No son invento nuevo. Ni creación mágica de hace un par de añitos. No sr. Veamoslo tipo cuentito:
Erase una vez, un tiempo donde los navegadores incluían su propio lenguaje de estilos, el cual se utilizaba para personalizar la apariencia de cualquier documento web. Por aquel entonces, las hojas de estilos solo las aplicaban los usuarios, definiendo que tipografía y que tamaño debía usar su navegador para interpretar las páginas. Al no existir especificaciones, era entonces el mismo usuario quien decidía en definitiva como se veía un sitio.
El lenguaje HTML, como tal, fue creciendo con los años, y también se lo fue acompañando de una más amplia gama de estilos, para satisfacer también las necesidades de los diseñadores.
En el año 1994 con Håkon Wium Lie las CSS vieron la web, justo tres días antes que Netscape anunciara su navegador mejorado que incluía algunas etiquetas para usar fuentes y el centrado de los textos. La propuesta de Håkon fue presentada en la conferencia "Mosaic and the Web" en Chicago en 1994, y luego con Bert Bos en 1995. Por esta época el World Wide Web Consortium estaba en los inicios de su fundación. Y así se interesaron en el proyecto de CSS. Håkon y Bert conformaron el primer staff técnico del mismo, junto con otros participantes entre los que estaban Thomas Reardon de Microsoft.
A fines de 1996, CSS era casi oficial. Las recomendaciones del nivel 1 fueron publicadas en diciembre de 1996. En 1997, CSS ya contó con su propio grupo de trabajo dentro de W3C, comandado por Chris Lilley. Este grupo se dedicó especialmente a resolver ciertos problemas que estaban pendientes en el nivel 1 así como también implementaron otras mejoras, resultando en CSS nivel 2, y publicado como recomendación oficial en mayo de 1998. CSS nivel 3 está aún bajo desarrollo.
Si bien las especificaciones para CSS1 datan de 1996, se necesitó más de tres años antes que cualquier navegador pudiera implementarlas por completo. Microsoft Internet Explorer 5.0 para Macintosh, lanzado en marzo del 2000 fue el primer navegador que ofreció soporte para CSS1 (soporte de algo más de un 99%). Algunos lo siguieron, y otros implementaron solo partes de la especificación. A pesar de esta evolución, ningún navegador al día de hoy, ofrece un 100% de soporte para CSS2.
Los problemas surgen con algunas inconsistencias, bugs y errores varios en la especificación misma de CSS2. Entonces nos vemos obligados, muchas veces a utilizar “hacks” o atajos en vistas de conseguir un resultado consistente para varias plataformas y navegadores (o sea, seguimos haciendo malabarismos para que una página se vea bien).
Una de las fallas más conocidas de CSS se manifiesta con Internet Explorer y se trata del llamado box model bug, es decir, Internet Explorer no muestra correctamente el modelo de cajas de CSS. De esta forma el ancho de un elemento se ve bastante más angosto en este navegador respecto a otros. El problema se puede evitar, pero a cambio de perder ciertas funcionalidades.
Si bien es un error hay documentación sobre otros cientos de errores en varios navegadores. Hasta el momento, el motor Gecko de Mozilla es el que mejor se adapta a los estándares.
Para aprender a lidiar con estas incosistencias nada mejor que navegar las páginas de CSS Discuss y revisar los topics relativos a los hacks o workarounds. Siempre hay muy buena información sobre las diferentes técnicas que se van probando.
Otro documento que no debe faltar entre la documentación de todo buen diseñador: Eric Meyer on CSS, y Designing with web standards de Jeffrey Zeldman.
CSS fue diseñado primariamente para separar la presentación del contenido. En este punto hay algo de verdad y algo de mentira.
La verdad es que al poner todas características de un párrafo (color, fuente, interlineado, etc.) en un documento externo al documento estructural (el html) podemos ver con claridad como se comportan los distintos navegadores frente a estas modificaciones que se hagan a nivel del estilo (en el archivo externo .css), podemos manejarnos con mayor independencia y ello nos permite hacer modificaciones de manera más rápida y simple.
Pero también convengamos que un documento htm sin estilos, muchas veces se ve desprovisto de todo sentido, a causa de un desconocimiento de la semántica misma de este lenguaje. Para esto nada mejor que revisar el simplequiz de Dan Cederholm en Simplebits o bien Brainstorms & Raves.
Y en español bastante completo me pareció lo que se publica en Desarrollo Web y en Tejedores del Web.
Web Estilo también tiene bastante material para indagar.
Muy útil: descargar las recomendaciones directamente del
sitio de W3Consortium.