Por qué Tailwind

Solar escribe sus estilos con Tailwind. Esta página cuenta de dónde viene esa decisión y qué reglas salen de ella.

El HTML limpio y el CSS aparte

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.

Cuando el CSS crece

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.

Clases utilitarias

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.

Cómo lo aplica Solar

• 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, peso y espaciado, así que un título no suma font-semibold ni tracking-tight.
• 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, build para producción. Solar usa el CDN de Tailwind para estar siempre en la última versión. Un proyecto que sale a producción usa un build de Tailwind con Solar como preset. Ver Instalación.

Cuándo Solar crea un token

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.

Fuentes

• 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.

¿Qué quieres hacer?

Solar asegura que lo que construyas se vea y funcione como la CCS. Esta guía te ayuda a que, además, resuelva el problema de quien lo va a usar.

Según tu rol

Pides o apruebas un proyecto

Tu parte está en el primer paso de cada ruta: definir el problema, o pedir un diagnóstico antes de un rediseño.

Desarrollas

Usa los componentes y los tokens de Solar tal cual. Si falta algo, avísalo al equipo de Solar en vez de crear una variante propia.

Construyes con IA

Antes de pedirle algo a la IA, indícale los recursos de Solar y parte con el prompt «Antes de construir». Lo que armes con Tailwind por CDN es un prototipo, no un producto terminado.

Antes de partir, revisa las reglas: aplican a cualquier proyecto con Solar.

Crear algo nuevo

Siete pasos, desde el problema hasta el lanzamiento.

1. 1
   Define el problema antes que la pantalla

   • Responde: ¿qué problema resuelve?, ¿para quién?, ¿cómo lo resuelven hoy?, ¿qué sabes por evidencia y qué es un supuesto?
   • Define si tiene un objetivo único (inscribirse, cotizar, pagar) o varios (un sitio institucional, una plataforma).

   Listo para avanzar cuando el problema, el usuario y el objetivo están escritos, y los supuestos están marcados como tales.

   Si pides o apruebas el proyecto: este paso es tuyo.

2. 2
   Habla con usuarios o mira datos antes de diseñar

   • Mínimo: 3 a 5 conversaciones cortas (unos 15 minutos) con usuarios reales, o una revisión de los datos que ya existen: analítica, soporte y reclamos.
   • Una conversación de 15 minutos antes de diseñar cuesta menos que rehacer una pantalla después.

   Listo para avanzar cuando hubo al menos un contacto real, y los supuestos del paso 1 se confirmaron o se ajustaron.

3. 3
   Arma con Solar

   • Parte por los componentes del catálogo.
   • Si Solar ya tiene un componente, úsalo. No uses colores, tamaños ni espaciados fijos: usa los tokens.
   • Si a Solar le falta algo, avísalo al equipo de Solar en vez de crear una variante propia.

   Si construyes con IA: indícale los recursos de Solar y parte con el prompt «Antes de construir».

   Próximamente

   Patrones y páginas de ejemplo.

   Prototipo no es producción

   Tailwind por CDN sirve para maquetas y prototipos. Si lo que armaste se va a usar de verdad, pide a un desarrollador que lo pase a un build precompilado de Tailwind antes de publicarlo.
4. 4
   Haz una revisión previa con IA

   • Usa los prompts «Crítica de página» y «Accesibilidad».
   • Corrige lo obvio. El reporte de la IA no es evidencia: no reemplaza la revisión de personas ni la prueba con usuarios.
   • Guarda la lista de lo que la IA no puede evaluar sin usuarios: la vas a usar en los pasos 5 y 6.
5. 5
   Muéstralo a otras personas

   • Muestra el trabajo a colegas e indica qué partes requieren validación.
   • Separa la crítica (explorar y mejorar) de la revisión (aprobar). No las mezcles en la misma reunión.
   • Pide feedback específico, justificado y accionable.
6. 6
   Valida con usuarios

   • No basta con preguntar si lo pueden usar: pregunta también si les resuelve el problema.
   • Técnicas ligeras: una prueba con 5 usuarios, sesiones cortas con personas parecidas a quienes lo van a usar, o un piloto con un grupo acotado.
   • Un piloto muestra uso, no utilidad: compleméntalo con conversaciones.

   Listo para avanzar cuando hay evidencia con usuarios (ver estados de evidencia). Si no fue posible conseguirla, la decisión queda marcada como supuesto a validar.

7. 7
   Lanza, mide y vuelve

   • Compara el uso real con los supuestos del paso 1.
   • Lo que aprendas vuelve a Solar: avísalo al equipo de Solar para ajustar un componente o documentar un problema conocido.

