Forem: Ignacio Cuadra

ITCSS - Arquitectura CSS

Ignacio Cuadra — Wed, 26 Apr 2023 02:45:51 +0000

En un artículo anterior escribí sobre la importancia de las convenciones de nombre en CSS, haciendo especial mención a BEM, SUIT CSS y Title CSS. Hoy quiero seguir explorando el tema de la organización del código CSS, centrándome en las arquitecturas de estilo. Es esencial escribir código limpio y ordenado en proyectos grandes, y sin embargo, a menudo se pasa por alto cómo abordar el CSS en la arquitectura general del software.

En particular, me gustaría presentar la arquitectura ITCSS, que ha demostrado ser muy eficaz para organizar el CSS en proyectos grandes y complejos. Con ITCSS, el CSS se organiza en capas según su especificidad y su alcance, de forma que se pueda mantener una jerarquía clara y coherente.

A lo largo del artículo, exploraremos cada una de las capas de ITCSS y cómo se relacionan entre sí, así como los beneficios de su implementación. Espero que este artículo sirva como un recurso útil para aquellos que buscan mejorar la organización y mantenibilidad de su código CSS.

El triángulo

El triángulo invertido (Inverted Triangle CSS) de ITCSS es el que le da el nombre a esta metodología.

La arquitectura ITCSS nos indica que la organización del código CSS debe ser planteada en base a un triángulo invertido, según la especificidad. Esto significa que las reglas de estilo más generales y básicas se agregan primero, y las reglas específicas que sobrescriben el comportamiento como las clases de utilidad (utility classes) se agregan al final.

Cabe señalar que si bien puedes implementar esta metodología con CSS puro, ya sea en un archivo o multiples archivos, es recomendable el uso de preprocesadores como SASS o alguna herramienta de empaquetado que facilite la separación de cada una de las capas y componentes en documentos independientes para luego ser compilados.

Conceptos

Si te preguntas el por qué de un triangulo invertido, bueno, es por lo siguiente:

Como se especifica en la imagen, mientras mas grande es la sección, el alcance es mayor. Y de manera contraria, Mientras mas pequeña es la sección el CSS debe ser mas explicito y especifico.

Estos conceptos describen como debe ir organizado nuestro código en un archivo .css

Como te habrás dado cuenta, en esencia, los tres conceptos presentados en la imagen son similares y uno es consecuencia del otro. Con una explicación, todo será mas fácil:

De genérico a explícito

Se debe empezar escribiendo CSS genérico de bajo nivel y progresivamente escribir CSS más especifico y explicito. Osea, podríamos empezar con un reinicio o normalización de CSS, continuar reglas del tipo h1, h2, h3, etc. E ir progresando hasta llegar a reglas tan explicitas como .text-center

De baja especificidad a alta especificidad

Empezaremos con reglas de baja especificidad y progresivamente se codificarán reglas de alta especificidad. Con esto evitaremos conflictos y con ello, evitaremos el uso de la clausula !important.

De amplio alcance a corto alcance (localizado)

Inicialmente, las reglas CSS afectaran directamente al DOM y a medida que se avance en el documento CSS, nos encontraremos con reglas mas localizadas por medio de clases.

Capas

Habiendo entendido la generalidad de la idea, es momento de abordar cada una de las capas que nos presenta ITCSS.

Settings

La primera capa y con mayor alcance es la capa de Settings. Esta solo debe ser utilizada si haces uso de un preprocesador como lo es SASS, y es donde definimos las variables o configuraciones globales de nuestro proyecto. El tamaño base de letra, paletas de colores, etc.

Tools

La siguiente capa hace referencia a todas esas herramientas (mixins o funciones) que puedan ser utilizados por las siguientes capas.

Generic

Esta es la primera que realmente produce CSS. Alberga todos los estilos de alto nivel y amplio alcance que buscan eliminar u homologar el estilo entre navegadores, o también, establecer una configuración estándar que será base en todo el proyecto. El típico código de ejemplo es el siguiente:



