El examen del módulo: tomar una landing y darle una arquitectura de diseño
real — un sistema de tokens de dos niveles, con escalas, y un tema
claro/oscuro completo que cambia todo re-apuntando solo los semánticos. De
"valores a mano" a "sistema", en la práctica. Es el trabajo que separa una
maqueta de un producto mantenible.
Reto
Tokeniza una landing y dale tema oscuro
Media60 min60 XP(×2 sin mirar la solución)
Qué debes construir
Toma tu landing del módulo 16 (o construye una hero + par de tarjetas) y
dótala de:
Tokens primitivos: paleta de grises + acento, escala de espaciado
base 4, escala tipográfica, radios y sombras.
Tokens semánticos que apunten a los primitivos (--color-fondo,
--color-texto, --color-primary, --color-superficie, --color-borde).
Componentes que usen SOLO tokens semánticos — ni un valor a mano.
Tema oscuro vía [data-theme="dark"] re-apuntando los semánticos, con
un toggle (y localStorage en tu versión real).
Transición suave del cambio de tema, respetando prefers-reduced-motion.
Reglas
Cero valores de color/espaciado/radio a mano en los componentes: todo por
token semántico.
El tema oscuro NO duplica componentes: es un bloque que re-apunta tokens.
Si conservas las animaciones GSAP del módulo 16, que sigan respetando
reduced-motion.
60:00
Cuando estés listo, arranca el reloj.
El razonamiento — la arquitectura se construye de abajo hacia arriba:
Primero los primitivos, luego los semánticos, al final los
componentes. Ese orden no es casual: cada capa depende de la anterior.
Los primitivos son la paleta cruda; los semánticos son las DECISIONES
(qué color es "texto", qué es "fondo"); los componentes solo consumen
decisiones. Con esa jerarquía, el tema oscuro toca UNA capa.
El tema oscuro vive en los semánticos, jamás en los componentes.[data-theme="dark"] re-apunta --color-texto, --color-fondo, etc. Los
componentes no se enteran — por eso no se duplica nada. Es la prueba de
que el sistema está bien montado: si tuvieras que tocar un componente
para el tema oscuro, la capa semántica falló.
El acento también es una decisión del tema. El mismo violeta no
funciona igual en claro y oscuro (contraste), así que --color-primary
cambia entre temas. Detalle de calidad que solo la capa semántica
permite sin dolor.
La landing tokenizada con tema, completa:
<div class="sitio"><header class="barra"> <span class="marca">◆ Forge</span> <button id="tema" class="toggle">Modo oscuro</button></header><section class="hero"> <span class="hero__eyebrow">Nuevo</span> <h1 class="hero__titulo">Diseño con sistema, no con suerte</h1> <p class="hero__sub">Cada color, espacio y radio sale de un token. El tema entero cambia re-apuntando semánticos.</p> <button class="btn">Empezar</button></section><div class="grid"> <article class="card"><h3>Tokens</h3><p>Una fuente de verdad.</p></article> <article class="card"><h3>Temas</h3><p>Un bloque, no duplicar.</p></article></div></div>
const boton = document.querySelector("#tema");const raiz = document.documentElement;// en tu versión real: leer localStorage aquí y aplicar el tema guardadoboton.addEventListener("click", () => {const oscuro = raiz.getAttribute("data-theme") === "dark";raiz.setAttribute("data-theme", oscuro ? "light" : "dark");boton.textContent = oscuro ? "Modo oscuro" : "Modo claro";// en tu versión real: localStorage.setItem("tema", oscuro ? "light" : "dark");});
Autoevaluación: ¿hay CERO valores de color/espacio/radio a mano en los
componentes (todo por token)? ¿El tema oscuro es un solo bloque que
re-apunta semánticos, sin duplicar componentes? ¿El acento se ajusta entre
temas? ¿La transición respeta reduced-motion? Cuatro síes: tu landing tiene
arquitectura de diseño real.
Qué sigue
Módulo 17 cerrado: tu CSS ya no crece hacia el caos, sino hacia un sistema
—tokens, temas, capas— que escala y conecta con Tailwind. El módulo 18
atiende los dos pilares que un producto profesional no puede descuidar:
ACCESIBILIDAD (que cualquiera pueda usar tu sitio) y RENDIMIENTO (que sea
rápido de verdad). El acabado que separa "se ve bien" de "está bien hecho".