Tokens de espaciado: nomenclatura y pasos

Los tokens de espaciado son entradas con nombre para los pasos de una escala de espaciado —space-4 o space-md en lugar de un 23px sin más— guardadas en una única fuente y consumidas por igual por las herramientas de diseño y el código. Convierten una lista de números en un vocabulario compartido: un espacio se elige por su nombre, y el nombre se resuelve al mismo valor en todos los lugares donde aparece.

Este artículo cubre las dos convenciones de nomenclatura dominantes y sus concesiones, los alias semánticos, cuántos pasos exponer y la ruta de exportación que lleva una misma escala a CSS, Tailwind y Figma. Da por hecho que ya existe una escala —el hub del sistema de espaciado explica cómo se construye una.

¿Por qué darles nombre a los pasos?

Porque los nombres son lo que convierte un menú en algo compartido. Una escala de espaciado limita qué valores existen; los tokens hacen que elegir entre ellos sea comunicable. Dos personas que buscan «el espacio entre campos de formulario» llegan al mismo token, donde quizá no llegarían al mismo número. También es más fácil retener en la cabeza ocho pasos con nombre que ocho valores en píxeles: nadie discute si un espacio debería ser 23px o 26px cuando la elección real está entre space-4 y space-5. La conversación sube un nivel —un paso más o un paso menos—, que es el nivel donde corresponde tomar las decisiones de espaciado.

¿Los tokens de espaciado deben usar números o tallas de camiseta?

Las dos convenciones de uso extendido, comparadas:

Ninguna columna gana. Los nombres numéricos escalan con elegancia y siguen siendo honestos sobre lo que son: posiciones en una escala; los nombres por talla de camiseta son más fáciles de decir y de recordar. Lo que duele es cambiar más tarde: los nombres de los tokens se extienden por los componentes, las hojas de estilo, las bibliotecas de diseño y la documentación, y un renombrado toca cada uno de esos sitios. Elige una convención pronto y deja que sea aburrida.

Sobre la cantidad de pasos: expón toda la escala y mantén la escala corta —entre 6 y 10 pasos le sirve a muchos productos—. Un conjunto de tokens mucho más grande que la escala que hay detrás es señal de que valores puntuales se están colando de nuevo bajo nombres nuevos.

¿Qué son los tokens de espaciado semánticos?

Alias que nombran una intención y apuntan a un paso: un gap-section que se resuelve a space-7, un padding-card que se resuelve a space-4. Los pasos en bruto siguen siendo la única fuente de valores; los alias registran por qué se eligió un valor.

La recompensa aparece cuando la escala cambia. Reescala el sistema —una base más grande, una razón distinta— y cada espacio entre secciones del producto se mueve al unísono, porque cada uno apunta a un alias que apunta a un paso. La intención del diseño sobrevive al reescalado, y nadie va a la caza de 64 escritos a mano. Mantén pocos alias y que sean genuinamente estructurales (secciones, tarjetas, ritmo de los formularios); un alias por componente reintroduce la dispersión que la escala se construyó para eliminar.

¿Cómo pasan los tokens del diseño al código?

A través de un formato de archivo neutral respecto a la herramienta. El Design Tokens Community Group define un formato JSON —DTCG— para los design tokens, de modo que un único archivo puede alimentar muchas herramientas. Una escala de espaciado exportada en el formato DTCG tiene este aspecto:

{
  "space": {
    "1": { "$value": "8px",  "$type": "dimension" },
    "2": { "$value": "11px", "$type": "dimension" },
    "3": { "$value": "16px", "$type": "dimension" },
    "4": { "$value": "23px", "$type": "dimension" },
    "5": { "$value": "32px", "$type": "dimension" },
    "6": { "$value": "45px", "$type": "dimension" },
    "7": { "$value": "64px", "$type": "dimension" }
  }
}

Los valores no son arbitrarios: son una escala real (base 16, razón 2, dos notas por intervalo), y ese es justo el punto: el archivo de tokens se genera a partir de tres números, no se ensambla a mano.

A partir de esa única fuente, los mismos pasos se representan como propiedades personalizadas de CSS, un bloque de tema de Tailwind v4 y Variables de Figma. Abre la vista de exportación en Scale Composer: la misma escala representada como tokens DTCG, propiedades personalizadas de CSS, Tailwind v4 y Variables de Figma. Cambia un parámetro de la escala y cada exportación lo refleja, porque las cuatro se leen a partir de los mismos pasos.

¿Por qué mantener Figma y el código sincronizados es un problema de tokens?

Porque la deriva es estructural, no moral. Cuando los diseñadores mantienen una lista de espaciado en Figma y los desarrolladores mantienen otra en CSS, las dos acaban discrepando tarde o temprano: alguien añade un paso en un lado, redondea un valor en el otro, y seis meses después el archivo de diseño y el producto describen en silencio sistemas distintos. Pedirle a todo el mundo que tenga más cuidado trata un problema de fuente como un problema de disciplina. Con una única fuente generada que alimenta ambos lados —Variables de Figma para el archivo de diseño, propiedades personalizadas o un tema para el código— las listas no tienen ocasión de divergir, porque ninguno de los dos lados mantiene una lista. Los dos leen una.

Exporta la misma escala a tu stack

Prueba el extremo del código de la ruta: exporta esta escala como un tema de Tailwind v4: los pasos llegan como un bloque @theme listo para pegar en una hoja de estilo. Luego añade una nota a la escala y vuelve a exportar: los pasos intermedios aparecen en el bloque, con nombre y ordenados, sin un solo valor elegido a mano.