FW2006: Strategic CSS Project Management – Dave Shea

Ponente: Dave Shea [weblog]
Coautor del libro recientemente publicado Zen of CSS Design. Es el fundador y diseñador que dirige Bright Creative en Vancouver, BC. Dave también escribe para una gran audiencia de diseñadores web y desarrolladores en su popular blog, mezzoblue.com

Este post se escribe gracias a que Isa Casanova me ha prestado su Mac Book, ya que el mío se queda sin bateria.

Nos va a contar cosas sobre estrategia a seguir cuando trabajamos con hojas de estilo.

La conexión wifi ha fallado estrepitoamente.

Empieza contando que las css que están guardadas en ficheros externos son cacheadas en los agentes de usuario. Si embebemos el código css dentro del html esta peculiaridad se pierde, por lo tanto no es nada recomendable.

Hay un truco que nos enseña para informar al navegador de que la css ha cambiado, y es poner la fecha de actualización del css en el mismo nombre del fichero css, de tal modo que el navegador lo cargará porque no es igual que el que tenga cacheado.

El formato del código es importante.
Formato condensado: todo en una línea. Cada selector está descrito en una línea.
Formato estándar. Cada propiedad está en una linea. Es más legible por las personas humanas.

Tiene mucho sentido desarrollar un formato común. La recomendación de Shea es que se siga siempre un mismo formato.

Recomienda que el código css se comente. Un selector que tenga cierta complejidad puede ser positivo comentarlo, explicando en qué consiste.

propone comentarios en los cierres de los elementos html asociados al selector que le da a capa de presentación, de tal modo que sepamos dónde termina esa agrupación de código.

Comenta la posibilidad de aprovechar el espacio en blanco que queda a la derecha de los selectores, de tal modo que se pueda comentar ahí en que consiste cada uno de ellos.

Consistencia del código

Es bueno usar convenciones a la hora de nombrar las diferentes partes del contenido que conforma una pantalla determinada. La reutilización será posible si hacemos uso de este tipo de técnicas para nombrar el código.

Orden del código fuente css

Empezamos con el body los encabezados, vínculos… de arriba hacia abajo. De lo general a los específico.

Hay otra forma de ordenación, que es por orden aflabético. Al menos es lo que nos enseña Dave.

No se moja y no nos dice cuál prefiere.

Marca distancias.

Ahora nos habla de las características de la cascada y la especificidad. Vamos, que explica en qué consiste la especificidad.

Lo de la wifi… nada, que no va. Escribiendo offline.

Recomendaciones para sacar partido de la jerarquía en cascada

– Que el body tenga un id, o un id y una clase. Esto nos permitirá tomar el control del diseño de una forma amplia. A través de este tipo de selectores podemos incluso diferenciar el tipo de diseño que vamos a ofrecer a cada navegador. Nos enseña el ejemplo de cómo se consigue en css zen garden.

– Ficheros css granulares
Consiste en disgregar los selectores y atributos de cada uno de ellos en diferentes ficheros físicos. Básicamente nos sirve para reaprovechar algunas propiedades, Por ejemplo, el tipo de letra y su color pueden estar controlados en un fichero físico, y el layout en otro diferente.

La wifi sigue sin funcionar.

Establece una serie de criterios a través de los que poder configurar la granularidad de las hojas de estilos:
tipos de letra
colores
layout
etc

Parece que la conexión vuelve a funcionar. Cruzo los dedos.

Eliminación de errores en CSS. Quedan 15 minutos de speech.

Nos enseña cómo se muestran los resultados de la prueba Acid2. Safari y Opera superan actualmente el test.

Estrategias de debug en css:

– Tomarse tiempo para entender qué es lo que esta provocando el fallo. Se trata de ver si el problema es un fallo del navegador o es un fallo del código.
– Uso de hacks de una forma lógica y razonable. Gracias al Box Model Hack se solventaron los problemas de visualización entre IE 5 e IE 6. Tenemos que crear código CSS para un entorno ideal. Es decir, dsarrollar con Firefox o un navegador que haya paado el test Acid2. Después de eso hay que corregir los errores que se hayan podidoproducir en otros navegadores, como IE. Habla de que IE7 corrige muchos errores de sus versiones predecesoras, con lo que haber desarrollado para los navegadores que funcionan bien, para luego arreglar lo que se vea mal en otros, el hecho de que IE7 arregle los errores de sus versiones anteriores, junto con una estrategia que incluya el sacar a CSS externas donde estén lo hacks, hará que apenas tengamos trabajo cuando los navegadores funcionen de forma correcta. Obviamente hablamos de IE7.
– No tenerle miedo a IE7 desde la perspectiva de los desarrolladores. Nos dijeron que no ibamos a poder usar los hacks en IE7. Entró miedo al coocer esta información, pero es que en realidad se trataba de que IE7 arreglará, dice, esos problemas de visualizacion.

Los navegadores van mejorando con el tiempo.