Por qué Tailwind.

En los primeros años de la web, la apariencia se escribía dentro del HTML con etiquetas como <font>. El código se volvía difícil de mantener y no decía qué era cada cosa. En 1994 Håkon Wium Lie propuso las hojas de estilo en cascada (CSS), y a fines de 1996 CSS1 pasó a ser estándar.

De ahí salió una regla que se enseñó por años: el HTML dice qué es el contenido y el CSS, cómo se ve. En 2004 la W3C recomendó nombrar las clases por su función (aviso, submenu) y no por su apariencia (texto-azul). El CSS Zen Garden (2003) lo mostró en la práctica: un mismo HTML con cientos de diseños distintos.

La regla funcionaba bien en documentos. En sitios grandes y aplicaciones aparecieron los problemas: el CSS crecía sin control, nadie se atrevía a borrar una regla por si rompía otra página y los rediseños igual terminaban cambiando el HTML.

En 2009 Nicole Sullivan propuso OOCSS: piezas visuales reutilizables, cada una con su nombre. Bootstrap (2011) popularizó la idea con clases como .btn, .card y .alert. Esas clases nombran componentes, no apariencias, así que siguen la recomendación de la W3C. Lo que se le critica a Bootstrap es otra cosa: los sitios terminan pareciéndose, y personalizarlo obliga a pelear con sus estilos.

En 2013, en Yahoo, Thierry Koblentz propuso Atomic CSS: clases pequeñas que hacen una sola cosa, como un margen o un color, y que se combinan en el HTML. En 2017 Adam Wathan, creador de Tailwind, explicó el porqué: con clases semánticas el CSS igual depende del HTML, porque se escribe para las clases que el HTML expone. La separación es menor de lo que parece. Con utilidades, en cambio, el CSS es un conjunto fijo de piezas y el HTML las combina.

Tailwind es esa idea con un sistema de diseño detrás. Las utilidades salen de una escala de espacios, tamaños y colores que se configura una sola vez. En Solar, esa configuración son los tokens.

• HTML semántico, siempre. Cada cosa con su etiqueta: <h1> para el título, <button> para una acción, <table> para datos. Las utilidades cambian las clases, no el significado del HTML, que es lo que leen los lectores de pantalla y los buscadores.
• Interfaz con utilidades y tokens. Cada componente lleva las clases que definen su apariencia, con los tokens de Solar (bg-ccs-blue, text-ccs-h2). Hoy Solar entrega cada componente como un fragmento de HTML que se copia completo. Cuando existan componentes reales (por ejemplo, en React), se va a reutilizar el componente y no la lista de clases.
• Lo que define el token no se repite. text-ccs-h1 ya trae tamaño, interlineado y peso, así que un título no suma font-semibold ni leading-none.
• Texto largo con prose. Para contenido escrito por personas, como el que viene de un editor o un CMS, Tailwind ofrece el plugin Typography: la clase prose da estilo a los párrafos, listas y tablas de un bloque sin poner clases en cada uno. Solar lo está configurando con sus mismos tokens.
• CSS propio solo donde Tailwind no llega. Estados como data-open, gradientes, animaciones y máscaras. Ese CSS usa los valores de los tokens, nunca colores sueltos.
• CDN para Solar; en producción, todo alojado. Solar carga Tailwind, los íconos y las tipografías por CDN para estar siempre al día sin mantener un build. Un proyecto que sale a producción compila Tailwind con Solar como preset y aloja en su propio servidor los íconos y las tipografías (Inter y JetBrains Mono). Ver Instalación.

Tailwind ya trae escalas completas de espacios, tamaños de texto, pesos y colores, y su configuración está hecha para que cada proyecto sume sus propios valores. Solar crea un token solo en dos casos:

1. Tailwind no tiene el valor. Los colores de la CCS, el radio de 15 px y estilos como Body (16/26), Body XL (22/32) o H1 Hero (80/72).
2. Es una decisión de marca que debe cambiar en todo el sitio a la vez. Los ocho estilos de Textos y tipografías son la jerarquía de la CCS y funcionan como un set. Por eso H2, H3, Body L y Caption tienen nombre Solar aunque midan lo mismo que text-3xl, text-xl, text-lg y text-xs: si cambia el H2, cambia en un solo lugar.

Todo lo demás se usa tal como viene en Tailwind: espacios (h-10, px-4), pesos (font-medium) y el texto de interfaz de botones, campos, menús y tablas (text-xs, text-sm, text-base). Así trabajan también las colecciones de componentes más usadas con Tailwind: colores y radios propios, y text-sm en sus botones.

No se usan valores sueltos entre corchetes, como text-[14px]. Las únicas excepciones son las etiquetas de las muestras de color (9 y 10 px), los rellenos de imagen (8 px) y el tamaño de los íconos. Cada vez que se corre el build de Solar, este revisa los tamaños de texto y lista lo que no cumple.

• Cascading Style Sheets, tesis de Håkon Wium Lie (2006).
• A Look Back at the History of CSS, The History of the Web.
• Use class with semantics in mind, W3C (2004).
• OOCSS, Wikipedia.
• Challenging CSS Best Practices, Thierry Koblentz (2013).
• CSS Utility Classes and "Separation of Concerns", Adam Wathan (2017).
• Reusing Styles, documentación de Tailwind.
• Theme Configuration, documentación de Tailwind.
• Tailwind CSS Typography, el plugin de prose.