* {
  box-sizing: border-box;
  margin: 0;
  padding: 0;
}

Esta capa por lo regular es estándar y puede ser reutilizada en multiples proyectos. Aprovecho de listar algunos ejemplos que ha elaborado la comunidad para que puedas utilizar en tus proyectos:

MiniReset.css- Un pequeño reinicio de CSS moderno.
Normalize.css - Un conjunto de reglas CSS que brindan una mejor coherencia entre navegadores en el estilo predeterminado de los elementos HTML.
Sanitize.css - Un conjunto de reglas CSS que se adaptan a las mejores prácticas de hoy en día listas para usar.

En algún futuro artículo pretendo hablar mas extensamente de la diferencia entre un normalize y un reset y cual es mejor a mi parecer. Spoiler: Normalize casi el 100% de las veces.

Elements

Estos son elementos HTML sin clases. ¿Cómo se ve un h1 sin una clase en él? ¿Cómo se ve un a sin una clase? La capa de elementos solo usa selectores de tipo. Es un poco más explícito que la capa anterior en el sentido de que ahora decimos "haz que cada h1 sea así de grande", o "haz que cada a sea de un cierto color".

Objects

A partir de aquí empezamos a usar selectores de clases. Los objetos son elementos reutilizables con una mayor especificidad que los descritos en la capa Elements. Ejemplos concretos serían los típicos .button, .wrapper o .table. Es estilo que no nos sentimos cómodos colocandolo por medio de un selector de tipo como button debido a que en algún contexto puede que queramos utilizar el mismo tipo de elemento pero con otro estilo como por ejemplo, un botón que parezca un link.

En este punto también incluimos los modificadores de dichos objeto como lo sería .button--danger o .button--outline. Sin embargo, acá no debemos colocar modificadores globales (clases de utilidad) como .--text-center. Estos últimos forman parte de la capa "Trumps".

Components

Los componentes son las secciones independientes de nuestro sitio web. Acá nos podemos encontrar con el típico .header o .card que se componen de un conjunto de elementos y objetos. También es aquí donde pondremos modificadores de componente como .card--dark y elementos desentiendes como .card__title.

Trumps

Por ultimo tenemos la capa Trumps, la capa que "triunfa" sobre el resto. En esta capa podemos sobre escribir todo, y es donde seguramente estén todos nuestros !importants. Es aquí donde están nuestras clases de utilidad como --text-center.

Partials

Por último nos queda abordar los Parciales (Partials). Cada capa tiene sus parciales, aquellas partes de código que, por temas de orden, preferimos colocarlos en archivos independientes. Por convención, Harry Roberts (el creado de esta metodología) propone usar los nombres _<capa>.<parcial>.scss (por ejemplo: _settings.colors.scss, _elements.headings.scss o _components.tabs.scss).

Resultados

Para concluir, de usar esta metodología con un preprocesador, deberías terminar con un styles.scss como el siguiente:



@import "settings.global";
@import "settings.colors";

@import "tools.functions";
@import "tools.mixins";

@import "generic.box-sizing";
@import "generic.normalize";

@import "elements.headings";
@import "elements.links";

@import "objects.wrappers";
@import "objects.grid";

@import "components.site-nav";
@import "components.buttons";
@import "components.carousel";
@import "trumps.clearfix";
@import "trumps.utilities";
@import "trumps.ie8";

Código extraído de Manage large CSS projects with ITCSS

Conclusiones

Esta metodología es altamente efectiva para gestionar proyectos extensos y complejos. Al utilizarla, podrás mantener tu CSS organizado y fácil de mantener, y te despreocuparás de colisiones y redundancias. Sin embargo, como cualquier arquitectura, es importante considerar el costo que implica su implementación. Generar una arquitectura CSS no es algo que deba hacerse en todos los proyectos, ya que puede requerir un esfuerzo y tiempo excesivo si se trata de un sitio web pequeño o una página de presentación. En estos casos, es posible que sea más oportuno utilizar sistemas de diseño como Tailwind o Bootstrap.

