CSS
Explica cómo un sistema de diseño conecta principios, tokens, componentes, documentación y gobernanza, y cómo Atomic Design ayuda a clasificar piezas.
Un sistema de diseño conecta decisiones visuales, componentes, contenido y reglas de uso para construir productos coherentes.
principios
↓
tokens
↓
componentes
↓
patrones
↓
experiencias realesSon piezas elementales del sistema:
<button class="button" type="button">Guardar</button>Un átomo sí puede tener significado y comportamiento propio. Decir que “no tiene significado por sí mismo” sería incorrecto para un botón, un enlace o un input.
Combinan piezas pequeñas para resolver una tarea concreta.
<form class="search-form">
<label class="sr-only" for="query">Buscar</label>
<input id="query" name="q" type="search">
<button type="submit">Buscar</button>
</form>La unidad completa tiene un contrato de contenido, estado y accesibilidad.
Agrupan varios componentes en una región más compleja:
Un organismo no debería conocer detalles internos de cada componente; los integra mediante APIs y slots claros.
Definen estructura y distribución de una experiencia sin depender todavía de contenido específico.
header
main layout
sidebar opcional
footerEn desarrollo real pueden corresponder a layouts, page shells o composiciones de rutas.
Son instancias con contenido, datos, estados y restricciones reales.
Una page revela problemas que una plantilla vacía no muestra:
<header>
<nav>...</nav>
</header>No significa automáticamente que nav sea una molécula y header un organismo. Las categorías dependen del sistema y la responsabilidad, no de cuántos nodos contiene el markup.
.button {
background: var(--color-action-primary);
color: var(--color-on-action);
border-radius: var(--radius-control);
}Los tokens conectan decisiones globales con componentes. El componente transforma esos valores en una interfaz usable.
Un buen componente documenta:
Button
├─ variant: primary | secondary | danger
├─ size: compact | default
├─ state: loading | disabled
└─ content: label + optional iconNo añadas variantes para cada página. Una variante debe representar una necesidad reusable.
Para un input no basta mostrar el default:
empty
filled
focus
invalid
disabled
readonly
autofilled
loading
successCada estado necesita contraste, nombre, feedback y comportamiento correctos.
Una unidad reusable implementable, como Button o Dialog.
Una solución de interacción o composición, como confirmación destructiva, filtros o formulario de checkout.
Un patrón puede combinar varios componentes y reglas de producto.
Una biblioteca debe mostrar:
Storybook u otra herramienta facilita exploración, pero no reemplaza documentación conceptual ni pruebas.
Un componente no está completo solo por verse consistente.
Button necesita:
Estos requisitos pertenecen al sistema, no a una corrección posterior.
Cambiar un token o componente puede afectar muchas aplicaciones.
Distingue:
Publica migration notes cuando el consumidor deba actuar.
Un sistema mantenible necesita responder:
Sin gobernanza, la biblioteca puede acumular duplicados aunque el diseño inicial sea bueno.
Aporta para:
No resuelve automáticamente:
<article class="project-card">
<img
class="project-card__image"
src="domisys.webp"
alt="Dashboard principal de DomiSys"
>
<div class="project-card__content">
<h2 class="project-card__title">DomiSys</h2>
<p>Sistema de gestión para negocios.</p>
<a class="button" href="/portfolio/domisys">
Ver proyecto
</a>
</div>
</article>La card combina medios, contenido y un control reusable. Su categoría importa menos que un contrato claro.
¿Por qué un botón puede considerarse átomo y aun tener significado propio?
Porque “átomo” describe su nivel de composición dentro del sistema; el elemento button conserva semántica, foco, teclado y comportamiento propio.
Utility-first, Tailwind y estrategias de styling compara distintas formas de producir CSS sin confundir herramienta y lenguaje.