Mejorar algo que ya existe

Siete pasos para mejorar algo que ya está en uso, sin tener que rehacerlo todo.

1. 1
   Diagnostica antes de rediseñar

   • ¿Qué duele y cómo lo sabes? Reúne la evidencia que ya existe: analítica (dónde abandonan), soporte, reclamos y comentarios de usuarios.
   • Separa el problema de la solución que se pide. «Hay que cambiar el botón» es una solución, no un problema.

   Si pides o apruebas el proyecto: pide un diagnóstico antes de pedir un rediseño.

2. 2
   Compara con Solar

   • Lista los componentes de la pantalla actual y compáralos con Solar: qué ya existe, qué es distinto y qué falta.
   • Anota los valores fijos (colores, tamaños, espaciados) que deberían ser tokens.

   Próximamente

   Patrones y páginas de ejemplo. Por ahora, compara contra los componentes.
3. 3
   Haz una revisión experta

   • Primero, una revisión previa con IA («Crítica de página» y «Accesibilidad») para limpiar lo obvio.
   • Después, una evaluación con las heurísticas de Nielsen hecha por al menos 2 personas por separado. Una sola persona encuentra alrededor de un tercio de los problemas.
4. 4
   Prioriza

   • Ordena por impacto en la tarea del usuario, no por lo fácil que sea implementarlo. Lo más grave va primero.
5. 5
   Adopta Solar por capas

   • Primero los principios, después los lineamientos de UX y al final los componentes y el código.
   • No hace falta migrar todo de una vez.

   Si desarrollas: reemplaza los valores fijos por tokens y anota lo que le falta a Solar.

6. 6
   Valida el cambio

   • Prueba la versión mejorada con usuarios en las tareas críticas, y compara las métricas de antes y después.
   • Incluye personas nuevas: los usuarios actuales ya aprendieron a usar la versión anterior, con sus problemas.
7. 7
   Registra la decisión

   • Deja un registro breve: contexto, problema, decisión, alternativas consideradas y una referencia objetiva (una heurística, un criterio WCAG o un dato).
   • «Es buena práctica» no alcanza como justificación.

Reglas

Aplican a cualquier proyecto que use Solar.

1. Consistente no es lo mismo que resuelto. Solar asegura que algo se vea y se comporte como la CCS, no que resuelva el problema de quien lo usa.
2. Nada pasa a diseño final sin contacto real con usuarios, aunque sea una conversación corta o una prueba con 3 personas.
3. Separa supuestos de hechos. Lo que crees que necesita el usuario es un supuesto hasta que haya evidencia.
4. La revisión con IA es un filtro previo, no evidencia. No reemplaza la revisión de personas ni la prueba con usuarios.
5. El tiempo que ahorra la IA se usa para validar, no para lanzar antes.
6. Toda recomendación de UX en Solar indica su fuente y su estado de evidencia.
7. Las métricas de conversión muestran comportamiento, no si la pieza resolvió el problema.

Estados de evidencia

Indican si algo se probó con usuarios. Una decisión cerrada no es lo mismo que una decisión validada.

No cambian el estado: una revisión con IA, que la pieza esté hecha con Solar ni una buena métrica de conversión.

Hoy todos los componentes de Solar están en Supuesto.

Revisar con IA

Sirve para limpiar lo obvio antes de mostrarle el trabajo a otras personas. Copia el prompt, completa lo que va entre corchetes y adjunta una captura, una URL o el código.

Antes de construir

Para quien arma con IA. Úsalo al inicio, antes de que la IA escriba código.

