CSS orientado a objetos (OOCSS)

Esta semana vi una presentación fabulosa sobre nuevas técnicas de desarrollo CSS: CSS orientado a objetos (OOCSS). Nicole Sullivan, nos cuenta una forma interesante –que no es nueva pero tampoco se consolidó de forma oficial– de desarrollar CSS para sitios de grandísima escala como lo es Yahoo!, pero que también sirve como buena filosofía de desarrollo para sitios pequeños y medianos.

La idea básica se resume en crear componentes de estructuras que sirvan a lo largo de todo el sitio, y luego, mediante hojas de estilo particulares (o personalizadas) puedas extender lo que necesites a medida que vayas creando nuevas estructuras. De esta forma defines por ejemplo: módulos de contenido, de menús, de listas, de pestañas, de cabecerazas, etc. Hasta aquí, no hay misterios, todos hacemos esto en parte.

En Tractis empezamos un primer framework hace 2 años, crecimos de 0 a 100 en menos de un año lo cual nos ha causado algunos inconvenientes para poder crecer de forma orgánica y rápida con nuestro primer intento modelo. Esto lo anotamos en cuentas pendientes y con nuestra nueva interfaz agregamos más capas de “abstracción” que normalmente necesitaríamos. Nuestra estructura actual es esta:

1. authentication-pasarela.css
2. authentication.css
3. homepage.css
4. iehack-customs.css
5. lightbox.css
6. main.css
7. print.css

Mirando los nombres de los archivos podrán deducir algunas partes de Tractis y otras no. Nuestra hoja principal, es la hoja main.css la que nos permite tener todas las estructuras de Tractis definidas, digamos que es la que tiene todos los frameworks actuales: formularios, layouts, colores, tipografías, contratos, etc. Bien, el problema de trabajar así es que con el tiempo el tema se hace inmanejable y pierdes conciencia de todas las estructuras del sitio y terminas creando nuevas hojas de estilos para casos particulares que tienen sus propias estructuras, colores, etc.

Nuestro nuevo framework que venimos trabajando ordena este caos y nos permite hacer unas cositas extra que os vendría de maravilla si podéis aplicar. Para empezar, tenemos un conjunto nuevo de hojas de estilo numeradas:

1. 01-layouts.css
2. 02-fonts.css
3. 03-header.css
4. 04-nav.css
5. 05-subheader.css
6. 06-alerts.css
7. 07-content.css
8. 08-menus.css
9. 09-buttons.css
10. 10-footer.css
11. 11-list.css
12. …

Al principio os parecerá un caos, ¡más de 11 hojas de estilo por página!, pero no es así. En realidad, usamos más de 11 hojas de estilo pero en el momento de subida, un proceso automático las une en una, que denominaremos main.css. Bien, ese es nuestro humilde acercamiento a lo que vendría a ser un framework de CSS. Ya hablamos de lo bueno que era usar este tipo de modalidad de desarrollo, pero lo bueno de hacerlo en particiones es que es más organizado de actualizar y hacer crecer. No es lo mismo entrar un día a un archivo de CSS con 1500 líneas de código y ponerse a ver todas las dependencias y herencias que tenga a hacerlo en sólo un trozo de archivo en concreto.

Siguiendo el tema, esta organización nos permite definir dónde se alojarán nuestros componentes. Cada componente tendrá una cantidad de clases características que reutilizaremos a lo largo de nuestro sitio. Cada componente se basa en una serie de estructuras que ya hemos definido y creado, estas las definimos en el código con una serie de clases que reutilizaremos a nuestro gusto, para que esta regla se cumpla, como explica Nicole se deben dar estas condiciones:

1. Debe estar formado por clases y no debe estar formada por IDs.
2. Debe tener colores neutros, estos se deben formular luego aparte.
3. Debe tener cada parte definida y parametrizada.
4. Esta estructura debe poder ubicarse en cualquier parte del sitio y reaccionar ante las reglas.

La primera regla nos permite tener libertad. Los IDs en general nos traen conflictos para reproducir estructuras. Mucha gente usa un ID para definir por ejemplo un listado pero si un bendito día decidimos poner dos listados en un mismo documento ya se armó la gorda. Por eso, definir un tipo de menú conviene más utilizar una clase que un ID. Los IDs son excelentes para definir estructuras padre, las cuales nos ayudan a definir herencias simples con más comodidad pero nunca, nunca, las características de un módulo en particular.

La segunda regla, es la de parametrizar y definir cada parte de un módulo. Por ejemplo, en nuestro framework, tenemos definido los menús de esta forma:

<div class="menus">
  <div class="mtitle">
    <h3>Aquí va el título</h3>
  </div>
  <div class="mcontent">
    Aquí ponemos un contenido que definiremos en una hoja custom.css
  </div>
  <div class="mfooter">
    Aquí ponemos un pie de menú y <a href="/compare">Un enlace</a>
  </div>
</div>

De esta forma, sabemos qué partes tiene un módulo de menú, y nunca nos saldremos de esta línea de estructura. Teniendo la documentación de estructuras podemos hacer miles de menús de forma automática sin tener que dudar qué utilizar y qué no, pero lo mejor, como tenemos parametrizado todo, podemos, por ejemplo, quitar el pie de página de este módulo en particular y el menú seguirá teniendo un orden y una prolijidad¹ máxima.

Definiendo cada parte del sitio de esta forma, nos permite luego acelerar nuestros tiempos de desarrollo, incluso, nos viene bien para bocetar cosas ¡sin tener que tocar CSS! De esta forma, si la semana que viene queremos hacer una sección nueva en Tractis, sólo tenemos que escribir las estructuras básicas en una vista de plantilla sin tocar CSS:

1. Definimos si tendrá título o no.
2. Definimos un área de contenido (con una columna o dos).
3. Definimos los menús y su contenidos.
4. Definimos el tipo de contenido principal de esa sección: listas, tablas informativas, etc.

Así, lo que nos llevaría unas dos semanas de planear, armar y probar podemos reducirla a unos 2 o 3 días.

Me gustaría saber de vuestra mano qué tipo de organización utilizáis, y como desarrolláis vuestras estructuras de CSS y HTML en los proyectos, así seguimos este debate interesante.

¹ Prolijo: 2. adj. Cuidadoso o esmerado.

Por Diego Lafuente
Guardado en: Diseño | 1 comentario » | 3 de Abril de 2009