El blog, por dentro

###Un reloj que no sirve para nada

En una esquina de la portada hay un pequeño reloj de misión. Muestra T+…s, los segundos transcurridos desde el 1 de enero de 1999, más o menos cuando empecé a programar. No recuerdo la fecha exacta, así que Año Nuevo tendrá que valer.

No tiene ninguna utilidad práctica. Es completamente innecesario, y precisamente por eso funciona. Antes de leer una sola línea ya te ha contado en qué clase de sitio estás.

###Todos iguales, todos planos

Los tonos no disponen del mismo margen de croma. La cantidad de saturación que podemos pedir antes de salir de la gama reproducible depende tanto del tono como de la luminosidad. Si obligamos a todos a compartir el mismo valor, la paleta completa queda limitada por el color con menos margen.

El violeta aparece en esta comparación porque era el acento principal del diseño anterior. Tiene bastante margen y por eso mi regla de mantener el mismo croma nunca dio demasiados problemas. Al sustituirlo por cian y ámbar terminé entrando en una zona mucho más estrecha.

La gráfica comprueba cuál es el croma máximo que puede tener cada tono antes de que el navegador tenga que recortarlo para representarlo en sRGB. Utilizo sRGB porque es la gama de color común que puedo dar por segura en una web. Con una luminosidad de 0.70, estos son los valores aproximados para los tonos que nos interesan:

No son límites universales: cambian al mover la luminosidad y también dependen de la gama de color con la que trabajemos. Lo importante es la diferencia entre ellos. Pedir el mismo croma no garantiza obtener colores igual de vivos.

Puedes comprobarlo en el siguiente ejemplo. Mantén la luminosidad en 0.70, salta al cian y sube el croma por encima de 0.12: el valor solicitado supera lo que sRGB puede representar y el indicador lo marca como recortado. En el violeta todavía queda margen. La gráfica inferior dibuja ese techo para todos los tonos y permite ver que no forma una línea recta.

La solución no consiste en llevar cada color hasta el límite, sino en ajustar su croma por separado. Los acentos pueden compartir una luminosidad que los relacione entre sí, mientras cada tono utiliza la intensidad que necesita y realmente puede reproducir.

En esta paleta el ámbar tiene algo más de croma que el cian. También aparece con mucha menos frecuencia, de modo que puede ser más intenso sin apoderarse de la interfaz. El cian guía. El ámbar interrumpe cuando hay un motivo.

###El problema del ámbar

En el tema claro aparece otro problema. El ámbar está muy cerca del amarillo, y el amarillo necesita bastante luminosidad para conservar su carácter. Si lo oscurecemos demasiado para ganar contraste sobre blanco, termina convertido en un oliva apagado.

Podría desplazar el tono hacia el naranja, pero entonces la misma señal usaría dos colores distintos según el tema. Preferí mantener el tono y cambiar el papel que cumple. En oscuro puede comportarse como una pequeña luz. Sobre papel lo utilizo con más contención, como una marca de tinta.

###El casco

El fondo oscuro es un azul petróleo casi negro. Tiene suficiente color para no parecer gris, pero no tanto como para competir con el campo de estrellas y las órbitas de la portada. Los paneles y bordes permanecen dentro de esa misma familia en lugar de introducir nuevos tonos. El texto utiliza un blanco roto para evitar el contraste agresivo del blanco puro.

###Dos temas, no tres paletas

El blog ya tenía un tema claro y otro oscuro. El problema era que mantenía tres versiones de la paleta: una para el modo claro, otra para el oscuro y una tercera para el modo por defecto cuando el sistema operativo prefería oscuro. default no era un tercer tema, pero en el CSS se comportaba como otra copia que había que mantener sincronizada.

Ahora cada color se define una sola vez con sus dos valores dentro de light-dark(). La propiedad color-scheme decide cuál utilizar. Si no eliges un tema, el navegador sigue la preferencia del sistema operativo. Si utilizas el selector del blog, color-scheme queda fijado en claro u oscuro.

/* Antes */
[data-theme="light"] { --color-text: oklch(44% 0.01 285deg); }
[data-theme="dark"] { --color-text: oklch(79% 0.01 85deg); }

@media (prefers-color-scheme: dark) {
  [data-theme="default"] { --color-text: oklch(79% 0.01 85deg); }
}

/* Ahora */
:root {
  color-scheme: light dark;
  --color-text: light-dark(oklch(44% 0.01 285deg), oklch(79% 0.01 85deg));
}

[data-theme="light"] { color-scheme: light; }
[data-theme="dark"] { color-scheme: dark; }

Para modificar un color edito una línea y veo sus dos versiones juntas. El modo por defecto continúa funcionando, pero ya no contiene una paleta propia. Solo quedan duplicadas unas pocas variables que no son colores, porque light-dark() no puede utilizarlas. La mayor parte del tercer bloque ha desaparecido.

###Una escala de intensidad

El texto y los elementos de la interfaz utilizan la misma escala conceptual: prominent, strong, regular, quiet y subtle. Hay una versión para texto y otra para líneas y superficies, pero ambas responden a la misma pregunta: ¿cuánto peso visual necesita esta pieza?

Los pasos no son cinco colores escogidos a mano. Parten de un ancla y se obtienen cambiando su luminosidad. En el tema claro, aumentar la intensidad implica oscurecer. En el oscuro ocurre lo contrario. La escala conserva el significado aunque la operación se invierta.

Antes había nombres como hover o selected. Parecían descriptivos hasta que el mismo valor resultaba útil en un elemento que no estaba seleccionado ni bajo el puntero. Nombrar por intensidad evita esa mentira: un color no sabe para qué componente se utiliza, solo cuánto debe destacar.

Los colores semánticos (success, warning, error, info y note) quedan fuera de esta escala. No representan niveles de intensidad, sino significados distintos con el mismo rango jerárquico.

###Un token es una decisión

El blog ya tenía tokens, escalas y una base de color en OKLCH. El problema era que no todo utilizaba ese sistema. Algunos componentes habían resuelto sus necesidades por separado y se quedaron fuera.

Los controles de formulario eran el ejemplo más claro. Cada uno había terminado con su propio espaciado, borde, estado de hover y anillo de foco. Ninguno era desastroso por sí solo, pero construir el siguiente control obligaba a elegir entre varios valores casi iguales sin saber cuál representaba la decisión correcta.

Ahora todos comparten la misma geometría y los mismos estados. Esto no solo hace que se parezcan: permite cambiar una decisión desde el lugar donde esa decisión vive.

Esa es la diferencia importante. Un token no es un valor compartido, sino una decisión compartida. Dos elementos pueden tener hoy el mismo radio o el mismo espacio por casualidad. Solo deberían utilizar el mismo token si, al cambiar uno mañana, también querríamos cambiar el otro.

Una paleta reúne valores. Un sistema reúne relaciones y decisiones. El rediseño no solo cambió el aspecto del blog. También redujo el número de lugares que tengo que tocar para modificarlo y, en la mayoría de los casos, ese número ahora es uno.