Voy a construir [qué: una página, un flujo o un aplicativo] con Solar, el sistema de diseño de la CCS (https://utiliza.me/solar/llms.txt). Antes de escribir código:
1. Hazme las preguntas que necesites sobre el problema, el usuario y el objetivo. No asumas.
2. Propón qué componentes de Solar usarías y qué le falta a Solar para este caso.
3. Espera mi confirmación antes de construir.
Reglas: usa solo componentes y tokens de Solar. Si algo no existe, dilo en vez de inventarlo.

Crítica de página

Primera impresión, usabilidad, jerarquía y consistencia con Solar.

Contexto:
- Qué es: [página / flujo / aplicativo interno]
- Para quién: [usuario y su situación]
- Qué tiene que lograr el usuario: [tarea principal]
- Objetivo de la pieza: [único: ___ / varios]
- Etapa: [exploración / refinamiento / casi final]
- Sistema de diseño: Solar, de la CCS (https://utiliza.me/solar/llms.txt). Usa sus tokens ccs-* y sus componentes. No propongas valores fijos fuera del sistema.

Revisa esta página [adjunto una captura, una URL o el código]:
- Primera impresión: qué se ve primero, si es lo correcto y si el propósito se entiende en segundos.
- Usabilidad, con las 10 heurísticas de Nielsen como preguntas: ¿el usuario sabe qué está pasando?, ¿se habla su idioma?, ¿puede deshacer o salir?, ¿es consistente?, ¿se previenen errores?, ¿reconoce en vez de recordar?, ¿es eficiente para quien la usa seguido?, ¿sobra algo?, ¿los errores se entienden y se pueden corregir?, ¿hay ayuda cuando hace falta?
- Jerarquía visual y orden de lectura.
- Consistencia con Solar: componentes, tokens, espaciado y textos.

Formato de respuesta:
1. Hallazgos ordenados por gravedad (crítico / moderado / menor). Para cada uno: qué pasa, por qué importa (principio o criterio que lo respalda) y qué cambiar.
2. Las 3 a 5 correcciones de mayor impacto.
3. Qué funciona bien.
4. Qué no puedes evaluar sin usuarios reales: supuestos y preguntas que solo se responden probando con personas.
Rotula el resultado como "Revisión asistida por IA — no es evidencia de usuario".

Accesibilidad

WCAG 2.2 nivel AA.

Contexto:
- Qué es: [página / flujo / aplicativo interno]
- Para quién: [usuario y su situación]
- Qué tiene que lograr el usuario: [tarea principal]
- Objetivo de la pieza: [único: ___ / varios]
- Etapa: [exploración / refinamiento / casi final]
- Sistema de diseño: Solar, de la CCS (https://utiliza.me/solar/llms.txt). Usa sus tokens ccs-* y sus componentes. No propongas valores fijos fuera del sistema.

Audita [adjunto una captura, una URL o el código] contra WCAG 2.2 nivel AA (no 2.1). Incluye los criterios nuevos de 2.2: foco no oculto, tamaño mínimo de objetivo, ayuda consistente, entrada redundante, autenticación accesible y movimientos de arrastre. Mide el contraste con APCA-W3 0.1.9, no con la fórmula de WCAG 2: Lc 75 para texto de lectura, 60 para otros textos, 45 para texto grande (24px en negrita o 36px) e íconos de línea, 30 para textos auxiliares, íconos sólidos y bordes de campos, y 15 para líneas. No reportes como error lo que APCA aprueba, aunque WCAG 2 lo repruebe. Revisa también navegación con teclado, orden de foco, etiquetas de formularios y texto alternativo.
Indica qué no se puede verificar desde lo que adjunté y hay que probar a mano (teclado, lector de pantalla, zoom al 200%).

Formato de respuesta:
1. Hallazgos ordenados por gravedad (crítico / moderado / menor). Para cada uno: qué pasa, por qué importa (principio o criterio que lo respalda) y qué cambiar.
2. Las 3 a 5 correcciones de mayor impacto.
3. Qué funciona bien.
4. Qué no puedes evaluar sin usuarios reales: supuestos y preguntas que solo se responden probando con personas.
Rotula el resultado como "Revisión asistida por IA — no es evidencia de usuario".

Cómo leer el reporte

• Parte por los hallazgos críticos.
• La lista de lo que la IA no puede evaluar sin usuarios es tu punto de partida para mostrarlo a otras personas y validar con usuarios.
• El reporte no cambia el estado de evidencia.

Recursos para IA

Para que la IA use los componentes de Solar tal cual, en vez de inventar algo parecido.

Cómo está armado

• llms.txt, en este sitio: las reglas de Solar y el índice de componentes.
• Un .md por componente, con su HTML listo para usar.
• AGENTS.md, en tu proyecto: le avisa a la IA que programa en él que use Solar y lea el llms.txt.

llms.txt

Un archivo que le resume Solar a la IA: las reglas y dónde está el HTML de cada componente. La IA no lo busca sola: tienes que indicárselo.

Ver llms.txt

En un chat

Agrega esta línea al inicio de tu mensaje:

Usa Solar, el sistema de diseño de la CCS: https://utiliza.me/solar/llms.txt

En tu proyecto: AGENTS.md

Pega este fragmento en el AGENTS.md de la raíz de tu proyecto. Lo leen solas las IAs que programan en él, como Claude, Cursor o Copilot. Si el proyecto ya tiene CLAUDE.md, pégalo ahí: Claude Code lee ese archivo en vez de AGENTS.md.

## Sistema de diseño

Este proyecto usa Solar, el sistema de diseño de la CCS.
Antes de construir o modificar la interfaz, lee https://utiliza.me/solar/llms.txt

- Usa solo componentes y tokens de Solar (ccs-*). No uses colores, tamaños ni espaciados fijos.
- Si un componente no existe en Solar, dilo. No lo inventes.
- Antes de construir, haz preguntas sobre el problema, el usuario y el objetivo.

Cuidados

• Instala skills o conectores de IA solo de fuentes confiables: pueden ejecutar código en tu equipo.
• Si usas skills genéricas de diseño, mandan las reglas de Solar.
• Que la IA use Solar asegura consistencia, no que la experiencia esté validada.

Color

Los colores de la marca CCS y sus valores para pantalla e impresión. Los primarios y secundarios vienen del manual de marca; los neutros y degradados los define Solar a partir de ellos.

Los matices son el mismo color con menos intensidad, del 100% al 10%.

Para presentaciones, gráficos e ilustraciones, cuando los colores de marca no alcanzan. Es una propuesta de Solar, pendiente de validar con Marketing. En la interfaz, advertencia y error usan sus propios colores.

Orden para gráficos

Usa los colores en este orden, sin saltarte ninguno. Así cada color queda junto a uno que se distingue bien, también para personas con daltonismo. Acompaña los datos con etiquetas, para no depender solo del color.

Solar mide el contraste con APCA (Accessible Perceptual Contrast Algorithm). Predice mejor lo que vemos que la fórmula de WCAG 2: considera el tamaño y el grosor de la letra, y si el texto es claro sobre oscuro o al revés. El resultado se llama Lc: mientras más alto, más contraste.

Sobre Naranjo, WCAG 2 aprueba el texto oscuro y reprueba el blanco. APCA hace lo contrario, y coincide con lo que se ve.

Los colores y tokens de Solar ya cumplen: si los usas, no necesitas medir nada.

Las herramientas automáticas, como Lighthouse o axe, miden con WCAG 2 y pueden marcar como error combinaciones que APCA aprueba.

Voz y tono

Cómo se escribe todo texto de interfaz en Solar: botones, avisos, errores y etiquetas. Aplica a cualquier componente; cada componente solo suma lo que es propio de él.

1. Tuteo, con respeto. Escribe de tú, en español de Chile. Sin voseo (“abrí”, “copiá”) y sin el “usted” distante.
2. Sin tecnicismos. Usa las palabras de quien lee, no las del sistema. Nada de códigos de error, “servidor” ni “parámetro”.
3. Primero qué pasó, luego qué hacer. Una o dos frases. Si no hay nada que hacer, no inventes un paso.
4. Acciones con verbo y objeto. “Descargar informe”, no “Haz clic aquí”.

Historial de cambios

Qué cambió en Solar y cuándo, para que los equipos sepan si algo que usan se modificó. Aquí van solo los cambios mayores; las correcciones menores no se anotan.

Cómo se numeran las versiones

Solar usa tres números: mayor.menor.corrección. Mientras el sistema se construye, el número mayor es 0.

• Mayor: un cambio que obliga a los equipos a modificar su código, como renombrar o quitar un token o una clase. Solar pasa a 1.0.0 cuando se publique para su uso en producción.
• Menor: algo nuevo o rehecho que no rompe lo anterior: un componente, una variante, una regla o una página de documentación.
• Corrección: un arreglo que no cambia lo que se debe usar, como un color mal aplicado o un texto confuso. Se anota solo en el registro interno.

Cuándo se anota

• Cada cambio mayor se anota apenas se cierra, en la versión en curso.
• Una versión nueva se publica cada semana, con el cierre del viernes, si hubo cambios mayores.
• Un cambio que rompe código publica una versión mayor en el momento, sin esperar al viernes.

Próxima versión

Desde el 5 de octubre de 2026

• Portada rediseñada: foto a pantalla completa, título en el estilo nuevo Display y el logo de Solar a todo el ancho, con movimiento al hacer scroll.

Versión 0.4.0 Versión actual

29 de septiembre al 2 de octubre de 2026

• Componente nuevo: Tooltip.
• Tags & Badges reordenado, con variantes con ícono.
• Iconografía rehecha con Solar Icons: dos familias, color por tokens e íconos sobre degradado.
• Alertas rehechas, con siete variantes y estados con ícono.
• Nueva convención de las páginas de componente: el texto va suelto y la vista previa muestra solo el componente. Los “por qué” son desplegables.
• Textos y tipografías: estilos nuevos H1 Hero y Body XL, y se quita Display.
• Encabezado de cada ficha de componente rediseñado, con título grande, bajada e imagen.
• Menú móvil unificado en todo el sitio, con botón dividido en Docs y Componentes.
• Voz y tono, pie de página compartido con la nota para IA y token Naranjo (propuesta).
• Escala de texto como tokens: los ocho estilos de Textos y tipografías pasan a clases text-ccs-*, y los tamaños que no son de Tailwind se ajustan al más cercano.
• Texto de interfaz con text-xs, text-sm y text-base de Tailwind, y criterio de cuándo Solar crea un token.
• Títulos y párrafos de todo el sitio con los estilos text-ccs-*; los títulos de sección de Docs pasan al H2 de la escala.
• Página nueva en Docs: Por qué Tailwind.

Versión 0.3.0

22 al 28 de septiembre de 2026

• Modo oscuro: un color oscuro por cada color de la paleta, aplicado a todo el sitio y a los componentes.
• El contraste se mide con APCA. Paleta oscura y colores de estado (éxito, advertencia, error) ajustados.
• Color por función pasa a Componentes, en el grupo Base. Se elimina Docs › Modo oscuro.
• Recursos para IA: llms.txt, un archivo .md por componente y reglas permanentes.
• Sección Cómo trabajar en Docs.
• Pestaña Colores en Botones y Alertas; botón con ceja.

Versión 0.2.0

15 al 21 de septiembre de 2026

• Sidebar fijo y layout de ancho completo.
• Menú móvil con navegación interna de dos niveles.
• Las páginas de componente muestran bloques de variantes con pestañas Vista previa y Código HTML, en los 25 componentes.
• Norma de uso de JetBrains Mono; Botones con escala de tamaños nueva.

Versión 0.1.0

8 al 14 de septiembre de 2026

• Nace Solar como sistema de diseño, evolución del UI Kit de la CCS.
• Portada, header flotante y fondo claro definidos.
• Fundamentos cerrados: Work Sans, espaciado, breakpoints y modo oscuro en un solo nivel.
• Navegación del sitio: Documentación y Componentes, con catálogo completo.

Espaciado

Solar usa la escala de Tailwind, en múltiplos de 4px. Usa estos pasos para cualquier padding, margin o gap: elige el más cercano al espacio que necesitas.

Los pasos 0.5, 2.5 y 3.5 existen en la escala, pero solo se usan en ajustes finos dentro de un componente (por ejemplo, el padding de un badge). El espacio entre párrafos y listas está en Textos y tipografías.

Forma y sombra

Radios y sombras comparten página porque cada uno es, hoy, un solo valor con poco que contar por separado — el catálogo ya los agrupa igual, como "Forma y sombra".

Breakpoints

Tampoco es una escala nueva: es la escala completa por defecto de Tailwind, aunque hoy el sitio solo use tres de sus cinco pasos — nunca se sobreescribió screens en ccs-tailwind-config.js.

Al llegar el primer caso real que necesite xl/2xl, usar el paso de esta tabla — no inventar un ancho nuevo.

Glosario

Todavía no existía como página — arranca con los términos que ya se usan de hecho en la documentación de Solar. Se va a ampliar a medida que aparezcan más términos que valga la pena explicar.

Token de diseño

Una decisión de diseño con nombre propio y reutilizable — un color, un espaciado, un radio — guardada en un solo lugar (acá, ccs-tailwind-config.js) para poder cambiarla en todas partes a la vez, en vez de repetir el valor suelto en cada página.

Breakpoint

El ancho de pantalla en el que cambia el layout — por ejemplo, cuándo el menú del header pasa de verse completo a esconderse detrás de un botón de hamburguesa.

Átomo / molécula

Vocabulario de fases de Solar: un átomo es un componente indivisible (un botón, un input); una molécula combina varios átomos con un propósito propio (un formulario, una tarjeta). Fase 1 de Solar cerró fundamentos (tokens); fase 2-3 es cuando se cierran átomos y moléculas reales.

Spec cerrada / borrador

Así se marca el estado de cada decisión de Solar en docs/solar/specs/: 🟢 cerrada significa que ya se decidió y no se espera que cambie pronto; 🟡 borrador significa que una parte ya se resolvió pero falta algo (por ejemplo, un mecanismo de activación) antes de darla por terminada.