En un artículo futuro, presentaré un ejemplo práctico de cómo aplicar esta metodología a un proyecto en React.js o Solid.js, donde los objetos y componentes pueden tener su propio CSS modular.

Referencias

Manage large CSS projects with ITCSS

CSS - Convenciones de nombres: BEM, SUIT CSS y Title CSS

Ignacio Cuadra — Mon, 17 Apr 2023 16:45:01 +0000

Hay solo dos cosas difíciles en Ciencias de la Computación: Invalidación de caché y nombrar las cosas.

— Phil Karlton

De aquí a un tiempo esa cita a tomado especial relevancia en mi vida como desarrollador. Los proyectos en los que trabajo cada vez se hacen mas grandes y complejos, y esto no se limita solo al back-end, sino que también el front-end y como no, a CSS.

Afortunadamente hay guiás que nos ayudan a ponerle nombre a las cosas, estas guiás se denominan "Convenciones de Nombres" (Naming Conventions) y son fundamentales para escribir código limpio, ordenado y fácil de mantener.

Las convenciones de nombres nos ayudan a nombrar de forma consistente nuestras clases y a organizar nuestro código de manera coherente. BEM, SUIT CSS y Title CSS son algunas de las convenciones más populares que podemos utilizar para lograr esto.

BEM

En mi opinión, BEM es la metodología más ampliamente utilizada de todas. Como se indica en getbem, independientemente de la metodología CSS que utilices (OOCSS, SMACSS o ATOMIC), BEM te será de gran utilidad para organizar tu código de una manera que sea fácil de entender a primera vista.

Las reglas de BEM son simples y se resumen en tres conceptos principales:

1. Bloque (Block)

Sintaxis: <component-name>

El bloque encapsula una entidad independiente que es significativa por sí misma. Aunque los bloques se pueden anidar o interactuar, cada uno es independiente y tiene sentido por sí solo.

Por ejemplo, la clase .card es un bloque. Una .card recibe este nombre porque es un elemento independiente y reutilizable (por lo tanto, se utilizan clases en lugar de IDs). Puedes anidarla o listarla, pero sigue siendo independiente y reutilizable.

