¿Framework CSS? Primera parte

Una de las cuestiones que, he observado, menos respuestas ha obtenido cuando cuando en algún foro se ha preguntado, es la que tiene que ver con la organización de las hojas de estilo dentro de un proyecto de desarrollo web.

No es que sea cosa baladí, ni mucho menos, pero sí es cierto que si no estamos ante un proyecto de determinado volumen, estrujarse el cerebro para montar algo así como un framework CSS no es de mucha utilidad, a poca experiencia que tengamos en el uso y manejo de esta tecnología. De todos modos, puedo decir por la experiencia de trabajo que tengo, que cuando nos encontramos ante un proyecto de cierta envergadura, contar con un entorno controlado de CSS es una herramienta mucho más que útil. Casi diría que es vital.

Voy a tratar de desarrollar en este post una serie de ideas que tengo dispersas en mi cabeza, ordenarlas, y tratar de arrojar algo de luz en el tema de la organización y sistematización de las hojas de estilo cuando nos encontramos ante un proyecto de alcance medio-alto.

Los inicios

Cuando inciamos un proyecto, lo más habitual suele ser que empecemos por planificar las hojas de estilo en función de los elementos que nos vamos a encontrar, siguiendo la norma de dotar de estructura a la pantalla, y posteriormente dotar de un nivel de presentación a los elementos que hay en cada pantalla.

De ese modo, lo más habitual es que empecemos a escribir en el documento CSS todo lo necesario para posicionar la rejilla o layout de la pantalla. Así, situamos la cabecera, la navegación, la zona de contenidos, el pie de página, etc.

Luego vamos ajustando, si es que nos preocupamos de ello, los selectores para que todo se vea igual en los diferentes navegadores. Si es necesario hacemos uso de algún hack o, en el mejor de los casos, planteamos el uso de comentarios condicionales para discriminar, en el mejor sentido de la palabra, las reglas que usamos en función del navegador.

Hasta aquí las cosas se pueden desarrollar con cierto orden y podemos decir que tenemos la sensación de que controlamos el desarrollo del trabajo. En función de nuestra pericia a la hora de transformar lo que vemos en un psd en un set de HTML y CSS, llegamos a dominar la situación sin excesivos problemas que, como ya he dicho, controlamos gracias al uso de algún que otro hack, o a través de comentarios condicionales.

En cualquier caso, lo importante de esta fase es que, por norma general, las reglas CSS vienen determinadas por los elementos de la pantalla que nos vamos encontrando a la hora de maquetar o escribir el código.

El desarrollo y crecimiento

Una vez que hemos iniciado el proceso de trabajo, y ya tenemos una cierta base sobre la que desarrollar la codificación HTML+CSS, los elementos que nos vamos encontrando para dar la capa de presentación, van creciendo, y en función de la variabilidad de los mismos, vamos viéndonos en la obligación de diversificar las reglas CSS para dar solución a todas y cada una de las situaciones concretas que tenemos ante nosotros.

Digamos que podemos entender la situación como controlable en el momento en que la variabilidad de los elementos a los que tenemos que dotar de diseño a través de CSS no crece demasiado. Y estoy hablando, ahora, sólamente de los elementos que tenemos en un mismo tipo de pantalla; es decir, elementos que aparecen en una o varias pantallas que tienen un mismo esquema.

Pero, ¿qué sucede cuando nos encontramos con elementos que creíamos similares, o iguales, y que cuando nos ponemos a aplicarles reglas que ya tenemos hechas, éstas no nos terminan de servir porque hay ligeras diferencias? Es entonces cuando se inicia la ruleta rusa de la multiplicación de reglas CSS muy parecidas. Y es el inicio de nuestra perdición 🙂

El problema

La cuestión es que en ese punto del desarrollo del trabajo nos podemos encontrar, y de hecho es lo más normal, con que la multiplicidad de opciones y elementos, sumado a la variabilidad de los mismos, y junto con las excepciones que tenemos que contemplar para que la visualización sea óptima en varios navegadores, hace que haya muchas probabilidades de que nos encontremos con un crecimiento sustancial tanto de las reglas como, lógicamente, del tamaño de la hoja de estilos. Esto nos traerá la espantosa consecuencia de la bajada escandalosa en el nivel de «manejabilidad» de la hoja de estilos.

