Mi visión sobre las “Arquitecturas” CSS.

Toda persona que se dedica al desarrollo sabe que, cuando te pones a trabajar, no abres tu IDE favorito y empiezas a picar código sin más. O no debería ser así. Lo normal es que, antes de codificar, hayas trazado un plan y tengas una metodología de desarrollo, una arquitectura que la soporta y unas guías que conducen el proyecto hacia la dirección correcta y que todo el equipo sigue fielmente. Pues hoy nos vamos a detener en CSS para hablar de metodología y debatir un poco.

He puesto Arquitectura entre comillas porque, aunque el término se usa comúnmente, cuando nos referimos a CSS, quizá la palabra le queda un poco grande. Y no porque CSS no sea suficientemente importante, sino porque cuando definimos y diseñamos cómo vamos a desarrollar el CSS de nuestra futura aplicación estamos creando el proceso (metodología) y no la estructura (arquitectura). Hablamos del “cómo hacer” (metodología) y no del “qué hacer” (arquitectura). Por ello, considero que es más ajustado a la realidad el hablar de metodología CSS que de “arquitectura CSS”.

Eso no quita que sea vital tener una metodología CSS en el proyecto. Hay una serie de objetivos que debemos cumplir y, por ello, debemos establecer la forma de garantizar su cumplimiento. Digamos unas cuantas obviedades:

• Nuestro CSS debe ser predecible (intuitivo, legible y descriptivo).
• Nuestro CSS debe ser reutilizable.
• Nuestro CSS debe ser mantenible.
• Nuestro CSS debe ser escalable.

Y, cuando definimos la metodología de nuestro CSS, debemos pensar, al menos, en cómo cubrir estos cuatro factores.

Afortunadamente, disponemos en la actualidad de varias metodologías que ya han sido definidas y probadas para solucionar dichos puntos. Veamos unas cuantas de forma sucinta:

OOCSS (Oriented Object CSS):

Como su nombre indica, es una metodología que se basa en el concepto de “objeto” CSS, es decir, un patrón visual repetitivo que puede encapsularse en un “pedazo” independiente de código HTML/CSS (incluso JS). Dichos objetos tienen que cumplir dos principios fundamentales: separación de la estructura de la visualización (utilizando skins que pueden aplicarse a distintos objetos) y separación entre contenedor y contenido (las características de un objeto son las mismas independientemente de lo que contenga). El objetivo fundamental de esta metodología es garantizar la reutilización y optimización del código CSS.

BEM (Bloque, Elemento, Modificador):

Esta metodología se basa en dividir el layout de una página en bloques independientes. Cada uno de estos bloques estará compuesto por elementos relacionados semántica y funcionalmente. Tanto bloques como elementos pueden tener modificadores que determinarán su apariencia, su estado o su comportamiento. Con estos tres conceptos, se crean una serie de convenciones de naming que ayudan a la predecibilidad del código, así como al mantenimiento y escalabilidad. El concepto de “bloque” ayuda a la reutilización.

ITCSS (Inverted Triangle CSS):

En esta ocasión, el objetivo principal es fijar la forma en la que se estructura el código que generamos. Para ello, se conciben una serie de secciones o capas que se organizan con la forma de un triángulo invertido: settings, tools, generic, elements, objects, components y utilities, en orden creciente de especificidad. Está muy orientado a garantizar la escalabilidad y la mantenibilidad del CSS.

He mencionado solo estas tres, aunque hay suficientes como para estar días enteros escribiéndolas, porque creo que son las más utilizadas y las que más presencia tienen en el mundo del desarrollo CSS. Además, tienen cosas que me gustan mucho.

OOCSS, solo con introducir la palabra “objeto”, ya aumenta 100 puntos la cantidad de molonismo del CSS (es lo bueno que tiene utilizar conceptos de otros lenguajes). BEM, con su estricta disciplina a la hora de nombrar los bloques y elementos, zanja de un plumazo los eternos debates entre maquetadores y termina con los excesos de creatividad en el bautismo de clases y las preferencias personales (el camel case, por ejemplo). Concebir el desarrollo de “objetos” o “bloques” casa bastante con los Sistemas de Diseño y los Web Components actuales, pero acaba convirtiendo todo en un exhaustivo catálogo de “piezas de lego” que solucionan problemas de grano muy fino. No se suele contemplar cómo se comportan unos objetos/bloques con otros, ni el layout general, ni el ritmo, la composición o el diseño especial de cada vista.

ITCSS, aunque se centra más en la organización del código, me parece un ejemplo magnífico sobre cómo funciona el CSS desde la globalidad hasta la especificidad. Sobre todo, muestra que si nos quedamos solo con los cinco pisos superiores, tenemos más de la mitad del trabajo hecho, y que la parte de estilos de componentización debería ser la excepción y no la norma. La realidad luego nos enseña que los ficheros “objects.css” y “components.css” son los más grandes, rompiendo la estilizada forma piramidal que tanto nos fascinaba.

Lo que comparten todas estas metodologías es la búsqueda de la reutilización, la mantenibilidad y la escalabilidad. Buenos propósitos, por cierto. Pero a veces parece que olvidamos que CSS por sí solo ya tiene interiorizados estos principios y creemos que, si no usamos ninguna metodología, nuestro desarrollo va a ser un maremagnum repetitivo e inmantenible de código. Aunque todas ellas tienen la palabra “CSS” en el nombre, realmente no versan sobre CSS, sino en cómo hay que organizar, cómo nombrar, cómo “trocear”. En mi opinión un cúmulo de obviedades ya que, si el CSS que desarrollamos es un desastre, por mucha capa, objeto, troceado y naming estricto que hagamos, el resultado final seguirá siendo lamentable. El éxito en el uso de cualquiera de estas metodologías radicará en que el CSS esté bien construido. Y en eso no entra ninguna de ellas.

CSS es un lenguaje complicado de usar. Su complicación no viene de la sintaxis, sino de la necesidad de comprender muy bien cómo funcionan las cosas en el navegador y cómo está concebido el estilado de un elemento. Obviar este conocimiento nos aboca al desastre.

El uso de una metodología no te garantiza el éxito. Y esto no sólo aplica a CSS, es agnóstico del lenguaje de programación. Como dice constantemente mi compi Eva Lozano “hay que ser cuidadoso y esmerado con el código que hacemos, porque un nombrado o una definición de arquitectura a alto nivel no asegura la calidad en absoluto”. Y creedla, que está curtida de tanto ayudar en proyectos que se desbocan y llevarlos hacia la luz.