.card { background-color: #eee; }

2. Elemento (Element)

Sintaxis: <component>__<element-name>

Los elementos son parte de un bloque y, por lo tanto, dependen de este. Un ejemplo concreto podría ser un título para el bloque .card. La clase CSS se forma combinando el nombre del bloque con dos guiones bajos y el nombre del elemento:

.card__title { color: #111; }

Cabe señalar que, debido a que los elementos ya indican en su nombre a qué bloque pertenecen, no es necesario indicar su dependencia en el código.

Mal

.card .card__title { color: #111; }

Bien

.card__title { color: #111; }

3. Modificador (Modifier)

Sintaxis: <component|element>--<modifier-name>

Los modificadores son todos aquellas clases que modifican o agregan estilo a un bloque o elemento. La clase CSS se forma como el nombre del bloque o elemento más dos guiones.

Por ejemplo, en determinados contextos, es posible que deseemos cambiar el color de una .card.

.card--dark { background-color: #111; }

Nuevamente, como su nombre lo indica, este modificador solo debe usarse en elementos de .card y, por lo tanto, no es necesario añadir dicha restricción al CSS.

Mal

.card .card--dark { background-color: #111; }

Bien

.card--dark { background-color: #111; }

Nota sobre BEM

Como habrás notado, tanto los elementos como los modificadores tienen un carácter que los identifica (_ o -), y este carácter se repite dos veces. Esto es para diferenciar el uso de estos caracteres como una utilidad semántica en lugar de un separador de nombre común. Por lo tanto, es perfectamente aceptable usar cualquiera de estas dos opciones:

.card__sub-title { color: #111; }

.card__sub_title { color: #111; }

La elección entre ellos dependerá de tu equipo y su preferencia. Lo importante es ser coherente y utilizar siempre la misma opción en tu código.

SUIT CSS

SUIT CSS se basa en nombres de clase estructuradas y guiones significativos (es decir, no usar guiones simplemente para separar palabras).

SUIT CSS divide las clases en dos principales conceptos: utilidades (utilities) y componentes (components)

Utilidades (Utilities)

Sintaxis: u-[sm-|md-|lg-]<utilityName>

Las utilidades son recursos de "bajo nivel estructural" que se pueden aplicar directamente a cualquier elemento dentro de un componente. En esencia, son modificadores globales. Si conoces TailwindCSS estarás familiarizado con las utilidades (TailwindCSS solo utiliza utilidades).

Un marco CSS de utility-first repleto de clases como .flex, .pt-4, .text-center y .rotate-90 que se pueden componer para crear cualquier diseño, directamente en markup.

— TailwindCSS

En SUIT CSS las utilidades deben partir con la letra u continuado por un guion y su nombre en camelCase. A su vez, SUIT CSS hace la salvedad de que si hay un modificador de tamaño como sm, md o lg se debe agregar entre la u y el nombre con otro guion extra de separación. Ejemplos de esto sería:

.u-floatLeft { float: left; }
.u-block { display: block; }
.u-md-block { /* ... */ }

Si bien la documentación de SUIT CSS no lo indica, para las utility class puede ser útil agregar la clausula !important. En mi opinión, este es el único contexto en donde está bien hacer uso de !important dado que en ningún caso deberías utilizar dos clases de utilidad que sean contradictorias.

.u-floatLeft { float: left !important; }
.u-block { display: block !important; }

Esto solo tiene sentido si utilizas clases de utilidad que sean atómicas, osea, que apliquen un solo estilo. Nuevamente, en mi opinión, las clases de utilidad deben ser atómicas.

Compoenentes (Components)

Sintaxis: [<namespace>-]<ComponentName>[-descendentName][--modifierName]

A diferencia de BEM en SUIT CSS los componentes pueden ser cualquier elemento al que queramos darle un nombre semántico sin importar si depende o no de otro componente.

Todo componente debe tener un nombre en PascalCase. Opcionalmente, separado por un guion - puede tener de prefijo un namespace en lowercase.

.twt-Button { /* ... */ }

Los sub-componentes deben estar escritos en camelCase deben tener de prefijo a su componente padre separado por un guion.

.Card-title { /* ... */ }

A su vez, los componentes pueden tener modificadores, descritos en camelCase y separados por dos guiones.

.Card--dark { /* ... */ }

Un ejemplo de todos esto utilizado a la vez sería el siguiente:

.twt-Card-title--bold { /* ... */ }

Estados

Sintaxis: <stateName>

Nota: Solo utilizar bajo el contexto de un componente (y por tanto, dependiente de este).

Adicionalmente, los componentes pueden tener estados como un .alert con .is-danger para notificar un error, o una card con .is-loading cuando su contenido esta cargando.

Estas deben estar descritas en camelCase.

.Commentary.is-expanded { /* ... */ }

Variables

Sintaxis: --ComponentName[-descendant|--modifier][-onState]-(cssProperty|variableName)

A su vez, SUIT CSS nos da un lineamiento de como definir nombres de variables. Estas se agrupan en dos tipos: Variables de componente y variables de tema.

Variables de Componente (Component Variables)

SUIT CSS bajo la premisa de que las propiedades son globales y los componentes no deben exponer su estructura interna, define que las variables de componente deben tener una estructura plana después de su namespace.

:root {
  --ComponentName-backgroundColor
  --ComponentName-descendant-backgroundColor
  --ComponentName--modifier-backgroundColor
  --ComponentName-onHover-backgroundColor
  --ComponentName-descendant-onHover-backgroundColor
}

En mi opinión, el uso de variables de componente debe mantenerse al mínimo (o idealmente no usarse). Las variables en CSS pretenden ser una guía de estilos general. Requerir variables de componente puede ser que sea un síntoma de que nuestro diseño no es coherente.

Variables de Tema (Theme Variables)

Las variables que no son componentes deben escribirse en camelCase. Para uso compartido, deben crearse en un archivo theme.css.

:root {
  --fontSize: 16px;
  --fontFamily: sans-serif;
  --lineHeight: 1.4;

  --spaceSmall: 10px;
  --spaceMedium: 15px;
  --spaceLarge: 20px;
}

Title CSS

Title CSS nace con una premisa que se puede resumir en: BEM es útil, pero tiene nombres largos. Resumamoslo.

Para ello define tres conceptos: Title (lo mantendremos en ingles, puesto que le da el nombre a la convención), descendientes y modificadores.

Title

Sintaxis: <TitleName>

Los titles (o títulos) son lo que en BEM conocemos como bloques. Deben ser descritos en PascalCase

.Title { /* ... */ }

Modificadores

Los modificadores, al igual que en BEM, son clases que modifican el estilo de un componente o descendiente. Deben ser descritos en camelCase. De ser necesario que el modificador solo afecte a cierto tipo de componente o descendiente, simplemente se anida como se hace nativamente en CSS.

.Title { /* ... */ }
    .Title.isModified { /* ... */ }

Descendientes

Los descendientes como su nombre lo dice son hijos de un Title, y por tanto dependen de este. Deben ser descritos en camelCase y anidados en CSS.

.Title { /* ... */ }
    .Title .descendant { /* ... */ }

Problemas y soluciones

Dos problemas que se nos vienen a la mente al usar esta metodología es: ¿Como distingo una modificación de un descendiente? y ¿Que pasa si tengo un modificador o descendiente anidado con el mismo nombre?

1. ¿Como distingo una modificación de un descendiente?

La respuesta es simple: Por el nombre que escojas. Esta metodología nos fuerza a escoger buenos nombres. Es fácil identificar cual es el modificador y cual es el descendiente entre estas dos opciones: .isDark y .title. El nombre debe ser descriptivo y no dar lugar a dudas.

2. ¿Que pasa si tengo un modificador o descendiente anidado con el mismo nombre?

Un ejemplo respecto a este problema es el siguiente HTML.

<div class="Container">
    <header class="header"></header>
    <main class="body">
        <section class="Title">
            <div class="header"></div>
            <div class="body"></div>
        </section>
        <section class="Title">
            <div class="header"></div>
            <div class="body"></div>
        </section>
    </main>
</div>

Pareciera que hay colisiones de nombre, pero si usamos CSS de la forma natural nos encontraríamos con algo como esto:

.Container {}
    .Container > .header {}
    .Container > .body {}

Por tanto .header y .body solo afectarían al descendiente directo y por tanto, ya no tenemos colisiones de nombre.

Conclusiones

Estas tres convenciones de nombre nos ayudan a tener un mayor dominio de nuestro código. Algunos de los beneficios que podemos encontrar en estas notaciones son:

Facilita la distinción de componentes, elementos y modificadores de forma clara (posiblemente, Title CSS un poco menos que otros).
Mantiene baja la especificidad de los selectores (Nuevamente, Title CSS un poco menos que otros).
Ayuda a desacoplar la semántica de presentación de la semántica de documentos (al hacer uso de clases con nombres coherentes y explicativos).

BEM tiene sus beneficios, y a mi parecer, es la mas conocida de todas. Si bien no describe el uso de utility classes se puede hacer uso de estas con ayuda de un prefijo u- o como yo lo prefiero, con dos guiones --

--float-left { float: left; }

Sin embargo, aun cuando el uso de PascalCase o camelCase me choco en un primer momento. Me decanto por SUIT CSS, es a mi parecer la mas completa, y si bien estoy totalmente de acuerdo con Title CSS respecto a lo "molesto" que puede ser clases tan extensas, creo que lo vale. Sobre todo si tienes un editor de código bien configurado que te auto completa, es una maravilla escribir Card-- y ver todas los modificadores que tiene Card.

Por lo demás es decision de cada equipo definir que notación usar, ya sea alguna de estas, alguna otra o una definida por el mismo equipo. Siempre y cuando se sea consistente, todo irá bien.