La facilidad en el manejo y edición del fichero CSS es una de las piezas clave en el éxito de la agilidad de desarrollo. Por lo tanto, controlarla será uno de los objetivos que tendremos que perseguir. Y para ello nada mejor que contar con una planificación de la hoja de estilos, previa al desarrollo.

Algunas soluciones

Lo primero que se me ocurre que hay que tener en cuenta es una serie de puntos a controlar para que podamos construirnos un entorno de trabajo CSS que nos permita manejar y gestionar lo más posible todas las reglas a escrbir. Para ello se me ocurre que hagamos el ejercicio de responder a unas preguntas previas:

• ¿Conocemos el mapa de la web que vamos a codificar?
• ¿Conocemos el contenido real que va a tener el sitio web?
• ¿Tenemos la posibilidad de contar con contenidos reales del sitio web?
• ¿Existe un libro de estilo previo que describa los elementos que aparecerán en el sitio web?
• ¿Conocemos la estructura modular del desarrollo previsto para el sitio web?

Si tenemos una respuesta afirmativa a todas esas cuestiones, tendremos el camino muy fácil para poder componer nuestro entorno CSS planificado con anterioridad. Y si no lo tenemos, no nos quedará más remedio que hacer un ejercicio de imaginación racional para tratar de dar una respuesta lo más consecuente posible.

De ese modo, podremos componer una serie de reglas predefinidas, sin valores de aributos, que observemos que se repiten y son de uso frecuente.

Lógicamente cuantos más proyectos abordemos con esta metodología, más ajustaremos el entorno CSS y la velocidad de trabajo aumentará sin que se resienta la calidad del resultado final.

De todos modos, y como un modestísimo consejo de uso, podemos empezar por trazar unas líneas de trabajo básicas para diseñar un framework CSS que nos sea de utilidad:

1. Establezcamos un modelo de layout que contemple las siguientes características:
• Que sea flexible
• Que contemple al menos 3 columnas de organización de contenidos
• Que las columnas laterales sean intercambiables en su posición (derecha-izquierda) tan sólo cambiando los atributos de posición de las mismas
• Que contemple:
• Cabecera
• Navegación global
• Navegación local
• Contenido
• Zona de información relacionada y/o complementaria
• Pie de página
2. Establezcamos una serie de rejillas de disposición de contenidos:
• Rejilla en columnas fijas
• Rejilla en columnas flexibles
• Rejilla en columnas fijas y flexibles
3. Establezcamos una serie de patrones de diseño codificados:
• Logotipo con texto asociado
• Login
• Menú horizontal
• Menú vertical
• Párrafo de texto
• Párrafo de texto con imágen y pie de foto
• Listado simple vertical
• Listado simple vertical en varias columnas
• Serie de imágenes a modo de galería
• Tabla de datos

Con la definición de reglas para todos estos elementos podemos considerar que tenemos una serie de elementos más que resueltos, de tal modo que «sólo» nos quede pendiente asignar los valores de los atributos que las definan en cada proyecto.

Lógicamente esto es sólo un punto de partida, pero a medida que avancemos en el desarrollo del proyecto iremos definiendo las variaciones que de cada uno de estos elementos necesitemos.

Pero claro, con esto no está todo dicho. Ahora tenemos que considerar que las reglas ya definidas, o más bien predefinidas, pueden aparecer en diversas zonas o secciones del sitio web. Y es muy deseable que tengamos presente que los atributos asignados a cada una puedan variar en función del módulo o sección en la que se deban aplicar.

Por ello lo que propongo es que hagamos un ejercicio de dispersión de las reglas CSS en función de los módulos en los que podamos seccionar el sitio web. Así las cosas no deberíamos tener complejos, y diseñar una serie de ficheros CSS específicos para cada sección del sitio web, adaptando las reglas a definir en cada uno de ellos, de tal modo que cuando estemos en faena, es decir, asignando atributos a las reglas, tengamos la libertad de elección suficiente como para que los atributos que usemos para una sección no interfieran cuando los usemos en otra.

Lógicamente, deberemos hacer un cuidado trabajo de nomenclatura en las reglas, de tal modo que éstas tengan una serie de propiedades:

• Que tengan un marcado carácter semántico
• Que sean únicas
• Que su nomenclatura permita relacionarlas entre sí
• Que sean cortas (tengan el mínimo de caracteres posible)
• Que sean universales, es decir, que sirvan para todos los proyectos

Del tema semántico en las reglas CSS hablaré en el siguiente post de esta mini-serie.