. ---------------------------------------------------------------------------- */ .rcx-surface { position: relative; isolation: isolate; overflow: hidden; } .rcx-surface::before { content: ""; position: absolute; inset: 0; z-index: -1; pointer-events: none; background-size: cover; background-position: center; } .rcx-surface--light::before { background-image: image-set( url("/images/backdrops/surface-light.avif") type("image/avif"), url("/images/backdrops/surface-light.webp") type("image/webp") ); opacity: 0.7; } .rcx-surface--dark { background-color: var(--color-neutral-950); color: var(--color-neutral-0); } .rcx-surface--dark::before { background-image: image-set( url("/images/backdrops/surface-dark.avif") type("image/avif"), url("/images/backdrops/surface-dark.webp") type("image/webp") ); opacity: 1; } /* ---------------------------------------------------------------------------- BANDA OSCURA CON LA DIAGONAL — flow-diagonal-dark Canvas 2026-08-15, entrega de T1 (spec 2026-08-14-familias-visuales §6/T1). POR QUÉ ES UNA BANDA Y NO UN FONDO DE PÁGINA. El spec de T1 daba 18 páginas como "oscuras" y pedía una variante oscura de página. Al medirlas en el navegador resultó falso: esas páginas son CLARAS con dos bandas oscuras. La secuencia real de superficies, leída en orden de documento, es `C W W W W W W C W` — hero carbón, cuerpo blanco, cierre carbón. El "9 secciones sobre un único color" de la auditoría era un artefacto: las

son transparentes y heredaban el color del , que en el momento de la captura estaba en carbón. Conclusión: las 26 páginas llevan el fondo CLARO de página (body.rcx-backdrop, arriba) y la variante oscura vive donde efectivamente hay oscuridad: las bandas. Así el ritmo de superficies se conserva en vez de aplanarse. CÓMO SE MONTA

…

… La clase NO pone color de fondo a propósito: la banda ya trae el suyo (carbón por .rcx-bg-dark o por su regla inline, y neutral-950 en .cw-problem por .rcx-bg-darkest). Si le pusiéramos color acá, pisaríamos ese 950 y perderíamos la única banda más profunda que tiene el sitio. Requisito: el elemento debe traer un fondo oscuro OPACO propio. CONTINUIDAD DE LA CORRIENTE La capa clara de página es `fixed`, así que una sola diagonal atraviesa toda la página. En las bandas no se puede repetir ese truco: un pseudo `fixed` no lo recorta el `overflow:hidden` del ancestro, y las propiedades que sí lo recortarían (clip-path, transform, filter) convierten al ancestro en bloque contenedor y anulan el fixed. `background-attachment: fixed` tampoco: iOS lo degrada a `scroll` y cuesta repintados. La continuidad se resuelve entonces por ANCLAJE: la banda de entrada muestra la esquina por donde la luz entra (arriba a la derecha) y la de cierre la esquina por donde sale (abajo a la izquierda). Es la misma dirección que la capa clara — arriba-derecha → abajo-izquierda — así que las tres capas leen como una sola corriente que cruza la página. Y es determinista en cualquier viewport, que es lo que `cover` no garantiza sobre el eje que no recorta. LEGIBILIDAD, MEDIDA Compuesta al 80% sobre carbón #1a1f24, el píxel más claro de toda la imagen deja el texto blanco en 4.55:1 — AA para texto normal en el peor punto del frame, no en promedio. El percentil 99 queda en 9.42:1. Bajo la caja del H1 de /looker-consulting se midió 16.14:1 a 1440 y 12.36:1 a 390. Por eso el contraste se gana con opacidad baja y una imagen que ya nace oscura, no con un scrim horneado encima. PRESUPUESTO DE BYTES — NO SUBIR EL PESO DE ESTOS DOS ARCHIVOS Canvas 2026-08-15, corrección tras medir LCP con el backdrop puesto. Este ::after convierte a la

en candidata de LCP por imagen: en las 18 páginas con banda visible sobre el pliegue, el LCP dejaba de ser el

y pasaba a ser la
atribuida a esta textura. Chromium descarta a un candidato cuando su ENTROPÍA queda por debajo de 0.05 bits por píxel (kMinimumEntropyForLCP, ImageRecord::EntropyForLCP), y el divisor NO es el píxel natural de la imagen sino el ÁREA PINTADA en píxeles CSS, recortada al viewport. O sea: el archivo tiene que pesar menos de area * 0.05 / 8 bytes. DOS TRAMPAS EN EL DENOMINADOR, las dos medidas y las dos contraintuitivas. 1) El área NO es el rect del elemento. Hay que leer `size` de la entrada de LCP, no calcularlo: a 320x568 el rect da 157.120 y la entrada, 129.938. 2) Chrome PENALIZA a la imagen que se agranda: multiplica el área por min(1, píxeles naturales / píxeles dibujados). O sea que achicar el archivo baja los bytes PERO también baja el área, y la entropía puede empeorar. Comprobado: bajando el móvil de 768px a 640px de ancho el archivo pasó de 889 B a 703 B y aun así falló en 12 páginas más. La salida es al revés de lo que uno haría: subir la resolución y bajar la calidad. Con `cover` y este encuadre, el móvil ve ~29% de la imagen dibujada, así que el techo real es ≈0.0145 bits por píxel NATURAL. Peores áreas medidas, leídas de la entrada de LCP (Playwright, 26 páginas): 320x568 → 84.381 px → 527 B* 768x1024 → 481.920 px → 3.012 B 390x844 → 299.130 px → 1.870 B 1440x900 → 1.094.895 px → 6.843 B (* con un asset de 640px; con 1.152px el área sube y el tope queda ~1.000 B) Por eso hay DOS archivos y no uno: un solo asset tendría que entrar en el tope del teléfono chico, y a 1920px de ancho eso emborrona la estría de luz, que es la firma de la imagen. Partiendo en 767px, cada uno entra holgado en lo suyo: ≥768px flow-diagonal-dark.avif 1920x1097, 2.282 B (tope 3.012 B) ≤767px flow-diagonal-dark-sm.avif 1152x658, 825 B (tope ~1.000 B) El -sm es el mismo frame completo, no un recorte, así que la geometría del `cover` no cambia y el encuadre móvil no se mueve un píxel. Y sólo se lo ve en ese encuadre (18% 50%), que cae en la zona plana y no muestra la estría: ahí el reescalado no se nota. En desktop sí, y por eso la banda ancha se queda con el archivo grande. Al ser una degradación diagonal difusa, la receta de codificación pesa más que la resolución: 10 bits saca el banding de los oscuros y encima baja el tamaño. Comandos exactos con los que se generaron (avifenc 1.x): avifenc -q 35 -s 0 -d 10 -y 444 src-1920.png flow-diagonal-dark.avif avifenc -q 20 -s 0 -d 10 -y 420 src-1152.png flow-diagonal-dark-sm.avif El AVIF anterior pesaba 8.841 B con la misma imagen; el nuevo pesa 2.282 B y compuesto sobre carbón da 48.6 dB de PSNR contra él — imperceptible. El .webp es sólo para el iOS viejo sin AVIF: no interviene en el LCP de campo (CrUX es Chrome) y por eso puede pesar más. LO QUE ESTE PRESUPUESTO NO PUEDE ARREGLAR La ventana de fallo es [tamaño del candidato de texto, 160 x bytes]: por debajo del primer número la banda no le gana al titular, por encima del segundo la entropía la descarta. Entre medio, gana la imagen. Como el segundo término es proporcional a los bytes, NINGÚN peso cierra la ventana cuando de la banda sólo asoma una astilla. Pasa en las 8 páginas de case-studies, que llevan banda de cierre y no de hero: con viewports de 1025-1275 px de alto (monitores 16:10) asoma el borde superior de .cs-close y el LCP se le va. Medido: falla en 1920x1025 a 1920x1175, y vuelve al
en 1920x1200 porque ahí la astilla ya pasa los 365.120 px que pide el umbral. Bajarle calidad al asset sólo angosta la ventana (a 1.250 B iría de 1025 a 1075), no la cierra, y se paga en la banda del hero, que es la superficie que sí se ve. Se deja documentado en vez de deformar la imagen principal por un borde de dos plantillas. ---------------------------------------------------------------------------- / .rcx-surface--flow-dark { position: relative; isolation: isolate; / encierra el z-index:-1 del ::after dentro de la banda / overflow: hidden; } / ::after y no ::before: varias bandas (.da-hero, .da-close, .ai-close, .prod-close, .cw-hero…) ya usan ::before para el gradiente firmado. / .rcx-surface--flow-dark::after { content: ""; position: absolute; inset: 0; z-index: -1; pointer-events: none; background-image: image-set( url("/images/backdrops/flow-diagonal-dark.avif") type("image/avif"), url("/images/backdrops/flow-diagonal-dark.webp") type("image/webp") ); background-image: -webkit-image-set( url("/images/backdrops/flow-diagonal-dark.avif") type("image/avif"), url("/images/backdrops/flow-diagonal-dark.webp") type("image/webp") ); background-size: cover; background-position: 50% 50%; background-repeat: no-repeat; opacity: 0.8; } .rcx-flow--in::after { background-position: 100% 0%; } / entra: arriba-derecha / .rcx-flow--out::after { background-position: 0% 100%; } / sale: abajo-izquierda / / Mobile: el hero ya no tiene mitad derecha vacía, el copy ocupa todo el ancho. Se ancla el recorte en la zona calma de la imagen y se baja la opacidad, para que la banda aporte material sin competir con el titular. Medido a 390: el texto blanco queda en 17.55:1 contra 12.36:1 con el encuadre de desktop. Acá también cambia el ARCHIVO, no sólo el encuadre (ver "presupuesto de bytes" arriba). El -sm es el mismo frame completo reducido a 768x439, así que la geometría del `cover` y el `background-position` son idénticos y el encuadre no se mueve un píxel: lo único que cambia es cuánta resolución se baja. Con este recorte el teléfono ve una franja de ~560px de ancho del original; bajar 1920 para mostrar 560 era, además del problema de LCP, tirar el 71% de los píxeles descargados. / @media (max-width: 767px) { .rcx-surface--flow-dark::after, .rcx-flow--in::after, .rcx-flow--out::after { background-image: image-set( url("/images/backdrops/flow-diagonal-dark-sm.avif") type("image/avif"), url("/images/backdrops/flow-diagonal-dark-sm.webp") type("image/webp") ); background-image: -webkit-image-set( url("/images/backdrops/flow-diagonal-dark-sm.avif") type("image/avif"), url("/images/backdrops/flow-diagonal-dark-sm.webp") type("image/webp") ); background-position: 18% 50%; opacity: 0.7; } } / ---------------------------------------------------------------------------- BANDA CLARA CON LA DIAGONAL — flow-diagonal Canvas 2026-08-15, home ES ("agregá fondos abstractos donde corresponda para que no quede tan liso y frío"). POR QUÉ HACÍA FALTA UNA VARIANTE CLARA DE BANDA, HABIENDO YA UNA DE PÁGINA. La home no lleva `body.rcx-backdrop`: tiene su propio sistema (body .rcx-home-v2 + home-premium-sections.css, hoja que comparte con /es/contacto). Meterle la capa fija de página habría cambiado las diez secciones de una vez, incluido el hero con video, que está aprobado y no se toca. Esta variante es la misma corriente montada por sección, opt-in: sólo aparece donde se la pide. INTENSIDAD, DERIVADA DE LA CAPA DE PÁGINA Y NO INVENTADA. En el montaje de página la imagen va al 34% y encima lleva el velo de papel, que es blanco a ~0.76 de alpha. La contribución neta de la imagen queda entonces en 0.34 * (1 - 0.76) ≈ 0.082. Por eso acá el pseudo va al 9%: sin velo, un 9% reproduce el mismo material que ya aprobó el owner en las otras 25 páginas, y la home deja de ser la única superficie sin corriente. No se sube más porque la imagen clara NO es plana: va de 0 a 242 de luma (tiene bandas oscuras además de la estría). Al 9% sobre blanco el píxel más oscuro cae a 232, que es lo que mantiene el cuerpo por encima de 4.5:1 en el peor punto del frame. Al 20% caería a 204 y el texto secundario se rompe. LA RETÍCULA VA ACÁ TAMBIÉN, y en la misma capa que la imagen en vez de en un segundo pseudo: las secciones destino son
limpias, pero gastar sus dos pseudos en el fondo dejaría sin ninguno a cualquier detalle futuro. Las capas de `background` se pintan de la primera a la última, así que la retícula (declarada antes) queda por encima de la imagen, igual que en la capa de página. CONTINUIDAD — es la misma corriente, no tres parches. Se usan los mismos anclajes que la banda oscura, en orden de scroll: #recorrido --in 100% 0% la luz entra por arriba a la derecha #equipo --mid 50% 50% cruza por el medio de la página #cierre --out 0% 100% sale por abajo a la izquierda (y en oscuro) Leído de arriba a abajo da una sola diagonal arriba-derecha → abajo-izquierda, que es la dirección de la capa clara de página. Tres apariciones en 9.889 px de home: una cada ~3.300 px, no una por sección. LCP — MEDIDO, NO ASUMIDO. flow-diagonal.avif pesa 11.822 B: a 1440x900 eso da 0,086 bits por píxel, por encima del umbral de entropía (0,05), así que Chromium NO lo descartaría como candidato. No es un problema acá porque ninguna de las tres bandas asoma en el viewport inicial — la primera arranca en y=2.075 y el pliegue más alto que probamos es 1.200 px — y el LCP sólo mira lo que se pinta dentro del viewport. Verificado con PerformanceObserver en 390x844, 1440x900, 1440x1200 y 1920x1200: el LCP sigue siendo el
del hero en los cuatro. SI ALGUNA VEZ UNA DE ESTAS BANDAS SUBE POR ENCIMA DEL PLIEGUE, hay que volver a medir y probablemente bajarle bytes al asset (ver el presupuesto de la banda oscura, arriba: el divisor es el área PINTADA, no el píxel natural). ---------------------------------------------------------------------------- / .rcx-surface--flow-light { position: relative; isolation: isolate; / encierra el z-index:-1 del ::after dentro de la banda / overflow: hidden; } .rcx-surface--flow-light::after { content: ""; position: absolute; inset: 0; z-index: -1; pointer-events: none; background-image: linear-gradient(to right, rgba(1, 7, 12, 0.028) 1px, transparent 1px), linear-gradient(to bottom, rgba(1, 7, 12, 0.028) 1px, transparent 1px), image-set( url("/images/backdrops/flow-diagonal.avif") type("image/avif"), url("/images/backdrops/flow-diagonal.webp") type("image/webp") ); background-image: linear-gradient(to right, rgba(1, 7, 12, 0.028) 1px, transparent 1px), linear-gradient(to bottom, rgba(1, 7, 12, 0.028) 1px, transparent 1px), -webkit-image-set( url("/images/backdrops/flow-diagonal.avif") type("image/avif"), url("/images/backdrops/flow-diagonal.webp") type("image/webp") ); background-size: 64px 64px, 64px 64px, cover; background-position: 0 0, 0 0, 50% 50%; background-repeat: repeat, repeat, no-repeat; opacity: 0.09; } / La retícula no se mueve con el anclaje: es el sistema de la página, no parte de la imagen. Sólo se reposiciona la tercera capa. / .rcx-surface--flow-light.rcx-flow--in::after { background-position: 0 0, 0 0, 100% 0%; } .rcx-surface--flow-light.rcx-flow--mid::after { background-position: 0 0, 0 0, 50% 50%; } .rcx-surface--flow-light.rcx-flow--out::after { background-position: 0 0, 0 0, 0% 100%; } / ---------------------------------------------------------------------------- FONDO OSCURO DE PÁGINA — misma imagen, montada como capa fija Hoy NO la usa ninguna página: las 26 de T1 son claras con bandas oscuras (ver nota de arriba). Queda acá, y no en un snippet suelto, porque es la hermana exacta del montaje claro de las líneas 25-68 y porque T3 la va a necesitar cuando /work y /services salgan de Webflow. Cuesta cero bytes: reusa flow-diagonal-dark. Uso: . No combinar con .rcx-backdrop. ---------------------------------------------------------------------------- / html:has(body.rcx-backdrop--dark) { background-color: var(--color-neutral-950); } body.rcx-backdrop--dark { background-color: transparent !important; } .rcx-backdrop--dark::before { content: ""; position: fixed; inset: 0; z-index: -2; pointer-events: none; background-color: var(--color-neutral-950); background-image: image-set( url("/images/backdrops/flow-diagonal-dark.avif") type("image/avif"), url("/images/backdrops/flow-diagonal-dark.webp") type("image/webp") ); background-image: -webkit-image-set( url("/images/backdrops/flow-diagonal-dark.avif") type("image/avif"), url("/images/backdrops/flow-diagonal-dark.webp") type("image/webp") ); background-size: cover; background-position: center; opacity: 0.85; } / Esta variante NO cambia al -sm en móvil, a propósito. Dos motivos: no lo necesita —los fondos colgados del no compiten por LCP en Chromium; se comprobó con la capa clara, que con 0.073 bits/px estaría por encima del umbral y aun así nunca resultó LCP en ninguna de las 26 páginas— y encima le haría mal: acá el encuadre es `center`, que sí muestra la estría, y el -sm está afinado para el recorte plano del 18%. Compuesto en `center` el cuantizador deja un rizado visible sobre el filo de la estría (43.2 dB contra los 48.3 dB del recorte para el que fue hecho). Los 2.282 B del archivo grande no son un problema de peso en un teléfono. / / Retícula de 64px, la misma medida que la capa clara, para que las dos variantes compartan sistema. Sin velo de papel: la imagen ya nace oscura y un velo encima sólo la ensuciaría. / .rcx-backdrop--dark::after { content: ""; position: fixed; inset: 0; z-index: -1; pointer-events: none; background: linear-gradient(to right, rgba(255,255,255,0.022) 1px, transparent 1px), linear-gradient(to bottom, rgba(255,255,255,0.022) 1px, transparent 1px); background-size: 64px 64px, 64px 64px; } @media (prefers-reduced-transparency: reduce) { .rcx-backdrop::before { background-image: none; opacity: 1; } .rcx-backdrop::after { display: none; } .rcx-surface--light::before { background-image: none; } / La banda vuelve al carbón sólido que ya trae el elemento. / .rcx-surface--flow-dark::after { display: none; } / Y la clara, al blanco de la sección. / .rcx-surface--flow-light::after { display: none; } .rcx-backdrop--dark::before { background-image: none; opacity: 1; } .rcx-backdrop--dark::after { display: none; } } / Alto contraste forzado: fuera toda textura, gane el color plano. Pixel 2026-08-15: acá faltaba la capa clara de página, que se quedaba puesta mientras la banda sí se apagaba. Corregido — el bloque ahora cubre las tres superficies, igual que el de prefers-reduced-transparency. */ @media (prefers-contrast: more) { .rcx-backdrop::before { background-image: none; opacity: 1; } .rcx-backdrop::after { display: none; } .rcx-surface--light::before { background-image: none; } .rcx-surface--flow-dark::after { display: none; } .rcx-surface--flow-light::after { display: none; } .rcx-backdrop--dark::before { background-image: none; opacity: 1; } .rcx-backdrop--dark::after { display: none; } }