El hermano de data-on, para un problema distinto: uno re-entinta un subárbol
porque cambió su lienzo, este porque el contenido son marcas de otros y se pelean
entre sí.
Un muro de logos de clientes es el caso que todas las referencias shippean y
ninguna resuelve a nivel de sistema: veinte marcas en veinte paletas gritan sobre
la página, así que los catálogos retocan cada asset a mano — y por eso venden el
modo oscuro como un segundo artefacto, porque un asset retocado no puede seguir a
un tema.
Va a la fundación y no a un componente, y eso se midió antes de elegir. Image no
tiene eje de tinta, ni prop ni regla, y tampoco era su casa: es un componente con
máquina de estados de carga para fotos, mientras que un logo suele ser un svg en
línea. Y el mecanismo es doble — un vectorial toma la tinta por currentColor y un
raster por filtro —, así que un solo eje tiene que cubrir los dos. Un primitivo
Logo nuevo se descartó por lo mismo: no habría cargado más que el contexto.
Sin tokens nuevos: el reposo y el realce son los que el tier semántico de la
escala de opacidad ya tenía. Y el opt-out por marca vale anidado, porque hay
marcas registradas que no se pueden alterar y el bloque no puede saber cuáles.
Dos medias querys que importan: la transición se anula con la preferencia de
movimiento reducido, y bajo colores forzados se retira el desaturado entero,
porque ahí la paleta es del sistema y desaturar pelearía contra el contraste que
ese modo existe para garantizar.
Verificado sobre ocho marcas de anchos y colores dispares: en mono, gris al
sesenta y cinco por ciento con la tinta del tema, y otra distinta en oscuro; en
brand, el color propio de cada una; al pasar el puntero, color entero.
Queda anotada en el generador la trampa que me costó una vuelta: renderBlock une
declaraciones con un salto de línea y no añade punto y coma, así que cada entrada
trae el suyo salvo la última. Escritas sin ellos, las reglas llegan a la hoja de
estilo y no pintan nada.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
dev
ad26922d29