, y delegaba el revert a requestAnimationFrame → setTimeout(50ms). Medido con Playwright antes de tocarlo: · carga normal ............ 324ms con el contenido invisible, en cada visita · prefers-reduced-motion .. IGNORADO, el slide ocurría igual · sin JavaScript .......... se veía bien (el script no corre, no aplica opacity:0) · rAF que no dispara ...... opacity:0 PERMANENTE = página en blanco El último caso es el grave y no es teórico: rAF no dispara en pestañas ocultas ni en renderers que no producen frames, así que abrir /blog/ en una pestaña de segundo plano (o rastrearla con un renderer sin frames) daba una página vacía. Y es una página indexada. Ahora es una @keyframes: el estado final es el NATURAL del elemento, así que nada puede dejarlo en opacity:0 — si el CSS no carga, si la animación no corre o si el JS falla, el contenido se ve. Es fail-safe por construcción. Se apunta a `body.blog #brx-content` (markup del theme, no un elemento de Bricks al que se le pueda asignar clase), en la misma línea que el fix del padding de arriba: el arreglo viaja en git y no suma una fila a la tabla de la sección 10 de CLAUDE.md. El mismo snippet está copiado en 11 páginas más y 4 plantillas de CPT: esas NO se migran a @keyframes (su content no está versionado), las cubre la red de seguridad de más abajo. Gotcha 8.11 de CLAUDE.md. */ @keyframes cc-entrada-lateral { from { opacity: 0; transform: translateX(-50px); } to { opacity: 1; transform: none; } } /* SIN animation-fill-mode a propósito: `backwards`/`both` dejarían el elemento en el estado `from` (opacity:0) si la animación no llegara a correr. Sin fill-mode, fuera de la ejecución manda el estilo natural = visible. Y sin delay, así que no hay parpadeo al inicio. */ body.blog #brx-content { animation: cc-entrada-lateral var(--cc-dur-base) var(--cc-ease-out); } @media (prefers-reduced-motion: reduce) { body.blog #brx-content { animation: none; } } /* ⚠️ RED DE SEGURIDAD (2026-07-27) — neutraliza la misma animación por JS en las 15 piezas del diseño VIEJO que todavía la traen (gotcha 8.11): 11 páginas publicadas (`/servicios/` y sus 4 hijas, `/portafolio/` y sus 4 sub-páginas, `/equipo/`) y 4 plantillas de CPT. Por qué acá y no en la BD: el content de esas páginas NO está versionado, así que un arreglo página por página se perdería con el próximo dump de prod. Esta regla viaja en git y se aplica sola al desplegar. Cómo funciona: `!important` de una hoja de autor le gana al style INLINE que pone el JS, así que el contenido nunca queda en `opacity:0`. Cuando el JS revierte (inline `opacity:1`), el selector deja de matchear y la regla se retira sin dejar rastro. Verificado el 2026-07-27 con `rAF` anulado: las 11 páginas quedaban EN BLANCO y con esta regla quedan visibles. Selector doble a propósito: `[style*="opacity: 0"]` a secas también matchea `opacity: 0.5` (comprobado), así que se exige además la firma `translateX(-50px)`, que es la de este snippet concreto y no puede dar falso positivo. EFECTO SECUNDARIO ACEPTADO: esas páginas pierden el slide de entrada. El estado final es idéntico; solo desaparece la animación, que el diseño nuevo no usa en ninguna parte. Decisión del equipo, 2026-07-27. Se puede borrar esta regla cuando las 15 piezas estén rediseñadas. */ main#brx-content[style*="opacity: 0"][style*="translateX(-50px)"] { opacity: 1 !important; transform: none !important; } /* ========================================================================== MOVIMIENTO DE LA HOME (2026-07-27) Por qué: la home tenía 11 secciones sin un solo scroll-reveal. Lo único que se movía era el crossfade del hero y el hover de las cards, y por eso se leía "sosa" aunque la composición estuviera bien. Fail-safe por diseño: SOLO se oculta bajo `html.cc-js`, clase que pone un script inline de (functions.php → ccd_motion_head_guard) que antes verifica IntersectionObserver y prefers-reduced-motion. Sin JS no se oculta nada. Y `html.cc-motion-off` (timeout de 2.5s del mismo guard) revela todo si cc-motion.js no llegó a cargar. Ver gotcha 8.11. ========================================================================== */ /* --- Reveal individual ---------------------------------------------------- PATRÓN CLAVE: se oculta con `:not(.cc-in)` y el estado revelado NO declara nada. Es deliberado. Si la regla revelada dijera `opacity:1`, estaría AFIRMANDO un estado final, y entonces le ganaría por especificidad a la opacidad de diseño que un elemento pudiera tener (pasó con la trust bar, que vive al 0.72 y quedaba forzada a 1). Al solo RETIRAR el ocultamiento, cada elemento vuelve a su valor natural, sea 1 o el que tenga. Es la misma idea que hace fail-safe a la animación del blog: no fijar un estado final, dejar que manden los valores naturales. */ html.cc-js .cc-reveal { transition: opacity var(--cc-dur-reveal) var(--cc-ease-out), transform var(--cc-dur-reveal) var(--cc-ease-out); } html.cc-js .cc-reveal:not(.cc-in) { opacity: 0; transform: translateY(14px); } /* --- Reveal en cascada: la clase va en el CONTENEDOR, no en cada hijo ------ Se observa el contenedor y sus hijos entran escalonados por nth-child. Así el JSON del template suma UNA clase por sección en vez de una por elemento, y el orden lo da el DOM sin tener que numerar a mano. */ /* ⚠️ EL ESCALONADO SE HACE CON `animation`, NO CON `transition`. Medido el 2026-07-30: la versión anterior ponía los `transition-delay` en el estado OCULTO, y eso NO ESCALONA NADA. Una transición usa las propiedades del estado DESTINO, y al revelar el destino tiene delay 0: :not(.cc-in) → 0s 0.08s 0.16s 0.24s (el estado del que se sale) .cc-in → 0s 0s 0s 0s (el que la transición usa) Los cuatro hijos arrancaban juntos. La ventana medida entre el primero y el último de un grupo era de 0 ms, en TODOS los grupos, desde que se construyó el sistema. El comentario que lo justificaba tenía razón en el problema —un `transition-delay` en el estado revelado se queda pegado y después se nota como lag en el hover— y su solución silenciaba el efecto entero. `animation` resuelve las dos cosas a la vez: · `animation-delay` sí se aplica cuando la animación corre, así que escalona; · terminada la animación no queda nada pegado, así que el hover no arrastra ningún retardo — que era el motivo original del cambio; · el keyframe declara solo `from`. Sin `to`, el elemento termina en SU valor natural, no en uno afirmado: es la regla de 8.12 y la que mantiene viva la trust bar a su `opacity: .72` en vez de forzarla a 1; · `backwards` mantiene el primer keyframe durante el retardo, así que no hay parpadeo entre que aparece `.cc-in` y arranca la animación. */ @keyframes cc-entrar { from { opacity: 0; transform: translateY(16px); } } /* Solo oculta; el estado revelado no declara nada (ver la nota de arriba). */ html.cc-js .cc-stagger:not(.cc-in) > * { opacity: 0; transform: translateY(16px); } html.cc-js .cc-stagger.cc-in > * { animation: cc-entrar var(--cc-dur-reveal) var(--cc-ease-out) backwards; } /* ⚠️ LA COLA SE ACORTÓ A LA MITAD el 2026-08-17: los pasos eran de 80ms y el tope 480, o sea el último hijo terminaba 1.040ms después del disparo (560 de reveal + 480). Con la rueda del ratón eso va SIEMPRE por detrás del lector. Ahora el paso es de 50ms y el tope 250, así que el último cierra a los 810ms. El escalonado se sigue leyendo —es lo que distingue una entrada de un encendido— pero deja de ser una espera. */ html.cc-js .cc-stagger.cc-in > *:nth-child(2) { animation-delay: 50ms; } html.cc-js .cc-stagger.cc-in > *:nth-child(3) { animation-delay: 100ms; } html.cc-js .cc-stagger.cc-in > *:nth-child(4) { animation-delay: 150ms; } html.cc-js .cc-stagger.cc-in > *:nth-child(5) { animation-delay: 200ms; } html.cc-js .cc-stagger.cc-in > *:nth-child(6) { animation-delay: 250ms; } html.cc-js .cc-stagger.cc-in > *:nth-child(n+7) { animation-delay: 250ms; } /* --- La barra de acento vertical que crece ------------------------------- */ /* Es `blo037`, la barrita verde de 5x56px sobre el H2 de S4. Su _cssCustom es una regla de ID que define width/height/background/border-radius pero NO transform, así que esta clase gana sin pelear especificidad (gotcha 8.1). */ @keyframes cc-trazar-y { from { transform: scaleY(0); } } @keyframes cc-trazar-x { from { transform: scaleX(0); } } html.cc-js .cc-bar-draw { transform-origin: top center; } html.cc-js .cc-bar-draw:not(.cc-in) { transform: scaleY(0); } /* Es el PRIMER hijo de su contenedor, así que sin retardo se trazaba ANTES que el titular al que acompaña — un acento no puede llegar antes que aquello que acentúa. Con 320ms entra después de la bajada y se lee como lo que es: el remate de la sección, no su apertura. Va como `animation-delay` y no como `transition-delay` por lo explicado arriba: en una transición el retardo del estado que se abandona no se aplica. */ html.cc-js .cc-bar-draw.cc-in { animation: cc-trazar-y var(--cc-dur-reveal) var(--cc-ease-spring) 620ms backwards; } /* --- Reglas que se TRAZAN junto al dato que encabezan --------------------- Las tres columnas de la banda violeta llevaban un `border-top` estático: la línea ya estaba ahí cuando el número empezaba a contar, o sea eran dos cosas separadas ocurriendo cerca. Ahora la línea se traza mientras el número sube y las dos leen como un solo gesto. Va en un pseudo-elemento y no en el borde porque un `border-width` no se puede escalar: `transform` sobre el elemento entero deformaría también el texto. El estado oculto lo dispara el ANCESTRO (`.cc-stagger:not(.cc-in)`), no una clase propia: así no hace falta sumar entradas al observer y el trazo queda sincronizado con la entrada de su columna por construcción. */ .cc-rule-draw { position: relative; } .cc-rule-draw::before { content: ""; position: absolute; inset: 0 auto auto 0; width: 100%; height: 3px; background: var(--cc-green-500); transform-origin: left center; } html.cc-js .cc-stagger:not(.cc-in) > .cc-rule-draw::before { transform: scaleX(0); } html.cc-js .cc-stagger.cc-in > .cc-rule-draw::before { animation: cc-trazar-x var(--cc-dur-reveal) var(--cc-ease-out) 120ms backwards; } html.cc-js .cc-stagger.cc-in > .cc-rule-draw:nth-child(2)::before { animation-delay: 240ms; } html.cc-js .cc-stagger.cc-in > .cc-rule-draw:nth-child(3)::before { animation-delay: 360ms; } /* ⚠️ AQUÍ VIVÍA `.cc-rule-draw--lado` (la regla vertical de la tercera columna de la banda de Números) y se retiró el 2026-08-14 al quedarse sin elemento: la banda se reestructuró el 2026-08-13 —fuera el 17x, titular y cifra en la misma fila— y esa columna dejó de existir. Comprobado antes de borrar: cero usos en `bricks-templates/` y cero en TODAS las páginas de la BD. Se anota en vez de borrarse en silencio porque el gesto (una regla que se traza en otro eje para marcar "esto es la conclusión, no un dato") puede volver a hacer falta. */ /* --- RED DE SEGURIDAD: si cc-motion.js no cargó, revelar todo ------------- La pone el guard de a los 2.5s. `!important` porque tiene que ganarle a las reglas de arriba sin importar el orden. */ html.cc-motion-off .cc-reveal:not(.cc-in), html.cc-motion-off .cc-stagger:not(.cc-in) > *, html.cc-motion-off .cc-bar-draw:not(.cc-in) { opacity: 1 !important; transform: none !important; } /* Los pseudo-elementos NO los cubre la regla de arriba: `transform:none` sobre el elemento no llega a su `::before`. Sin esta línea, un fallo de cc-motion.js dejaría las tres reglas de la banda violeta en scaleX(0) —invisibles— para siempre. Es exactamente el fallo que el resto de esta red existe para evitar. */ html.cc-motion-off .cc-stagger:not(.cc-in) > .cc-rule-draw::before { transform: none !important; } /* --- Sin movimiento si el usuario lo pidió ------------------------------- */ /* El guard ya no pone `cc-js` con reduced-motion, así que estas reglas son defensa en profundidad: cubren el caso de que la preferencia cambie DESPUÉS de cargar la página, sin recargar. */ @media (prefers-reduced-motion: reduce) { html.cc-js .cc-reveal:not(.cc-in), html.cc-js .cc-stagger:not(.cc-in) > *, html.cc-js .cc-bar-draw:not(.cc-in) { opacity: 1 !important; transform: none !important; transition: none !important; } html.cc-js .cc-stagger:not(.cc-in) > .cc-rule-draw::before { transform: none !important; transition: none !important; } /* Si la preferencia cambia DESPUÉS de cargar, `.cc-in` ya puede estar puesto y entonces lo que corre es una animación, no una transición: hay que apagarla explícitamente o el movimiento seguiría ocurriendo. */ html.cc-js .cc-stagger.cc-in > *, html.cc-js .cc-stagger.cc-in > .cc-rule-draw::before, html.cc-js .cc-bar-draw.cc-in { animation: none !important; } } /* ========================================================================== TRUST BAR (S2) — de 6 textos grises a logos reales (2026-07-27) Antes: 6 textos de 13px en gris al 60% de opacidad. Era la parte más "sosa" de la home: una banda de 83px sin peso visual que decía credenciales fuertes (Google Premier, VTEX, Shopify…) con la voz más débil posible. Los logos salen de los assets del home ANTERIOR, traídos de prod. Se referencian por ID de attachment y sin `url`/`full` en el JSON, a propósito: esas URLs quedan cacheadas con el dominio del entorno donde se exportó y no deben viajar en el repo. Los ids sí son estables porque vienen del dump de prod. ========================================================================== */ .cc-trust { --cc-trust-h: 40px; border-top: 1px solid rgba(255, 255, 255, 0.06); border-bottom: 1px solid rgba(255, 255, 255, 0.06); } .cc-trust__item { display: flex; align-items: center; justify-content: center; /* SIN !important, y eso importa: estos bloques traían `#brxe-blo008{opacity:.6}` en su _cssCustom, una regla de ID que solo se podía pisar con !important (gotcha 8.1) — pero entonces el !important también le ganaba al reveal, que nunca podía llevar el item a opacidad 1. En vez de pelear especificidad se eliminó el _cssCustom del template: una sola fuente de verdad, cero !important, y el reveal funciona igual que en el resto de la página. */ opacity: 0.72; transition: opacity var(--cc-dur-base) var(--cc-ease-out); } .cc-trust__item:hover { opacity: 1; } /* Los logos son FONDOS CSS de archivos del child theme, no elementos `image` de Bricks. La razón es de portabilidad, no de estilo: un elemento image referencia un ID de attachment, y esos ids NO sobreviven un dump fresco de prod (es el mismo problema del logo del header, §10). Un archivo en `assets/img/partners/` viaja en git y funciona en cualquier entorno el día que se despliegue, sin re-apuntar nada y sin sumar una fila a esa tabla. El label de texto sigue en el DOM con `.cc-vh`, así que la credencial es contenido indexable y el fondo es puramente decorativo — que es lo correcto. ⚠️ CAMBIO DE FONDO EL 2026-08-13: la fila dejó de ser de WORDMARKS y pasó a ser de BADGES DE PARTNER. Es el pedido de Mauricio en el acta del 2026-08-10 —que los logos declaren nivel y tipo de asociación— y Ricardo entregó los seis archivos oficiales de cada portal. Eso cambia dos reglas que antes eran correctas: 1. **Se fue el tope de 118px de ancho.** Existía para que el wordmark de "Google Ads" (180x29) no se viera el doble de grande que el de "PrestaShop" (182x43), o sea para normalizar piezas de proporciones muy dispares. Los badges ya vienen normalizados entre sí (2.2:1 a 4:1) y el tope, en cambio, RECORTABA a los tres más anchos. Ahora se normaliza por ALTURA, que es lo que iguala el peso óptico de piezas del mismo lenguaje gráfico. 2. **La fila subió de 26 a 40px.** Un wordmark de una línea se lee a 26px; un badge lleva texto DENTRO del arte ("Level 2 Expert", "Business Partner") y a 26px esa letra caía a ~4px, o sea ilegible. Es la misma altura a la que los puso el mockup aprobado por el equipo. Cada logo declara su `aspect-ratio` real, así que con la altura fija el ancho sale solo y `background-size: contain` nunca deforma. */ /* ⚠️ LA ALTURA COMÚN NO IGUALA EL TAMAÑO PERCIBIDO (2026-08-13). Ricardo lo vio a ojo —"que no se vea uno más grande que otro"— y al medirlo era grande: con los seis a 40px de alto, la TINTA que pone cada uno iba de 550 px² (Meta) a 1671 (PrestaShop), o sea **3,04x de diferencia**. Por eso PrestaShop se leía enorme y Meta diminuto midiendo lo mismo: un badge ancho de letra fina pesa mucho menos que uno compacto y negrita. La corrección es un multiplicador por logo que lleva a todos a la misma tinta —la media geométrica, 1082 px²— acotado a la banda 0.85–1.25 para que ninguno se salga de la fila. Resultado medido: de 3,04x a **1,41x**. Meta queda en el tope de la banda y aun así por debajo (859): es un lockup genuinamente ligero y subirlo más lo volvería el más alto de la fila, que es cambiar un desequilibrio por otro. ⚠️ Si se cambia un archivo de esta carpeta hay que RECALCULAR su multiplicador: el número depende del arte, no del nombre. */ .cc-trust__logo { height: var(--cc-trust-h); background-repeat: no-repeat; background-position: center; background-size: contain; } /* Los cinco badges de portal. Todos monocromo BLANCO salvo TikTok, que trae sus dos acentos de marca; ninguno necesita filtro sobre el fondo oscuro. Las credenciales están confirmadas por Ricardo el 2026-08-13 y hay un trinquete en `home.mjs` que impide añadir una sin confirmar. */ .cc-trust__logo--google-premier { /* El lockup horizontal "PREMIER Google Partner", monocromo blanco (elección de Ricardo el 2026-08-13: es el que usa el mockup que el equipo revisó en la reunión del 2026-08-10). ⚠️ Es el TERCER asset de Google que pasó por aquí en el día, así que conviene dejar escrito por qué este y no los otros dos: · `google-ads.svg` era el logo del PRODUCTO — no decía nada de la credencial, que es justo lo que pidió Mauricio. · el badge CUADRADO del kit oficial (`PremierPartner-RGB.svg`, 152x145.5) dice la credencial, pero es una tarjeta a color con fondo propio: en una fila de cinco marcas monocromas blancas y transparentes se leía como una estampilla pegada, y obligaba a dos excepciones —altura propia (1.4x) y quedar fuera del teñido del modo claro—. · este lockup dice lo mismo ("PREMIER Google Partner") en el mismo lenguaje gráfico que sus cinco vecinos: 2.7:1, blanco, sin fondo. Con él las dos excepciones desaparecen y la fila vuelve a tener UNA sola definición (8.40). O sea la decisión no es de gusto: el badge cuadrado era correcto como asset y equivocado como pieza de ESTA fila. */ aspect-ratio: 1241 / 460; background-image: url("../img/partners/google-premier-partner.png"); /* Peso óptico: ponía 1020 px² de tinta a la altura base y ahora pone 1083 (medido, ver el bloque de arriba). */ height: calc(var(--cc-trust-h) * 1.03); } .cc-trust__logo--meta { /* Variante APILADA (562x252). La anterior era el lockup de 16:1, que obligaba a un tope de ancho propio para no verse la mitad que sus vecinos — un problema que la doc pedía resolver "si el portal ofrece la variante compacta o apilada". La ofrecía. Con 2.2:1 la excepción sobra. */ aspect-ratio: 562 / 252; background-image: url("../img/partners/meta-business-partner-2026.png"); /* Peso óptico: ponía 550 px² de tinta a la altura base y ahora pone 859 (medido, ver el bloque de arriba). */ height: calc(var(--cc-trust-h) * 1.25); } .cc-trust__logo--prestashop { /* Expert Level 2. El anterior era el logo del PRODUCTO, sin nivel. */ aspect-ratio: 445 / 164; background-image: url("../img/partners/prestashop-expert-level2.png"); /* Peso óptico: ponía 1671 px² de tinta a la altura base y ahora pone 1207 (medido, ver el bloque de arriba). */ height: calc(var(--cc-trust-h) * 0.85); } .cc-trust__logo--shopify { aspect-ratio: 800 / 200; background-image: url("../img/partners/shopify-partner.png"); /* Peso óptico: ponía 809 px² de tinta a la altura base y ahora pone 1089 (medido, ver el bloque de arriba). */ height: calc(var(--cc-trust-h) * 1.16); } .cc-trust__logo--vtex { aspect-ratio: 308 / 94; background-image: url("../img/partners/vtex-partner.png"); /* Peso óptico: ponía 1377 px² de tinta a la altura base y ahora pone 1091 (medido, ver el bloque de arriba). */ height: calc(var(--cc-trust-h) * 0.89); } .cc-trust__logo--tiktok { /* ⚠️ TikTok SHOP Partner, y el nombre importa. El mockup llegó con el alt "TikTok Agency Gold Partner" y el archivo `tiktok-shop-partner_white.png`; el repo tenía un tercero, `tiktok-marketing-partner.png`. Son TRES programas distintos. El nombre que vale es el del archivo que entregó Ricardo desde el portal. ⚠️ Y queda dicho, porque no es menor: el barrido de las 29 páginas publicadas de canalcero.com (GET anónimo, 2026-08-13) NO encontró ninguna afirmación de asociación con TikTok — el sitio solo declara Google Premier, Yandex Gold y VTEX. Entra porque Ricardo entregó el asset oficial, no porque el sitio ya lo dijera. Es el único de los seis en esa situación. ⚠️ LLEVA `grayscale(1)` DESDE EL 2026-08-23, y el porqué está en la frase que había aquí antes: «esta variante ya viene en blanco **con los acentos de marca**». Los acentos eran el problema y no se habían pesado. Medido pixel a pixel sobre los seis badges: este tenía **16,9 % de tinta claramente cromática** (pico de saturación 0,84) y los otros cinco **0 %** (pico ≤0,15). En una fila cuyo trabajo es leerse como UN conjunto, uno de los seis se adelantaba — y es el único sin asociación confirmada en el sitio (ver arriba), o sea el que menos autoridad aporta. ⚠️ Y NO es la receta de la cinta de marcas, aunque lo obvio fuera copiarla. Medidos los cuatro candidatos contra la luminancia media de los otros cinco (150): | filtro | color | luminancia | delta | | (ninguno) | 16,9% | 149 | −1 | | grayscale(1) | 0% | 151 | +1 | ← elegido | saturate(0) brightness(1.1) | 0% | 152 | +2 | | brightness(0) invert(1) | 0% | 161 | +11 | ← la de la cinta `brightness(0) invert(1)` —lo que usa la cinta de marcas y lo que este archivo usaba con el PNG viejo— apaga el color pero deja el badge como el MÁS BRILLANTE de los seis: cambia una incoherencia por otra. `grayscale(1)` respeta la luminancia que el archivo ya tenía. El modo claro no se toca: su regla es más específica y ya lo pasa a `brightness(0)` con los otros cinco. */ aspect-ratio: 654 / 178; background-image: url("../img/partners/tiktok-shop-partner.png"); filter: grayscale(1); /* Peso óptico: ponía 1531 px² de tinta a la altura base y ahora pone 1106 (medido, ver el bloque de arriba). */ height: calc(var(--cc-trust-h) * 0.85); } /* El item sin logo (hoy solo TikTok, sin asociación confirmada — ver arriba) se iguala al peso óptico de los wordmarks: mayúsculas, tracking y el mismo alto de caja. */ .cc-trust__text { display: flex; align-items: center; height: var(--cc-trust-h); font-family: var(--cc-font-sans); font-size: 13px; font-weight: var(--cc-fw-bold); letter-spacing: 0.06em; text-transform: uppercase; color: var(--cc-fg-strong); white-space: nowrap; } /* Mobile. NO se usa grid acá, y quedó documentado porque costó descubrirlo: Bricks emite `#brxe-con007{display:flex;flex-flow:row wrap;…}` en su CSS por-página, o sea una regla de **ID**, que le gana a cualquier clase — incluso a un selector doble `.brxe-container.cc-trust` (0,2,0). Es el gotcha 8.1. Se podría forzar con !important, pero no hace falta: basta acotar el ancho del logo más largo para que el propio `wrap` del flex reparta 3 y 3 en vez de 3-2-1, que dejaba a TikTok solo en la última fila como si fuera un sobrante. El tope de Meta baja de 172 a 150px: su lockup de 16:1 es el que descuadra la fila. Lo ideal sería la variante compacta/apilada del badge de Meta. */ @media (max-width: 767px) { /* 30px y no 20: con badges la letra va DENTRO del arte, así que bajar la caja la vuelve ilegible antes que estrecha. El tope de ancho de Meta desapareció con el lockup de 16:1 al que corregía (ahora es la variante apilada, 2.2:1). */ .cc-trust { --cc-trust-h: 30px; } .cc-trust__text { font-size: 11px; } } /* Oculto visualmente pero legible por lectores de pantalla y buscadores. Se usa en los labels de la trust bar: el logo comunica la marca, y el texto ("Google Premier Partner") conserva la credencial como contenido indexable. NO se usa display:none, que lo sacaría del árbol de accesibilidad. */ .cc-vh { position: absolute !important; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip: rect(0, 0, 0, 0); white-space: nowrap; border: 0; } /* ========================================================================== BADGE "GOOGLE PREMIER PARTNER" ANIMADO (S10) — 2026-07-27 El home anterior mostraba acá un GIF (690 KB) y un PNG (454 KB) del badge oficial. Los dos se DESCARTARON a propósito: ambos traen fondo blanco/celeste horneado —irreconciliable con una página dark-first— y el PNG además dice "Partner Premier del 2024", un año viejo. Se reconstruye en CSS: nativo del tema oscuro, sin peso de red, sin año que caduque, y con la animación que el GIF aportaba. Los 4 colores de Google viven en el punto cónico, que es la única cita de marca que hace falta. ========================================================================== */ /* --- La credencial de capacidad ------------------------------------------- ⚠️ ACÁ VIVÍA `.cc-badge-premier`: una pill con un PUNTO QUE LATÍA y un barrido de brillo metálico recorriéndola cada 5,5s. Se retiró el 2026-08-06 porque Ricardo señaló la fila entera (*"las píldoras de Capacidad son muy de IA, esos detalles no me gustan"*) y tenía razón: punto pulsante + shimmer + contorno de color es, literalmente, el vocabulario de una landing generada. La credencial más fuerte del negocio se estaba presentando con el recurso que más la abarata. Ahora las tres son texto en una ficha de datos, con el mismo separador de hairline que la fila de TRAYECTORIA de arriba —que es la que SÍ funcionaba—. Eso resuelve además una incomodidad que el código anterior admitía en su propio comentario: "Stack medios + commerce + data" no es algo que certifique un tercero, y en formato de sello lo parecía. Sin cápsula, las tres son lo que son: hechos declarados. Y de paso desaparece el ÚNICO uso de `border-radius: 999px` en una caja de la home, que era el radio que hacía que estas tres se leyeran como tags. */ /* ========================================================================== FOOTER — redes sociales y links legales (2026-07-27) Los dos faltaban respecto del footer anterior. Los legales no son cosméticos: en un sitio con Complianz GDPR instalado, no enlazar privacidad y cookies desde el footer es lo más cercano a un problema de cumplimiento que había. Van como HTML dentro de elementos `text` de Bricks (que rinde HTML, igual que ya hacían los links del nav del footer) en vez de un elemento `code`: ese es el mecanismo que causó el bug de la página en blanco (gotcha 8.11). ========================================================================== */ /* ⚠️ El flex va en el

INTERNO, no en el wrapper. El elemento `text` de Bricks envuelve su contenido en un

, así que `.cc-social{display:flex}` tenía un solo hijo (ese

) y el `gap` no se aplicaba nunca: la separación que se veía era el espacio entre palabras del HTML. Es el gotcha 8.9 otra vez —verificar el markup renderizado antes de escribir el selector. */ .cc-social { margin-top: 18px; } .cc-social > p { display: flex; gap: 10px; margin: 0; } .cc-social__link { display: inline-flex; align-items: center; justify-content: center; width: 38px; height: 38px; border-radius: var(--cc-radius-md); background: var(--cc-bg-surface); border: 1px solid var(--cc-border-on-dark); color: var(--cc-green-500); transition: transform var(--cc-dur-base) var(--cc-ease-out), border-color var(--cc-dur-base) var(--cc-ease-out), background var(--cc-dur-base) var(--cc-ease-out); } .cc-social__link svg { width: 18px; height: 18px; fill: currentColor; /* el color lo manda el link, no el SVG */ } .cc-social__link:hover { transform: translateY(-2px); border-color: var(--cc-green-500); background: rgba(61, 237, 180, 0.08); } /* Foco visible por teclado: son los únicos links con icono y sin texto, así que sin esto un usuario de teclado no sabría dónde está. */ .cc-social__link:focus-visible { outline: 2px solid var(--cc-fg-accent); outline-offset: 2px; } @media (prefers-reduced-motion: reduce) { .cc-social__link:hover { transform: none; } } /* Fila de links legales, sobre una línea fina que la separa del copyright. Idem: el flex va en el

(gotcha 8.9), así que el link y el botón viven DENTRO de ese

y el

` que envuelve todo elemento `text` (8.9): sobre el contenedor no haría nada, porque tendría un solo hijo. */ .cc-tabs__lista > p { display: flex; flex-wrap: wrap; gap: 0; margin: 0; border-bottom: 1px solid var(--cc-border-on-dark); } .cc-tabs__tab { display: inline-flex; align-items: baseline; gap: 10px; padding: 14px 22px 16px; cursor: pointer; border-bottom: 2px solid transparent; margin-bottom: -1px; /* pisa el hairline de la fila */ transition: color var(--cc-dur-fast) var(--cc-ease-out), border-color var(--cc-dur-fast) var(--cc-ease-out), background-color var(--cc-dur-fast) var(--cc-ease-out); } /* Los dos van a 15px —el mismo tamaño del nav— y se distinguen por peso y color, NO por tamaño. Estrenar un 17px para el nombre sumaba un tamaño más al conjunto de la home y lo cazó el trinquete de `ux.mjs` (13 sobre un techo de 12). Es 8.18: si hace falta un valor nuevo, falta un token; y acá no faltaba ninguno, sobraba el invento. */ .cc-tabs__num { font-family: var(--cc-font-sans); font-weight: 800; font-size: 15px; color: var(--cc-fg-muted); transition: color var(--cc-dur-fast) var(--cc-ease-out); } .cc-tabs__nom { font-family: var(--cc-font-sans); font-weight: 700; font-size: 15px; letter-spacing: -0.01em; color: var(--cc-fg-muted); transition: color var(--cc-dur-fast) var(--cc-ease-out); } /* Reposo -> hover: un control que no responde al puntero no se lee como control (8.18, y `ux.mjs` lo mide). */ .cc-tabs__tab:hover .cc-tabs__num, .cc-tabs__tab:hover .cc-tabs__nom { color: var(--cc-fg-read); } /* La pestaña activa toma el color de SU unidad, que es el mismo mecanismo de islas de 8.34: el número, el punto del nombre y el subrayado salen todos de `--cc-unidad` sin que esta regla sepa en qué unidad está. */ .cc-tabs__radio:checked + .cc-tabs__tab { border-bottom-color: var(--cc-unidad, var(--cc-fg-accent)); } .cc-tabs__radio:checked + .cc-tabs__tab .cc-tabs__num { color: var(--cc-unidad, var(--cc-fg-accent)); } .cc-tabs__radio:checked + .cc-tabs__tab .cc-tabs__nom { color: var(--cc-fg-strong); } /* El anillo de foco va en el label, porque el input mide 1px y su outline no se vería. Mismo criterio que el área de golpeo del checkbox del carrusel (8.28). */ .cc-tabs__radio:focus-visible + .cc-tabs__tab { outline: 3px solid var(--cc-unidad, var(--cc-fg-accent)); outline-offset: -3px; border-radius: var(--cc-radius-sm); } /* Los paneles. `:has()` mira qué radio está marcado y el emparejamiento va por la clase de unidad que el panel YA tenía (`.cc-u-media`…), no por contar posiciones. Contar era un bug: `:nth-of-type()` cuenta por TIPO de elemento, y como la fila de pestañas también es un `div`, los paneles serían el 2.º al 5.º y ninguna regla habría coincidido nunca. Emparejar por unidad además documenta solo qué pestaña abre qué panel. El `>` es imprescindible: las etiquetas llevan las mismas clases `cc-u-*` y viven más abajo, dentro del `

`, NO sobre el elemento. Bricks envuelve el texto de un elemento `text` en su propio `

`, así que `display:flex` en la clase gobierna un contenedor cuyo único hijo es ese `

` — la cifra y su rótulo quedaban EN LÍNEA dentro de él. Es 8.9 literal, y se ve midiendo: `innerHTML` del nodo con la clase devolvía `

$148M

` pasa a llevar una clase con su `aspect-ratio` real y `background-image`, más `.cc-vh` en el texto para que el nombre siga siendo contenido indexable. **No se deja el CSS escrito de antemano**: sin el archivo serían reglas que no matchean nada, o sea CSS muerto. ========================================================================== */ .cc-marcas { position: relative; display: flex; align-items: center; /* 20px y no 14: con menos, el nombre que se está desvaneciendo en el borde derecho queda pegado al icono de pausa y los dos se leen como una sola cosa. */ gap: 20px; width: 100%; } /* La máscara recorta la cinta Y difumina los dos bordes. El difuminado no es adorno: sin él las marcas aparecen y desaparecen de golpe contra el borde, que es lo que hace que un marquee se vea barato. Va con `mask` y no con un degradado de color encima porque así funciona igual en los dos temas — no hay que saber de qué color es el fondo. */ .cc-marcas__mask { flex: 1; min-width: 0; /* un mínimo rígido en un flex es una promesa de overflow (8.7) */ overflow: hidden; -webkit-mask-image: linear-gradient(90deg, transparent 0, #000 6%, #000 94%, transparent 100%); mask-image: linear-gradient(90deg, transparent 0, #000 6%, #000 94%, transparent 100%); } /* ⚠️ EL HUECO ENTRE PISTAS VIVE EN LA PISTA, NO EN LA CINTA, y las dos razones son aritméticas (2026-08-04, auditoría visual). 1. **El bucle no cerraba.** Con `gap: G` en la cinta, su ancho es `N·T + (N−1)·G`, pero el ciclo tiene que avanzar exactamente `T + G`. `translateX(-100/N%)` avanza `T + G·(N−1)/N`, o sea se queda corto en `G/N`: con G=56 eso son **14px de salto en cada vuelta**, cada 28 segundos. Se ve como un tirón y no hay forma de arreglarlo desde el CSS sin saber cuánto mide T. Con el hueco DENTRO de la pista (su `padding-right`), el ancho exterior de cada pista es `P = T + G`, la cinta es `N·P` exacto y `-100/N%` es exactamente un P. Cierra por construcción, sin que importe cuánto midan los items ni el gap. 2. **Se veía la misma marca dos veces.** La desigualdad de 8.28 (`V ≤ (N−1)·T`) evita el VACÍO al final de la vuelta, pero no el duplicado: para eso hace falta `P ≥ V`, porque el patrón se repite cada P. Medido antes: V=1112 y P=788 a 1440, o sea 324px de contenido repetido en pantalla — y con 5 marcas eso significaba "Falabella … Cencosud … Falabella … Cencosud" a la vista, que se lee como un bug del sitio y no como un carrusel. El hueco sube a `clamp(40px, 11vw, 160px)`, que es el mínimo que cumple `P ≥ V` en los 5 anchos medidos (1920, 1440, 1024, 768 y 390) con margen. Con cinco marcas la cinta queda airosa, que es como se ve un marquee de logos de verdad. */ /* ⚠️ El hueco BAJÓ de `clamp(40px, 11vw, 160px)` el 2026-08-22, y no es un cambio de gusto: aquel valor era el mínimo que cumplía `P ≥ V` con **cinco nombres de texto**, donde la pista medía 788px a 1440 y hacía falta un hueco enorme para que el patrón no se repitiera en pantalla. Con **16 logos** la pista mide ~2.900px, o sea las dos desigualdades de arriba se cumplen con muchísimo margen y un hueco de 160px solo servía para dejar la cinta medio vacía. Los dos valores están comprobados por medición en `home.mjs`, que los recalcula en 5 anchos en vez de confiar en este comentario. */ /* La CELDA es lo que da el ritmo, no el hueco. Con hueco fijo entre logos de anchos dispares —44px Emasa, 175px Tienda Copec— la distancia ENTRE MARCAS sale distinta en cada pareja y la fila se lee desordenada aunque el hueco sea idéntico. Con una celda de ancho fijo y el logo centrado dentro, el ritmo horizontal es exacto y lo que varía es el aire interno, que el ojo no cuenta. Por eso `--cc-marcas-hueco` es 0: el aire vive DENTRO de la celda. */ .cc-marcas { --cc-marcas-hueco: 0px; --cc-marcas-celda: clamp(132px, 14vw, 208px); --cc-marcas-escala: 1; } .cc-marcas__cinta { display: flex; width: max-content; gap: 0; /* ⚠️ 90s, no los 28s de la cinta de texto. La duración es de la VUELTA COMPLETA, o sea la velocidad real sale de dividir la pista por ella: con 5 nombres la pista medía 788px y 28s daban 28px/s; con 16 logos mide 3.557px y esos mismos 28s habrían dado 127px/s —cuatro veces y media más rápido— y los logos pasan volando sin que se lean. 90s devuelve la velocidad a 40px/s a 1440 y 33px/s a 390. */ animation: cc-marcas-correr 90s linear infinite; /* `will-change` NO se declara: el navegador ya promueve una capa para una animación de transform en curso, y dejarlo fijo reserva memoria de vídeo para siempre en una página que además tiene otras seis animaciones. */ } .cc-marcas__pista { display: flex; align-items: center; gap: var(--cc-marcas-hueco); margin: 0; /* El hueco de la derecha es parte de la pista: es lo que hace exacto el −100/N. */ padding: 0 var(--cc-marcas-hueco) 0 0; list-style: none; } .cc-marcas__item { flex: 0 0 var(--cc-marcas-celda); display: flex; align-items: center; justify-content: center; } /* --- Los logos de la cinta (2026-08-22) ------------------------------------ Hasta hoy la cinta llevaba los NOMBRES en texto —«Copec · Falabella · Cencosud · Walmart · Mercado Libre»—, y de esos cinco solo Copec era cliente: los otros cuatro entraron con el primer import del rediseño como texto de maqueta y contradecían al propio `/portafolio/` del sitio, que nombra Tecno Fast, AGUNSA, Corona y Sencillito. Las 16 marcas de ahora salen del ERP: facturación en los últimos 3 meses y archivo de logo sin problemas anotados. TRES decisiones de sistema, las tres medidas y las tres explicadas en 8.83: 1. **El ritmo lo pone la CELDA, no el hueco.** Los logos miden de 44 a 175px de ancho; con un hueco fijo, la distancia ENTRE MARCAS sale distinta en cada pareja y la fila se lee desordenada aunque el hueco sea idéntico. Con celda de ancho fijo y el logo centrado dentro, el ritmo horizontal es exacto. 2. **Los archivos van RECORTADOS al borde del dibujo.** Kupfer y workit traían un 45% de caja transparente, Metra un 20%, Corona un 39% de alto. Eso pinta la marca más chica que sus vecinas Y le suma aire que el hueco no controla. Los rasters se recortaron por su caja de alfa; a los SVG se les reescribió el `viewBox` al `getBBox()` real. 3. **El tamaño sale de la TINTA, con el alto acotado.** `--cc-h` es el alto pintado de cada logo, calculado para que todos pongan ~900 px² de tinta —`h = √(T/(densidad· proporción))`— y luego acotado a 22–48px. Sin acotar, la tinta queda perfecta (1,01x) pero los altos van de 14 a 72px y la fila se ve descuadrada. Acotado, la tinta queda en 3,15x y los altos en 15–48. **Es un intercambio deliberado**: coherencia de altura por balance de tinta, porque lo primero se ve. ⚠️ Si se cambia o se añade un archivo hay que RECALCULAR su `--cc-h`: el número sale de la densidad de tinta del arte, no del nombre. `home.mjs` mide la razón y falla si se dispara. **Monocromo, y por eso los archivos pesan lo que pesan.** El logo se pinta siempre en un solo color —blanco sobre oscuro, negro sobre claro—, o sea el color de origen es información que se tira. Los rasters se guardan como alfa sobre blanco en WebP sin pérdida: los 10 bajaron de 183 KB a 38 KB sin perder un píxel de forma. ⚠️ `metra` llegó como `.svg` de 20 KB y era **98% un PNG incrustado, cero paths** (8.46): convertido a WebP pesa 2,7 KB. ⚠️ **mK quedó FUERA** aunque es el nº 5 por facturación: su logo es un «mK» en blanco calado sobre una placa oscura, o sea la marca ES el hueco. Bajo cualquier filtro monocromo se convierte en un rectángulo relleno. Hace falta pedirle a la marca una versión monocroma con fondo transparente. */ .cc-marcas__logo { --cc-h: 32; display: block; width: auto; height: calc(var(--cc-h) * var(--cc-marcas-escala) * 1px); max-width: 100%; filter: brightness(0) invert(1); opacity: .68; transition: opacity var(--cc-dur-base) var(--cc-ease-out); } /* El nombre en TEXTO viaja en el markup y está oculto: el logo es lo que se pinta en la portada. Existe para que las variantes de texto del laboratorio sean un cambio de CSS y no de plantilla, y va `display: none` —no `visibility` ni `clip`— porque el nombre ya lo anuncia el `alt` del logo: mostrarlo a un lector de pantalla lo diría dos veces. Lleva además `aria-hidden` por si alguna variante lo saca de `display: none` sin quitar el `alt`. */ .cc-marcas__nombre { display: none; } /* El hover de la cinta va en el ITEM y no en el logo porque el logo mide justo lo que mide su arte: en un `--cc-k` de 0.72 el blanco de Feltrex ocupa 108x29 y apuntar ahí con el puntero mientras la cinta corre es imposible. */ .cc-marcas__item:hover .cc-marcas__logo { opacity: 1; } /* En claro el logo se tiñe de NEGRO, igual que los badges de la trust bar (8.68). */ html[data-theme="light"] .cc-marcas__logo { filter: brightness(0); opacity: .7; } html[data-theme="light"] .cc-marcas__item:hover .cc-marcas__logo { opacity: 1; } .cc-marcas__logo--corona { --cc-h: 22; } /* 167x22 · tinta 1221 px² */ /* Newman entró el 2026-08-25. Su altura se MIDIÓ igual que las demás —rasterizando el SVG y contando píxeles opacos hasta acercarse a los ~900 px² de tinta con los que se normaliza la cinta—, no se eligió a ojo: a 24px da 870, y las alturas vecinas dan 607 (20px) y 1142 (28px). El archivo ya estaba en el theme: lo usa /servicios/agencia-seo/ en su tabla de casos, así que no hubo que pedirlo. */ .cc-marcas__logo--newman { --cc-h: 24; } /* 62x24 · tinta 870 px² */ .cc-marcas__logo--tecno-fast { --cc-h: 42; } /* 97x42 · tinta 900 px² */ .cc-marcas__logo--metra { --cc-h: 48; } /* 68x48 · tinta 399 px² */ .cc-marcas__logo--workit { --cc-h: 30; } /* 79x30 · tinta 900 px² */ .cc-marcas__logo--theoduloz { --cc-h: 30; } /* 133x30 · tinta 900 px² */ .cc-marcas__logo--copec { --cc-h: 15; } /* 175x15 · tinta 988 px² */ .cc-marcas__logo--victorinox { --cc-h: 48; } /* 110x48 · tinta 854 px² */ .cc-marcas__logo--kupfer { --cc-h: 48; } /* 61x48 · tinta 411 px² */ .cc-marcas__logo--feltrex { --cc-h: 27; } /* 102x27 · tinta 900 px² */ .cc-marcas__logo--byp { --cc-h: 48; } /* 66x48 · tinta 501 px² */ .cc-marcas__logo--sencillito { --cc-h: 22; } /* 114x22 · tinta 1020 px² */ .cc-marcas__logo--animal-care { --cc-h: 28; } /* 146x28 · tinta 900 px² */ .cc-marcas__logo--open-english { --cc-h: 36; } /* 97x36 · tinta 900 px² */ .cc-marcas__logo--adflip { --cc-h: 28; } /* 126x28 · tinta 900 px² */ .cc-marcas__logo--emasa { --cc-h: 45; } /* 44x45 · tinta 900 px² */ .cc-marcas__logo--maxtec { --cc-h: 22; } /* 124x22 · tinta 1251 px² */ @media (max-width: 640px) { /* La celda ya encoge por su `clamp`, pero el LOGO no: a 390px un Tienda Copec de 175px no cabe en una celda de 132. Se baja la escala del arte, no la del hueco. */ .cc-marcas { --cc-marcas-escala: .82; } } @keyframes cc-marcas-correr { to { transform: translateX(-25%); } /* −100/N con N=4 pistas */ } /* --- Pausa ---------------------------------------------------------------- */ /* El input vive fuera de pantalla pero SIGUE siendo enfocable: el visible es el label. No se usa `display:none`, que lo sacaría del orden de tabulación. */ .cc-marcas__check { /* Bricks da a los inputs una `transition: .2s` de formulario, y en un elemento invisible eso no significa nada — pero sí ensucia la escala de duraciones que `ux.mjs` vigila. Lo cazó el trinquete, no una revisión. */ transition: none; position: absolute; width: 1px; height: 1px; margin: -1px; padding: 0; overflow: hidden; clip: rect(0, 0, 0, 0); white-space: nowrap; border: 0; } .cc-marcas__check:checked ~ .cc-marcas__mask .cc-marcas__cinta { animation-play-state: paused; } /* 28×28 como el pausa del hero: pasa el mínimo de 24×24 de WCAG 2.5.8 por su propia caja, sin depender del `::after` de 8.17 — que aquí no serviría porque los pseudo-elementos están dibujando el icono. */ .cc-marcas__pausa { flex: none; display: inline-flex; align-items: center; justify-content: center; gap: 3px; width: 28px; height: 28px; border-radius: var(--cc-radius-pill); cursor: pointer; /* 0.55 de alfa da 3:1 sobre el fondo base, el mínimo de WCAG 1.4.11 para un componente de interfaz. En claro manda el token, que da 6.9:1. */ color: rgba(255, 255, 255, 0.55); transition: color var(--cc-dur-fast) var(--cc-ease-out); } html[data-theme="light"] .cc-marcas__pausa { color: var(--cc-fg-muted); } .cc-marcas__pausa:hover { color: var(--cc-fg-accent); } .cc-marcas__pausa::before, .cc-marcas__pausa::after { content: ""; width: 3px; height: 11px; background: currentColor; border-radius: 1px; } /* Pausado: el icono pasa a "play", porque un control muestra la ACCIÓN que ejecuta y no el estado en que está (8.22). */ .cc-marcas__check:checked ~ .cc-marcas__pausa::after { display: none; } .cc-marcas__check:checked ~ .cc-marcas__pausa::before { width: 10px; border-radius: 0; clip-path: polygon(0 0, 100% 50%, 0 100%); } /* El foco del teclado se ve en el label, que es lo visible. */ .cc-marcas__check:focus-visible ~ .cc-marcas__pausa { outline: 3px solid var(--cc-fg-accent); outline-offset: 2px; box-shadow: 0 0 0 6px rgba(10, 10, 15, 0.55); } /* Quien pidió menos movimiento ve la fila quieta. Y el control de pausa deja de tener sentido, así que se oculta: un botón que no hace nada es peor que ninguno (8.19). Las repeticiones sobrantes las recorta la máscara. */ @media (prefers-reduced-motion: reduce) { .cc-marcas__cinta { animation: none; } .cc-marcas__pausa { display: none; } } /* ========================================================================== SERVICIOS (/servicios/) — 2026-08-03 Rediseño de la página madre de servicios. La consigna de Ricardo fue explícita: "fiel al tema que hemos hecho, que toda la página sea igual, no tenga distintos formatos". Así que la pieza NO trae vocabulario nuevo: reusa el hero, las tarjetas, la banda y el cierre de la home, y las cuatro unidades Canal.* con las MISMAS descripciones que ya usa `home.json`. Lo único que se añade acá son las tres clases que faltaban para que la tarjeta de servicio sea UNA sola definición en vez de un `_cssCustom` por tarjeta. Es 8.18 al revés: en la home cada card escribía su propio relleno, borde y radio (y por eso el modo claro necesitó una lista de 7 ids); acá el formato vive en la clase, así que las nueve tarjetas de la página son idénticas por construcción y el tema claro se resuelve con una línea que ya está más arriba (`.cc-svc-card` entra en las dos reglas del modo claro, la del fondo y la de la elevación). ========================================================================== */ /* La grilla de tarjetas de una unidad. El mínimo va con `min()` y no pelado: un mínimo rígido en una grilla es una promesa de overflow (8.7, tercera aparición). */ /* El mínimo subió de 280 a 320px el 2026-08-09, al entrar la primera unidad con CINCO tarjetas (`agencia-marketing`). A 280px y 1180 de ancho caben CUATRO columnas exactas (4×280 + 3×20 = 1180), así que esa página salía 4 + 1 huérfana y con las tarjetas a 280px de ancho: medido, 906px de alto y ~30 caracteres por línea, o sea por debajo del único bloque del sitio que `docs/pendientes.md` ya tenía marcado como fuera del rango cómodo de lectura (34). Con 320 el tope son TRES columnas (3×320 + 2×20 = 1000 ≤ 1180; con cuatro serían 1340), así que esa página queda 3 + 2 y las tarjetas a ~380px. No cambia nada de lo que ya existía: las unidades de 2 y de 3 tarjetas de la página madre siguen midiendo 580 y 380px, porque `auto-fit` colapsa las pistas vacías y reparte el sobrante igual. Verificado antes y después. */ .cc-svc-grid { display: grid; grid-template-columns: repeat(auto-fit, minmax(min(320px, 100%), 1fr)); gap: 20px; } /* `align-items: stretch` NO es redundante, y es el bug que Ricardo leyó como "todo muy descuadrado" (2026-08-04). El elemento `block` de Bricks es un flex column con `align-items: flex-start` (clase `.brxe-block`), y ese valor SOBREVIVE al pasar la caja a `display: grid`: se aplica igual al contexto de grid, donde significa "cada tarjeta con su altura natural" en vez del `stretch` que trae un grid por defecto. Medido: 227 vs 202px en Canal.Commerce y 253/227/227 en Canal.Brand, o sea las filas quedaban con un escalón de hasta 26px según cuánto midiera cada descripción. Es la trampa de 8.1 en su forma más silenciosa: `display` sí se pisó desde la clase, así que la regla PARECE haber entrado del todo, y lo que quedó atrás es una propiedad que nadie declaró en esta hoja. El selector doble es a propósito (8.1): con (0,2,0) le gana a `.brxe-block` sin depender de que `cc-components.css` cargue después. */ .brxe-block.cc-svc-grid { align-items: stretch; } /* La tarjeta. Mismo relleno (blanco al 6%), mismo hairline y mismo radio que las de la home tras la auditoría del 2026-08-03: en oscuro la elevación la da la superficie más clara, no una sombra. */ .cc-svc-card { background: rgba(255, 255, 255, 0.06); /* El borde se TIÑE con el color de la unidad en vez de llevarlo pleno: a fuerza completa cuatro bordes de color saturado convierten la página en un semáforo y compiten con el titular. Fuera de una unidad `--cc-unidad` no existe y el borde vuelve al de siempre, así que las tarjetas del blog y de la home no se enteran. Estaba al 34% mientras la marca superior llevaba el color a pleno. Retirada la marca (ver el bloque "dónde vive el color" más abajo), en las 4 hijas de `/servicios/` este borde quedó como ÚNICO canal —esas tarjetas no llevan número ni enlace— y al 34% sobre `rgba(255,255,255,.06)` no se distingue del hairline blanco: eso es el *"o no hay color"* del reporte del 2026-08-09. Al 55% se lee como borde de color y sigue sin gritar; el hover va a pleno (100%) en vez del 78% anterior, porque ahora es él quien tiene que marcar TODO el cambio de estado. */ border: 1px solid var(--cc-border-on-dark); border-color: color-mix(in srgb, var(--cc-unidad, transparent) 55%, var(--cc-border-on-dark)); border-radius: var(--cc-radius-lg); padding: 34px 30px; display: flex; flex-direction: column; gap: 14px; transition: border-color var(--cc-dur-base) var(--cc-ease-out); } /* Al hover la tarjeta afirma su unidad: el borde sube a pleno. Es un cambio de estado real y medible, no solo un color más bonito (8.18: un control que no responde al puntero no se lee como control). */ .cc-svc-card:hover { border-color: color-mix(in srgb, var(--cc-unidad, transparent) 100%, var(--cc-border-on-dark)); } /* El elemento `text` de Bricks envuelve su contenido en un
(8.9), y ese
trae el margen del navegador: sin esto el `gap` del flex no manda y las tarjetas quedan con espaciados distintos entre sí según qué elementos tengan. */ .cc-svc-card :is(p, h3) { margin: 0; } /* El enlace se pega abajo, así que las flechas de una fila quedan alineadas aunque las descripciones midan distinto. `auto` en el margen superior de un hijo flex es lo que hace ese trabajo sin fijar alturas. Pero el `auto` tiene que ir en el HIJO DIRECTO del flex, y el enlace NO lo es: el elemento `text` de Bricks lo envuelve en un `
` dentro de su propio div (8.9, en dos capas), así que la cadena real es `.cc-svc-card > div.brxe-text > p > a`. Sobre el `` el margen no hacía nada. Esto estuvo TAPADO por el bug del `align-items` de más arriba (8.24: un bug tapado por otro no está arreglado, está esperando): mientras cada tarjeta tomaba su altura natural no había espacio sobrante que repartir, así que el enlace caía al fondo por su cuenta y el chequeo de "las flechas quedan alineadas" pasaba. Al estirar las tarjetas apareció el sobrante y las flechas se separaron 26px — el chequeo lo reportó en la primera corrida. `:has()` en vez de una clase en el template a propósito: así el arreglo viaja en git y no hay que re-exportar el JSON ni escribir en la BD (§10). Si un navegador no lo soporta, degrada al comportamiento anterior en vez de romper nada. */ .cc-svc-card > .brxe-text:has(.cc-cardlink) { margin-top: auto; } .cc-svc-card > .cc-cardlink { margin-top: auto; } .cc-svc-card .cc-cardlink { margin-top: 0; } .cc-svc-card__title { font-family: var(--cc-font-sans); font-weight: 700; font-size: 22px; line-height: 1.2; letter-spacing: -0.01em; color: var(--cc-fg-strong); } /* ⚠️ El color pasó de `--cc-fg-muted` a `--cc-fg-read` el 2026-08-10, y es un fallo AA que llevaba meses. `--cc-fg-muted` (#898989) está calibrado contra el fondo de SECCIÓN, pero esta tarjeta se pinta sobre `rgba(255,255,255,.06)`, o sea una superficie un 6% más clara: compuesto da (42,40,55) y el ratio cae a **4.14:1**, bajo el 4.5 de WCAG 1.4.3. Estuvo tapado porque el medidor de contraste **se saltaba las capas con alfa < 0.85** y medía contra la sección directamente. Al componerlas de verdad —cambio del mismo día, forzado por bajar el header al 72%— apareció solo. Es 8.25.8 otra vez en su forma general: **un token de texto no es seguro por sí mismo, lo es contra una superficie**, y cambiar la superficie sin re-medir el texto es donde se cuelan estos. `--cc-fg-read` es además el token que corresponde: esto es la descripción del servicio, o sea texto de lectura, no un metadato. Queda en 8.52:1. */ .cc-svc-card__texto { font-family: var(--cc-font-sans); font-weight: 400; font-size: 16px; line-height: 1.6; color: var(--cc-fg-read); } /* ========================================================================== LAS 4 HIJAS: EL SERVICIO COMO REGISTRO (2026-08-23) Ricardo, sobre las tarjetas de estas cuatro páginas: *«las tarjetas así ordenadas con texto y la imagen es muy IA, muy feo sin cuerpo ni diseño»* y *«mucho del color de cada sección»*. Las dos quejas eran ciertas y tenían causas SEPARADAS, medidas: · el color es el duotono COCIDO en los `.webp` por `tools/img/tarjetas-duotono.py`, que cubre el **92–98%** de cada imagen con saturación >0,45. La foto deja de ser foto y pasa a ser un rectángulo de color con textura. Aislado: bajando solo el tinte, el croma de la sección cae del **18,3% al 0,8%** sin mover el layout. · lo «muy IA» es la REPETICIÓN de la misma pila —imagen 16:9 arriba, título, párrafo— en las trece entradas de las cuatro páginas. ⚠️ Y LA ESTRUCTURA LA DECIDE EL CONTENIDO, NO LA PÁGINA. Las cuatro no tienen el mismo número de servicios: Performance Marketing **5**, Creatividad **3**, Diseño **3**, Desarrollo **2**. Un índice existe para HOJEAR: con cinco entradas hojear gana, con dos no hay nada que hojear y plegar la mitad de la página detrás de un hover es perder contenido, no ganar diseño. Así que el umbral va aquí, con `:has()`, y no en una lista de páginas: 4 o más entradas -> ÍNDICE (una línea por servicio, se abre al apuntarla) 3 o menos -> FICHA (entrada completa, con su banda de imagen) Con eso sigue habiendo UNA definición con una condición dentro —no dos que se desincronizan— y si Creatividad pasa mañana de 3 a 5 servicios se convierte en índice sola. Cae de lado seguro: la rama por defecto es la FICHA, que muestra todo, así que si `:has()` fallara nadie pierde contenido. ⚠️ EL ALCANCE ES `body.cc-servicios.page-child:not(.cc-maqueta-propia)`, y no es cosmético: `.cc-svc-card` también vive en **home.json** (las 4 tarjetas de sec040) y en **page-servicios.json** (30 tarjetas en 4 rejillas). Sin acotar, esto reestructuraría la portada y la página madre, que nadie pidió. ⚠️ Y EL `:not()` SE AÑADIÓ EL 2026-08-25 PORQUE ESTE COMENTARIO SE VOLVIÓ FALSO. Decía: «las cuatro hijas son las únicas con `cc-servicios` Y `page-child`». Lo eran hasta que se rediseñó `agencia-seo`: al entrar en `ccd_paths_servicios_redisenados()` ganó las dos clases y **estas 25 reglas se le aplicaron encima**. Sus tarjetas de SXO/GEO/ESO/AEO pasaron a entradas de registro numeradas, las imágenes colapsaron a 0px de alto y las descripciones desaparecieron — otro diseño, aplicado a la pieza equivocada, y **ninguna suite lo cazó porque no era un error, era un diseño distinto**. `page-child` nunca significó «lleva registro de servicios»: era una coincidencia de las 4 hijas que dejó de serlo en cuanto hubo una quinta. La lista vive en `ccd_paths_maqueta_propia()` del child theme, y su nombre dice lo que el alcance quiere decir. Es la misma lección de 8.42: un alcance que se apoya en una coincidencia falla en silencio cuando la coincidencia se rompe. Las variantes que perdieron viven en `assets/css/lab/svc-*.css` con lo que midió cada una: `svc-tinte-suave`, `svc-lado`, `svc-lado-suave`, `svc-ficha`, `svc-sin-foto`, `svc-indice`, `svc-columna`. ========================================================================== */ /* ── EJE 1 · la cabecera deja de irse con el scroll. En las cuatro. ────────── Hoy `«CANAL.MEDIA»` desaparece en los primeros 400px de una sección de 1.550, así que el visitante lee cinco servicios sin ver de qué unidad son. Las dos condiciones del `sticky` se comprueban, no se suponen (8.26): el contenedor pasa a `grid` con `align-items: start` —si estirara el ítem no tendría por dónde deslizarse— y no recorta. El `top` sale del alto real del header, 85px (8.19). */ @media (min-width: 1000px) { body.cc-servicios.page-child:not(.cc-maqueta-propia) #brx-content .cc-stagger:has(> .cc-svc-head) { display: grid; grid-template-columns: minmax(280px, 34%) minmax(0, 1fr); column-gap: clamp(40px, 5vw, 80px); align-items: start; } body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-head { position: sticky; top: calc(var(--cc-header-h) + var(--cc-space-6, 32px)); align-self: start; } } /* ── EJE 2 · las entradas. Una columna, hairline en vez de caja. ───────────── */ body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-grid { grid-template-columns: 1fr; counter-reset: svc; gap: 0; } body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-card { counter-increment: svc; position: relative; background: none; border: 0; /* ⚠️ El hairline va por TOKEN y no por rgba literal, y esto costó el reporte de Ricardo del 2026-08-24 (*«los hijos de servicio en modo blanco no se ven muy bien»*): en blanco al 10% sobre el `#EEEEF1` de la sección da **1.015:1**, o sea los trece separadores del registro desaparecen y las entradas quedan flotando sin estructura. `--cc-rule-on-dark` vale EXACTAMENTE este mismo rgba en oscuro —así que ahí no cambia nada— y voltea a `rgba(32,30,44,0.16)` en claro. 8.96. */ border-top: 1px solid var(--cc-rule-on-dark); border-radius: 0; /* ⚠️ Y SIN SOMBRA, en los dos modos. La regla de elevación del modo claro (`html[data-theme="light"] … .cc-svc-card`, más arriba en esta hoja) se escribió cuando esto ERA una tarjeta; al pasar a registro (8.93) quedó heredada, y una sombra sobre algo sin fondo ni radio dibuja un RECTÁNGULO FANTASMA: en oscuro no se ve, en claro cada entrada volvía a leerse como una caja y el número quedaba pegado a ese borde. Lo reportó Ricardo el 2026-08-24 (*«los cuadrados se notan mucho, y se ve el número pegado»*). Es exactamente lo que avisa el comentario de `.cc-caso` unas líneas más arriba: un componente que cambia de papel tiene que SALIR de las reglas del papel anterior. El `:hover` de abajo ya lo ponía a `none`, o sea la intención estaba escrita solo para un estado. 8.97. */ box-shadow: none; padding: 24px 0 24px 56px; display: flex; flex-direction: column; gap: 10px; transition: border-top-color var(--cc-dur-base) var(--cc-ease-out); } /* ⚠️ El hairline de cierre va en la REJILLA y no en `:last-child`, y la razón es un chequeo: `servicios.mjs` exige que las tarjetas de una página sean UNA definición, y con el borde en la última entrada esa entrada difería de las demás. La regla existe desde el 2026-08-09 y tenía razón — el arreglo es no crear la excepción. */ body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-grid { border-bottom: 1px solid var(--cc-rule-on-dark); } /* Sin caja no hay elevación: el gesto se resuelve en el hairline. */ body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-card:hover { transform: none; box-shadow: none; border-top-color: var(--cc-unidad, var(--cc-fg-accent)); } /* El número es ESTRUCTURA: lo genera un `counter`, así que numera lo que hay. Si entra un servicio se renumera solo. Tabular para que las cifras no bailen. */ body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-card::before { content: counter(svc, decimal-leading-zero); position: absolute; left: 0; top: 33px; font-family: var(--cc-font-sans); font-weight: 800; font-size: 13px; font-variant-numeric: tabular-nums; letter-spacing: 0.06em; color: var(--cc-unidad, var(--cc-fg-accent)); } /* La imagen: banda baja y ancha AL FINAL de la entrada, con `order`. Deja de llevarse 325 de los 623px de alto de la tarjeta y de competir por el ancho. ⚠️ Se resuelve con `flex` + `order` y NO con rejilla: dos intentos con `grid` —por `grid-template-areas` y por número de línea— dejaron la banda en una fila de 64px siendo de 92, pintándose sobre la última línea del párrafo. La tarjeta ya es flex en columna por la regla de arriba, así que mandarla al final es una propiedad. Menos piezas y nada que resolver. */ body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-card .cc-svc-card__media { order: 9; width: 100%; height: 92px; margin-top: 6px; border-radius: 3px; object-fit: cover; object-position: center 40%; /* Monocroma en reposo: a 92px de alto el duotono no aporta motivo, solo tinte, y el color de la unidad ya lo declara el número. */ /* ⚠️ La atenuación va en el FILTRO y no en `opacity`, y esto lo forzó un chequeo: `servicios.mjs` exige que nada visible quede bajo 0.9 de opacidad tras recorrer (8.24), porque así se detecta un reveal que no disparó. Un `opacity: .55` deliberado es indistinguible de ese bug para el instrumento — y encima sobre fondo oscuro mezcla la imagen hacia el fondo en vez de controlarla. Con `brightness` el resultado es el mismo a la vista y la invariante sigue con dientes. */ filter: grayscale(1) contrast(1.08) brightness(0.72); transition: filter var(--cc-dur-base) var(--cc-ease-out); } /* Al apuntar la entrada la banda recupera color. Es la ÚNICA vez que el color aparece en la imagen, y significa «esta es la que estás leyendo». */ body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-card:hover .cc-svc-card__media, body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-card:focus-within .cc-svc-card__media { filter: saturate(0.5) contrast(1.06) brightness(1); } /* Los chips dejan de ser píldoras. ⚠️ Y solo existen en `/desarrollo/`: once de las trece entradas no tienen ni uno (medido), así que esto afecta a una página. */ body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-card .cc-chip { border: 0; padding: 0; background: none; font-size: 13px; letter-spacing: 0.02em; } body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-card .cc-chip:not(:last-child)::after { content: " · "; color: rgba(255, 255, 255, 0.28); } /* ── EJE 2b · con 4 entradas o más, la entrada se PLIEGA ──────────────────── ⚠️ El revelado va DEBAJO, no al lado, y la razón es el eje 1: con la cabecera fija ocupando el 34% la entrada baja de 1.180 a ~780px, y abrir la foto en una columna del 34% DE ESOS 780 solapaba el texto en las cinco entradas (medido). Como banda inferior las dos ramas comparten el objeto y solo cambia CUÁNDO aparece. */ /* ⚠️ La rama índice NO cambia el formato de la entrada: mismo relleno, mismo tamaño de título, mismo hairline. Lo único que cambia es si el detalle está plegado — un ESTADO, no un formato. Tenerlo así es lo que permite que el chequeo «las 4 páginas comparten UNA definición» siga en pie, y ese chequeo es la escritura de 8.40. */ body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-grid:has(> .cc-svc-card:nth-child(4)) > .cc-svc-card .cc-svc-card__media { filter: saturate(0.35) contrast(1.06) brightness(1); } /* ⚠️ EL PLEGADO SOLO DONDE HAY PUNTERO. En táctil no hay hover, así que ahí la entrada se muestra ENTERA desde el principio: un acordeón que solo abre con puntero es contenido inaccesible en teléfono, no un efecto (8.92). */ @media (hover: hover) and (min-width: 1000px) { body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-grid:has(> .cc-svc-card:nth-child(4)) > .cc-svc-card .cc-svc-card__texto, body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-grid:has(> .cc-svc-card:nth-child(4)) > .cc-svc-card .cc-chips, body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-grid:has(> .cc-svc-card:nth-child(4)) > .cc-svc-card .cc-svc-card__media { max-height: 0; opacity: 0; overflow: hidden; margin-top: 0; transition: max-height var(--cc-dur-slow) var(--cc-ease-out), opacity var(--cc-dur-base) var(--cc-ease-out), margin-top var(--cc-dur-slow) var(--cc-ease-out); } body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-grid:has(> .cc-svc-card:nth-child(4)) > .cc-svc-card:hover .cc-svc-card__texto, body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-grid:has(> .cc-svc-card:nth-child(4)) > .cc-svc-card:focus-within .cc-svc-card__texto { max-height: 12em; opacity: 1; margin-top: 10px; } body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-grid:has(> .cc-svc-card:nth-child(4)) > .cc-svc-card:hover .cc-chips, body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-grid:has(> .cc-svc-card:nth-child(4)) > .cc-svc-card:focus-within .cc-chips { max-height: 6em; opacity: 1; margin-top: 10px; } body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-grid:has(> .cc-svc-card:nth-child(4)) > .cc-svc-card:hover .cc-svc-card__media, body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-grid:has(> .cc-svc-card:nth-child(4)) > .cc-svc-card:focus-within .cc-svc-card__media { max-height: 92px; opacity: 1; margin-top: 12px; } } /* Quien pidió menos movimiento no pliega nada: no hay nada que desplegar (8.23). */ @media (prefers-reduced-motion: reduce) { body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-grid:has(> .cc-svc-card:nth-child(4)) > .cc-svc-card .cc-svc-card__texto, body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-grid:has(> .cc-svc-card:nth-child(4)) > .cc-svc-card .cc-chips, body.cc-servicios.page-child:not(.cc-maqueta-propia) .cc-svc-grid:has(> .cc-svc-card:nth-child(4)) > .cc-svc-card .cc-svc-card__media { max-height: none; opacity: 1; transition: none; } } /* Área de golpeo del correo del footer (WCAG 2.5.8, 8.17). Al dejar de ser botón se quedó en 211x20: los 24px de alto los daba el relleno del botón, no el texto. */ .cc-foot__mail a { display: inline-block; padding-block: 4px; } /* El marcador de orden (01–04). Va por token y no por el verde de marca directo: en claro `--cc-fg-accent` ya es el verde de tinta (5.34:1), así que no hace falta sumar este id a la lista A2 del modo claro. Y desde el 2026-08-04 toma primero el color de la unidad, así que el 01 de Media es verde y el 04 de Brand magenta. */ .cc-svc-num { font-family: var(--cc-font-sans); font-weight: 700; font-size: 13px; line-height: 1.6; color: var(--cc-unidad, var(--cc-fg-accent)); } .cc-svc-num p { margin: 0; } /* ========================================================================== COLOR POR UNIDAD DE NEGOCIO (2026-08-04) Pedido por Ricardo: *"encuentro todo muy genérico, sin identidad, muy IA"*, con `infracommerce.lat` como referencia. Lo que esa página hace y que aquí se podía copiar SIN plagiar nada es que sus sub-marcas (`infra.digital`, `.tech`, `.data`, `.pay`, `.log`) llevan un punto de color distinto cada una. Canal Cero ya tiene esa misma estructura —Canal.Media / .Commerce / .Data / .Brand, con el punto marcado en el markup— y la pintaba toda del mismo verde. O sea la identidad ya estaba escrita y no se estaba usando: es la mejora de carácter más barata que había en el sistema. MECANISMO: no hay una lista de ids ni una regla por unidad. Cada isla redefine UNA custom property, `--cc-unidad`, y como las custom properties heredan, todo lo que hay dentro cambia junto: el punto del nombre (`.cc-acento`), el número de orden (`.cc-svc-num`), el borde de las tarjetas (`.cc-svc-card`) y el color de los enlaces con flecha (`.cc-cardlink`). Ninguna de esas cuatro reglas sabe en qué unidad está, y un elemento que se agregue mañana dentro de una isla entra solo. Es el patrón de 8.25.5 —arreglar por ALCANCE y no por enumeración— aplicado a la identidad en vez de a un bug. Y por eso cada regla lleva `var(--cc-unidad, )`: fuera de una isla el token no existe y todo se comporta exactamente como antes del cambio. Las tarjetas del blog, las de la home que no son de unidad y los enlaces del footer no se enteran. Los ocho valores viven en `cc-tokens.css` con su tabla de contraste medido. Los cuatro pasan AA sobre el fondo, la superficie y el violeta en oscuro, y sobre blanco y paper en claro. ========================================================================== */ .cc-u-media { --cc-unidad: var(--cc-u-media); --cc-unidad-ink: var(--cc-u-media-ink); } .cc-u-commerce { --cc-unidad: var(--cc-u-commerce); --cc-unidad-ink: var(--cc-u-commerce-ink); } .cc-u-data { --cc-unidad: var(--cc-u-data); --cc-unidad-ink: var(--cc-u-data-ink); } .cc-u-brand { --cc-unidad: var(--cc-u-brand); --cc-unidad-ink: var(--cc-u-brand-ink); } /* El modo claro se resuelve con UNA regla para las cuatro, no con cuatro overrides: cada isla ya declaró su par, así que acá solo se dice "usa el otro". Si mañana hay una quinta unidad, basta añadirla a la lista de arriba y esta regla la cubre. Va con `:is()` para que la especificidad sea la del selector más pesado (1,1,0) y no crezca con cada unidad añadida. */ html[data-theme="light"] :is(.cc-u-media, .cc-u-commerce, .cc-u-data, .cc-u-brand) { --cc-unidad: var(--cc-unidad-ink); } /* ⚠️ Las islas oscuras del modo claro (8.25.5 y 8.25.8 — banda violeta, cierre, footer, caja CTA de la nota) vuelven a fondo OSCURO, así que dentro de ellas el color de unidad tiene que ser el BRILLANTE otra vez, no la tinta. Sin esto, una tarjeta de unidad colocada dentro del cierre en modo claro quedaría con su color de tinta sobre fondo casi negro. Hoy no hay ninguna ahí; la regla existe porque el día que la haya el fallo sería silencioso y del tipo que ninguna medición de texto ve (8.25.8). */ html[data-theme="light"] :is(#brxe-sec061, #brxe-sec127, #brxe-ftr001, .cc-cta, .cc-isla-oscura, .cc-proyectos) :is(.cc-u-media, .cc-u-commerce, .cc-u-data, .cc-u-brand) { --cc-unidad: var(--cc-u-media); } html[data-theme="light"] :is(#brxe-sec061, #brxe-sec127, #brxe-ftr001, .cc-cta, .cc-isla-oscura, .cc-proyectos) .cc-u-commerce { --cc-unidad: var(--cc-u-commerce); } html[data-theme="light"] :is(#brxe-sec061, #brxe-sec127, #brxe-ftr001, .cc-cta, .cc-isla-oscura, .cc-proyectos) .cc-u-data { --cc-unidad: var(--cc-u-data); } html[data-theme="light"] :is(#brxe-sec061, #brxe-sec127, #brxe-ftr001, .cc-cta, .cc-isla-oscura, .cc-proyectos) .cc-u-brand { --cc-unidad: var(--cc-u-brand); } /* El nombre de la unidad a 320px: "Canal.Commerce" es un token de 14 caracteres y a `--cc-fs-d2` (mínimo 34px) mide 303px, o sea MÁS que los 272 disponibles. Un flex item no baja de su min-content, así que el titular arrastraba a su bloque y con él a la bajada: 3 nodos fuera de caja y scroll horizontal a 320 (medido, lo cazó responsive.mjs). El punto de quiebre va en el template como `` justo después del punto de acento, que es el único lugar donde partir "Canal.Commerce" se lee bien. Esto es el cinturón para el próximo nombre que sea más largo todavía. */ .cc-svc-head { min-width: 0; } .cc-svc-head > * { min-width: 0; } .cc-svc-head :is(h2, p) { overflow-wrap: break-word; } /* ========================================================================== CARÁCTER: LO QUE EL COLOR POR UNIDAD PROMETÍA Y NO ESTABA LLEGANDO (2026-08-04, segunda tanda) Ricardo, sobre tres capturas: *"esto son cosas que no me gustan, se ven muy IA y feos"* — los silos de S2, las tarjetas de unidad de S5 y los chips de trayectoria/capacidad de S10. Lo medido explica las tres de una sola vez: son la MISMA FORMA repetida 15 veces en tres secciones seguidas —rectángulo redondeado, hairline blanco al 8–14%, relleno al 6%, texto gris y todos los hermanos idénticos—. Sin jerarquía interna y sin color propio, un grupo de cajas iguales es exactamente lo que produce un generador: de ahí la lectura de "IA". Y el color por unidad de 8.34 estaba a medio llegar. Medido en las 4 tarjetas de la home: el número 01–04 salía VERDE en las cuatro (hex fijo `#3dedb4` en el `_typography` del template), el borde era `rgba(255,255,255,0.08)` en las cuatro (regla de ID desde `_cssCustom`, que le gana a la clase — 8.1), y el `:hover` de `.cc-card-hover-violet` los pintaba VIOLETA a los cuatro con `!important`. O sea de los cuatro canales que 8.34 declara —punto, número, borde y flecha— en la home solo funcionaban dos, y el hover contradecía la identidad que la tarjeta acababa de afirmar. Es la lección de 8.18 en su forma más caramente literal: **el sistema existía y la pieza se lo estaba saltando**, así que el arreglo no es diseño nuevo, es dejar de pisar el que hay. Nada de esto añade un color, un radio, una duración ni un tamaño de fuente fuera de la escala: los tamaños nuevos (20px) y los colores nuevos (ninguno) ya estaban en el inventario de la home, que está justo en su trinquete de 12 tamaños y 11 interlineados (ux.mjs). ========================================================================== */ /* --- 1. La tarjeta de unidad: dónde vive el color ---------------------------- El punto del nombre mide 6px y la flecha es un renglón: sumado, el color de unidad ocupaba ~0.4% de una tarjeta de 380×267. Por eso las cuatro se leían iguales de lejos, que es la distancia a la que se mira una grilla. ⚠️ HISTORIA (2026-08-09, no repetir): eso se resolvió con una MARCA SUPERIOR —56px × 3px pegada al borde de arriba, que crecía a 92px al hover—. Ricardo la rechazó explícitamente: *"no me gusta la linea arriba de las tarjetas, esa que aumenta al poner el cursor"*. Se retiró entera, con su hover y su fallback de `prefers-reduced-motion`. No volver a introducir una regla decorativa sobre el borde de la tarjeta: el problema que resolvía es real, pero esa forma NO es la solución aceptada. El color se sostiene ahora en los canales que YA declaraba 8.34 y que no son decoración añadida: el borde teñido (abajo), el punto del nombre de la unidad, el número de orden y la flecha del enlace. Lo único que cambió es que el borde pasó a teñirse lo suficiente para leerse solo, porque al quitar la marca era el único canal que quedaba en las tarjetas de las 4 hijas —que no llevan ni número ni enlace—, y al 34% no se veía: es literalmente el *"o no hay color"* del mismo reporte. */ .cc-svc-card { position: relative; } /* La elevación al hover, que en la home la daba `.cc-card-hover-violet` pintando las cuatro tarjetas de violeta con `!important`. Ahora la sombra sale del color de la unidad, así que el estado hovereado AFIRMA la identidad en vez de borrarla. `color-mix` y no un rgba fijo: son cuatro colores y no queremos cuatro sombras escritas a mano (8.18). ⚠️ DECISIÓN DE RICARDO (2026-08-09) — antes esto estaba gateado a `:has(.cc-cardlink)`, o sea solo animaban las tarjetas CON enlace, por 8.18: un lift en algo que no lleva a ninguna parte es una promesa falsa. Lo que ese razonamiento no miró es lo que producía en pantalla, y medido es feo: en `/servicios/` animaban **7 de 10** —las 3 de Canal.Data no, porque son las únicas sin página hija— y en las **4 hijas no animaba NINGUNA**, porque ninguna de sus tarjetas lleva enlace. O sea la misma tarjeta, en la misma grilla, se comportaba de dos maneras sin que el visitante tuviera forma de saber por qué. Reportado así: *"las tarjetas de .data en servicios no tienen animación y luces, como las otras cartas"*. Se quitó el gate: **todas** las `.cc-svc-card` elevan y encienden su halo. El riesgo de 8.18 sigue siendo real y no se niega — la salida de fondo es darle a Canal.Data una página propia, que es lo que la haría clicable de verdad (anotado en `docs/pendientes.md`). Entre "todas iguales sin destino" y "unas sí y otras no", la decisión fue la primera. */ .cc-svc-card { transition: transform var(--cc-dur-base) var(--cc-ease-out), border-color var(--cc-dur-base) var(--cc-ease-out), box-shadow var(--cc-dur-base) var(--cc-ease-out); } .cc-svc-card:hover { transform: translateY(-6px); box-shadow: var(--cc-shadow-card-dark), 0 18px 40px -22px color-mix(in srgb, var(--cc-unidad, transparent) 60%, transparent); } @media (prefers-reduced-motion: reduce) { /* Sin desplazamiento, pero el feedback se conserva: la sombra negra casi no se ve sobre #0A0A0F, así que el fallback estático es un anillo del color de la unidad. Mismo criterio que el de `.cc-card-hover-violet` de arriba. */ .cc-svc-card:hover { transform: none; box-shadow: 0 0 0 1px color-mix(in srgb, var(--cc-unidad, transparent) 70%, transparent), 0 0 26px -6px color-mix(in srgb, var(--cc-unidad, transparent) 45%, transparent); } } /* El número de orden. Sube de 13 a 20px —los dos ya estaban en la home, así que el trinquete de tamaños no se mueve— y toma el color de la unidad desde el template (el `_typography` de Bricks emite regla de ID, así que el valor tiene que vivir ahí, no acá: 8.1). Lo que sí va acá es la marca tabular, para que 01/02/03/04 ocupen exactamente lo mismo y la columna de números quede a plomo entre tarjetas. */ .cc-u-num p, .cc-u-num { font-variant-numeric: tabular-nums; font-feature-settings: "tnum" 1; } /* --- 2. Los silos: cada uno lleva el color de la unidad que lo REEMPLAZA ------ Los cuatro proveedores de S2 mapean 1 a 1 con las cuatro unidades de S5: agencia de medios → Canal.Media, desarrollador ecommerce → Canal.Commerce, consultora de datos → Canal.Data, productora de contenido → Canal.Brand. Esa correspondencia estaba en la copia y no en el diseño. Con el color puesto, S2 y S5 pasan a ser la misma historia contada dos veces: lo que en S2 está disperso, apagado y sin conectar, en S5 aparece ordenado, a pleno color y bajo un mismo techo. No hace falta explicarlo con una flecha ni con un "antes/después": es el mismo vocabulario cromático en dos estados. El color va DEBILITADO acá a propósito (punto al 55%, borde teñido al 22%): el silo tiene que leerse como el problema, no como la marca. Si estuviera a pleno las dos secciones dirían lo mismo con la misma fuerza y el contraste narrativo —que es todo el punto— se perdería. */ .cc-silo { position: relative; /* El `padding-left: 40px` existía para dejarle hueco al punto de color, y el punto se retiró el 2026-08-13 (ver abajo). Quedó un relleno asimétrico de 40 contra 22 que se lee como descuadre: las cuatro tarjetas van ahora con el mismo aire por los cuatro lados. */ padding: clamp(18px, 1.8vw, 24px); /* Borde neutro: el teñido por unidad salió con el resto del color (ver el aviso del icono, arriba). Un solo valor para las cuatro. */ border-color: rgba(255, 255, 255, 0.10); /* Sobre la superficie nueva la caja está a 1.18 de contraste y sin sombra (medido 2026-08-04), así que no se separaba del fondo: en oscuro la elevación la da la sombra tanto como en claro (8.27.3). */ /* Sombra propia y no `--cc-shadow-card-dark`: ese token desplaza 14px hacia abajo, que con la caja recta deja un borde oscuro asomando bajo la tarjeta. Aquí basta un halo casi centrado — profundidad sin segunda caja. */ box-shadow: 0 6px 22px -12px rgba(0, 0, 0, 0.7); } /* (El punto de color vivía aquí y se retiró el 2026-08-13 — el porqué está unas líneas más abajo, junto al del conector: en la tarjeta nueva el color de unidad ya lo lleva el icono y el punto lo repetía.) */ /* ⚠️ AQUÍ VIVÍAN EL PUNTO (`::before`) Y EL CONECTOR (`::after`), Y LOS DOS SE RETIRARON EL 2026-08-13 al pasar los silos de apilado vertical a rejilla de 4. El conector era una línea de 1px que salía a `left: 100%` y se desvanecía "sin llegar a nada", para que la desconexión la dijera el dibujo y no solo el texto. Traía una garantía escrita y MEDIDA: *"34px no alcanza a ningún vecino en ningún ancho"*, cierta mientras los `margin-left` escalonados separaban los silos entre 10 y 150px. En la rejilla el hueco es `clamp(10px, 1.4vw, 18px)`: **el conector se pasa 16px y aterriza sobre la tarjeta de al lado.** Ricardo lo vio como "un rayo en el lado derecho de cada tarjeta, se ve feo", y medido era peor que feo — un hilo que une dos silos dice justo lo contrario de lo que la sección argumenta. > Una invariante geométrica no sobrevive a un cambio de maqueta por sí sola. > Estaba medida, estaba documentada, y cambiar el layout la volvió falsa sin que > nada fallara: ninguna prueba miraba la distancia entre el conector y su vecino. El punto se va por otra razón: en la tarjeta nueva el color de unidad ya lo lleva el ICONO, arriba a la izquierda. Un punto del mismo color a media altura lo repite y, sin la etiqueta de una línea a la que servía de viñeta, se lee como suciedad. Cada significado con un solo portador: el color lo dice el icono, la desconexión la dicen los haces —que además ahora se ve, porque se apagan sin juntarse—. */ /* Modo claro: el silo va a papel blanco (regla A2 de más arriba), así que el borde teñido tiene que repetir el `var(--cc-unidad, …)` sobre el hairline oscuro. Sin esto el teñido funcionaría en oscuro y en claro volvería al gris neutro en los cuatro — que es exactamente 8.32, tercera vez. */ html[data-theme="light"] .cc-silo { border-color: rgba(32, 30, 44, 0.16); } /* --- 3. Trayectoria y capacidad: dos cosas distintas, dos formatos ----------- Los 7 chips de S10 eran la misma pill siete veces: 1px de borde, fondo transparente, 15px regular, radio 999. Leídos así son etiquetas de un CMS, y sobre todo esconden que las dos filas dicen cosas de naturaleza distinta: · TRAYECTORIA son DATOS (15 años, +200 marcas, 6 países) — hechos medibles. · CAPACIDAD son CREDENCIALES (Google Premier Partner, VTEX partner oficial) — cosas que alguien de afuera certifica. Un dato no se mete en una cápsula: se muestra. Una credencial sí, porque una cápsula con borde de color ES el lenguaje de un sello. Separar los formatos le da a la sección la jerarquía interna que no tenía, y de paso resuelve que el activo más fuerte de la banda estuviera al mismo tamaño que su etiqueta. Los datos suben a 20px/700 —tamaño que ya existía en la home— y se separan con hairlines en vez de bordes cerrados: es la forma de una ficha técnica, no de una nube de tags. */ .cc-especs { --cc-espec-sep: rgba(255, 255, 255, 0.12); } /* ⚠️ El separador solo existe cuando los datos van EN UNA LÍNEA, y esto lo cazó una captura a 390px: al envolverse la fila, cada item queda en su propio renglón y el `border-left` se convierte en **un palito vertical suelto a la izquierda de tres de los cuatro** —del primero no, porque es el que no lleva la regla—. Un separador que no separa nada se lee como un resto de maquetación. 768px es donde los cuatro caben en una línea (medido: suman 508px de texto y hay 652 de ventana). Bajo eso se apilan, y el `min-width: 100%` del rótulo hace que arranquen en su propio renglón en vez de dejar al primero colgado al lado de "TRAYECTORIA". El rótulo lleva `!important` porque su `min-width: 110px` sale de un `_cssCustom`, o sea de una regla de ID: es el único caso en el que una utilidad puede ganarle (8.1). */ /* `.cc-cred` entra en la misma regla desde el 2026-08-06: la fila de CAPACIDAD dejó de ser tres cápsulas y ahora comparte el lenguaje de ficha de datos con la de TRAYECTORIA, o sea también su separador. */ @media (min-width: 768px) { .cc-especs > :is(.cc-dato, .cc-cred) + :is(.cc-dato, .cc-cred) { border-left: 1px solid var(--cc-espec-sep); padding-left: 26px; } } /* ⚠️ Desde el 2026-08-13 las dos filas son una REJILLA y no dos flex independientes, y el motivo se midió: con `flex wrap` la posición de cada item depende del ancho del texto que tiene delante, así que TRAYECTORIA arrancaba sus datos en x=266/384/556 y CAPACIDAD los suyos en x=266/500/703. Sumadas a las columnas de las cifras de arriba (130/542/954) eran **tres rejillas distintas apiladas** y ninguna alineada con otra: eso es lo que se ve como "acoplado", y no el espaciado. Con `110px repeat(3,1fr)` las dos filas comparten la columna del rótulo y las tres de los datos, así que se alinean entre sí por construcción. */ @media (max-width: 767px) { /* El `!important` es el mismo caso de 8.1 que ya documentaba la regla de abajo: la plantilla declara la rejilla desde un `_cssCustom`, o sea una regla de ID, y una utilidad de clase no puede ganarle sin esto. */ .cc-especs { grid-template-columns: 1fr !important; gap: 14px !important; } } /* ⚠️ El separador NO se voltea con el tema, y es un caso de 8.24 que estuvo a punto de colarse: `#brxe-sec061` es una **isla oscura** (está en las PERMITIDAS de `tema.mjs`), o sea sigue siendo violeta en modo claro. Un `--cc-espec-sep` en tinta pintaría hairlines oscuros sobre fondo violeta — correcto para una sección que se aclara, equivocado para una que no. La banda mantiene el separador blanco en los dos temas. */ /* La unidad de medida del dato ("años", "marcas", "países") baja a texto de apoyo: sin esto "15 años" son dos palabras del mismo peso y el número no destaca, que era el problema. El `` lo pone el template, así que el dato sigue siendo UNA cadena traducible y no dos elementos que alguien pueda desalinear en el builder. */ .cc-dato__u { font-size: var(--cc-fs-sm); font-weight: var(--cc-fw-medium); color: var(--cc-fg-muted); } /* La credencial, como dato y no como etiqueta. Sin relleno, sin borde y sin radio: el peso lo da el texto (600 sobre `--cc-fg-strong`) y la separación, el hairline que comparte con `.cc-dato`. Ver el aviso de más arriba. Efecto colateral bueno: al no haber relleno hecho del mismo token que el texto, desaparece de raíz el problema que 8.35 tuvo que medir y compensar en modo claro —el lavado al 8% de `--cc-fg-accent` bajo un texto de `--cc-fg-accent`, que daba 4.48 y no pasaba AA—. El tema claro ya no necesita ninguna excepción para esta fila: es la lección de 8.27.6 (si el template usa el token, el tema no necesita overrides), llegando por la vía de quitar decoración. */ .cc-cred { font-weight: var(--cc-fw-semibold); } /* El rótulo de cada fila (TRAYECTORIA, CAPACIDAD). Estaba a 12px/700 SIN letter-spacing, que es lo que hace que un texto en mayúsculas se lea como grito en vez de como rótulo: en caps, el tracking es lo que separa un eyebrow de una palabra escrita a los gritos. Es tipografía, no color, así que no toca ningún trinquete. */ /* El rótulo de fila de `sec061` (TRAYECTORIA, CAPACIDAD). Pedido de Ricardo el 2026-08-17 (R-01): «más tamaño». Estaban a 12px CLAVADOS en el JSON —la clase solo ponía el interletrado— junto a un contenido de 15-16px, y por eso se leían como una nota al pie en vez de como el rótulo de su fila. ⚠️ NO se suben los otros rótulos de 12px de la portada, y es a propósito: los de `sec020` (`cc-silo__rot`: INVERSIÓN, SESIONES…) viven DENTRO de tarjetas pequeñas, donde 12px es proporcionado. Mismo aspecto, distinto papel; igualarlos habría sido tratar como una sola cosa dos que no lo son. 14px es el siguiente peldaño de la escala (`--cc-fs-xs`) y **ya se usa en la portada**, así que el trinquete de `ux.mjs` no se mueve: sigue habiendo 12 tamaños distintos, que es justo el techo. Subirlo a un valor nuevo habría necesitado decisión de equipo (§7). El valor vive aquí y no en el JSON por 8.18: si hay que volver a tocarlo, es una línea. */ /* La rejilla de las dos filas de especificaciones de `sec061`. Vivía DUPLICADA en el JSON, como `_cssCustom` con selector de id, una copia por fila — o sea dos sitios que tenían que decir lo mismo y ninguna forma de notar que dejaran de hacerlo (§5). Aquí es una. ⚠️ LA COLUMNA DEL RÓTULO ES LO QUE SE ROMPIÓ AL SUBIR EL TAMAÑO (R-01, 2026-08-17). Estaba fijada en 110px, y a 12px «TRAYECTORIA» medía ~108: cabía justo. A 14px mide **125,6px**, o sea se salía 15,6 de su columna y se comía el hueco: quedaban **10px** hasta «15 años», mientras «CAPACIDAD» —108,6px, que sí cabe— conservaba los suyos. Ricardo lo vio en el acto («se ve muy pegado»), y lo que lo delataba no era el hueco pequeño sino que las DOS FILAS no lo tuvieran igual: la corta parecía bien y la larga parecía rota. ⚠️ Y lo primero que medí NO lo vio: comparé la CAJA del rótulo con el inicio del valor y me dio 26px, el `gap` declarado, en los 8 anchos. La caja acaba en el borde de la columna; el texto se sale de ella con `overflow: visible`, así que la caja miente. Hay que medir la TINTA (un `Range` sobre el nodo, o el ancho del texto en un span suelto). Es 8.15 con otra cara: el instrumento devolvía un número correcto de algo que no era la pregunta. El ancho sale de la medida del rótulo más largo, no de un número redondo: 125,6 + holgura. Que las dos filas compartan valor es lo que mantiene alineada la columna de los valores. */ .cc-especs { display: grid; grid-template-columns: var(--cc-especs-rotulo, 136px) repeat(3, 1fr); align-items: baseline; gap: 26px; } .cc-especs > * { width: auto; min-width: 0; } .cc-rotulo { letter-spacing: 0.14em; font-size: var(--cc-fs-xs); } /* ========================================================================== LAS 4 HIJAS VIEJAS DE /servicios/ (2026-08-09) — gotcha 8.40 `agencia-marketing`, `desarrollo-web-proyectos-tecnologicos`, `creatividad` y `diseno` compartían estructura entre sí en el diseño anterior, así que se rediseñaron como UNA sola definición: las cuatro salen del mismo generador y tienen las mismas 4 secciones (hero, qué hacemos, proyectos asociados, cierre). Lo que cambia es el contenido y el color de unidad, nada más. Este bloque es TODO el CSS que hizo falta: tres clases. El resto —el hero con su aurora, las tarjetas, la grilla, la banda, los enlaces con flecha, el color por unidad— ya existía y se reusó tal cual, que era la prueba de que el sistema estaba terminado. Si esta sección hubiera crecido, la conclusión habría sido la contraria. ========================================================================== */ /* El rótulo "SERVICIOS" del hero, que es además el enlace de vuelta a la página madre. El diseño viejo hacía ese retorno con un cuadrado verde flotante (`.arrow-back`, un elemento `code` con `#59F0BA` escrito a mano — ni siquiera el verde vigente) posicionado sobre el contenido. Ahora es una migaja de pan en el sitio donde se busca, y el retorno completo a las 6 hermanas lo da el desplegable del header (8.32), que existe en todas las páginas. */ .cc-migaja a { color: inherit; text-decoration: none; transition: color var(--cc-dur-base) var(--cc-ease-out); } .cc-migaja a:hover { color: var(--cc-unidad, var(--cc-fg-accent)); } /* Fila de chips dentro de una tarjeta. La página de Desarrollo escribía estas listas como prosa con pipes ("VTEX | PrestaShop | Shopify | …"), que es una tabla disfrazada de frase: se lee como si fuera una oración y no lo es. El `
` lo pone Bricks (8.9), así que el margen entre chips va en el chip y no en un `gap` — un `
` no es un flex container y `gap` ahí no haría nada. */ .cc-chips { line-height: 1; } .cc-chips .cc-chip { margin: 0 6px 8px 0; } /* `.cc-chip` nació en el blog con el verde de marca escrito en la regla. Al entrar en una isla de unidad tiene que tomar el color de esa unidad, o la tarjeta de Commerce muestra chips verdes dentro de un borde violeta. Se arregla por ALCANCE y no enumerando (8.25.5): el fallback es EXACTAMENTE el valor anterior, así que el chip del blog —que no está en ninguna isla— no se entera de este cambio. */ .cc-chip { border-color: color-mix(in srgb, var(--cc-unidad, var(--cc-green-500)) 50%, transparent); color: var(--cc-unidad, var(--cc-green-500)); } /* El carrusel de proyectos asociados. Es contenido DINÁMICO heredado (consulta el CPT de la disciplina por su término de `portafolio_categoria`), así que la consulta se conservó intacta: es la única fuente de esos enlaces internos y en un sitio posicionado eso no se tira. Lo que se cambió fue el vestido y tres defectos del original, documentados en el JSON. Las flechas se acotan a 44px por el área de toque (WCAG 2.5.8, la misma medida que el resto del sitio desde la auditoría del 2026-07-29). */ .cc-proyectos .bricks-layout-item img { border-radius: var(--cc-radius-md); object-fit: cover; } /* Las flechas. El nombre de clase es `.swiper-button` + `.bricks-swiper-button-prev` / `-next` (verificado en `includes/elements/post-navigation.php` del theme padre, no supuesto): un selector contra markup inventado es 8.10, y en un carrusel de terceros es la trampa más fácil de pisar. */ .cc-proyectos .swiper-button { min-width: 44px; min-height: 44px; display: flex; align-items: center; justify-content: center; background: rgba(10, 10, 15, 0.72); border: 1px solid var(--cc-border-on-dark); border-radius: var(--cc-radius-pill); color: var(--cc-fg-strong); transition: border-color var(--cc-dur-base) var(--cc-ease-out); } .cc-proyectos .swiper-button:hover { border-color: var(--cc-unidad, var(--cc-fg-accent)); } /* ── El vídeo de marca en la home (2026-08-09) ───────────────────────────────── Va en "NUESTRA HISTORIA" y no en "Somos parte de tu equipo", donde primero se probó con una foto de la oficina: Ricardo la rechazó —*"no tiene sentido una foto de la oficina ahí"*— y tenía razón, un despacho vacío no ilustra cercanía ni delegación. El vídeo, en cambio, ES la marca contando quién es, y el titular de esa sección dice lo mismo con palabras. Con póster y CONTROLES, nunca de fondo: es una pieza narrada de 60s con texto quemado y locución; muda y en bucle pelearía con el titular y no se entendería. `object-fit: contain` y no `cover`: el póster es el logo centrado, y `cover` lo recorta hasta dejar un rectángulo violeta plano en pantallas anchas (medido a 1920). ⚠️ DORMIDA DESDE EL 2026-08-17: el vídeo salió de la portada por decisión de Ricardo («ya es antiguo», R-04), así que hoy no la usa nadie —ni la portada ni la variante de laboratorio—. NO se borra porque lo que vale de este bloque no son las 8 declaraciones sino las tres medidas de arriba, que costaron una sesión y se perderían con él. Si el vídeo vuelve, funciona tal cual; si se decide que no vuelve, esto se va y el póster `cc-video-poster.webp` con él (ojo: el póster SÍ lo sigue usando `tools/lab/`). ========================================================================== */ .cc-home-video { width: 100%; border-radius: var(--cc-radius-lg); overflow: hidden; border: 1px solid var(--cc-border-on-dark); } .cc-home-video video { /* Sin `max-height`: forzaba una caja más ancha que 16:9 y `contain` dejaba dos franjas oscuras a los lados que se leían como un error de encuadre. Dentro del contenedor de 1180 la proporción sola da 662px de alto, que cabe de sobra en una pantalla. */ display: block; width: 100%; height: auto; aspect-ratio: 16 / 9; object-fit: contain; background: #0a0a0f; } /* ========================================================================== ARTE DE CABECERA DE LA FAMILIA /servicios/ (2026-08-10) — gotcha 8.50 Pedido de Ricardo: *"en el original, cada sección tenía imágenes, ¿qué opinas si las colocamos? para que no sean simples tarjetas con información"*. Se fue a ver QUÉ imágenes eran —producción todavía sirve el diseño anterior de estas mismas páginas, así que el inventario sale con un GET— y eran dos familias distintas: · **Las de tarjeta no volvieron.** Once de doce eran banco genérico y varias claramente generadas por IA (pasillos de datacenter, tableros que brillan, ondas de partículas), en magenta y cian, o sea fuera de la paleta. Tres eran CAPTURAS DE PANTALLA con el texto quemado dentro: no se selecciona, no lo lee un lector de pantalla y no cambia en modo claro. Y pesaban: las 5 de `agencia-marketing` suman 3,08 MB contra los 0,19 MB que pesa la página entera. Traerlas habría sido restaurar exactamente el *"muy genérico, muy IA"* del que salió el rediseño. · **Las 4 de cabecera sí.** Un recorte de figura por página —astronauta, futbolista, Van Gogh, stormtrooper— en duotono. Eso no era relleno: era un SISTEMA de una imagen y un color por página, que es la mitad visual del `--cc-u-*` que el rediseño reconstruyó en CSS el 2026-08-04 y dejó sin imagen. Se recuperó el mecanismo, no los archivos: retiñidas al color de SU unidad, sin el grano de escaneo y en WebP. De 665-1015 KB a **15-28 KB** (−97%). ⚠️ SEGUNDA VUELTA, y es la lección. La primera versión colocaba el arte como un recorte a la derecha con los bordes fundidos en el propio archivo. Ricardo: *"no me gustó mucho como se ven las imágenes, como un cuadro difuminado"*. Tenía razón y el diagnóstico es exacto: un rectángulo con los bordes en alfa **sigue leyéndose como un rectángulo**, y encima difuminado. Fundir los bordes no hace que una pieza pertenezca a la composición; solo hace que se note menos que no pertenece. Lo que sí pertenece es lo que propuso él: **la imagen ocupa la sección entera y se apaga al llegar al texto**. Eso cambia tres cosas de la implementación: 1. **El fotograma completo, espejado.** El original trae la figura a la izquierda y el aire a la derecha, que es donde iba el titular en el diseño anterior. Aquí el texto va a la izquierda, así que la imagen se espeja y la figura cae en el lado libre. 2. **El desvanecido pasa del ARCHIVO al CSS.** Antes iba en el alfa del WebP porque el degradado de la sección es un `background-image` y no puede apagar a un hijo. Ahora tiene que ser una **máscara**, y por una razón que el archivo no puede resolver: dónde acaba el texto depende del ancho de la pantalla, y un alfa horneado no se entera. La máscara se declara en `%` del propio elemento, así que acompaña. 3. **La aurora se apaga en estas 4 páginas.** El `::before` violeta al 55% se pintaba ENCIMA del arte —los pseudos van sobre el fondo de la sección— y enturbiaba el color de unidad: un stormtrooper verde bajo un velo violeta no es ni verde ni violeta. La aurora existía para que el hero no fuera un rectángulo plano; con arte ya no hace falta y solo ensucia. ========================================================================== */ .cc-hero__art { position: absolute; inset: 0; width: 100%; height: 100%; /* `contain` y no `cover`, que fue el primer intento: la imagen es 2.66:1 y el hero ronda 2:1, así que `cover` la ampliaba un 20% y recortaba los lados — la figura salía enorme y descabezada. Con `contain` se ve entera y quedan dos bandas arriba y abajo, que **no se ven**: la sombra del duotono ES `--cc-ink-900`, el mismo color que el fondo de la sección, así que la banda y el fondo son el mismo píxel. Es la misma propiedad que hace que la imagen no necesite marco. */ object-fit: contain; object-position: right center; z-index: 0; /* los hijos de .cc-aurora van a z-index 1 */ pointer-events: none; /* decorativa: no roba el clic al CTA */ /* El apagado. Los porcentajes son del elemento, o sea del ancho de la pantalla: a 1440 el texto acaba en el 66% y a 1920 en el 62%, así que un corte fijo en px se quedaría corto en una y largo en la otra. 0-30% transparente cubre la columna de lectura con margen; 30-72% es la transición; del 72% en adelante la imagen va entera. */ -webkit-mask-image: linear-gradient(90deg, transparent 0%, transparent 30%, rgba(0,0,0,.55) 52%, #000 72%); mask-image: linear-gradient(90deg, transparent 0%, transparent 30%, rgba(0,0,0,.55) 52%, #000 72%); } /* Sin soporte de máscara la imagen quedaría entera bajo el titular. No se deja: el texto es blanco sobre un duotono con luces del color de unidad y el contraste no está medido ahí. Es la misma regla que 8.23 — si la red de seguridad no puede garantizar el estado bueno, que retire el efecto en vez de dejar algo a medias. */ @supports not ((-webkit-mask-image: linear-gradient(#000, #000)) or (mask-image: linear-gradient(#000, #000))) { .cc-hero__art { display: none; } } /* Con arte, la aurora sobra: se pintaba encima y enturbiaba el color de unidad. */ .cc-hero-art-on::before, .cc-hero-art-on::after { display: none; } /* Bajo 992px el hero es una sola columna y el texto ocupa TODO el ancho, así que una máscara horizontal no tiene dónde apagarse: dejaría la figura detrás del titular. Se cambia el eje —la imagen se apaga hacia ARRIBA, donde está el texto, y se ve entera abajo— y la sección gana alto para que quepan las dos cosas. No se oculta: esconderla en móvil dejaría a la mitad del tráfico con la página que Ricardo pidió cambiar. */ @media (max-width: 991px) { .cc-hero__art { object-position: center bottom; -webkit-mask-image: linear-gradient(180deg, transparent 0%, transparent 42%, rgba(0,0,0,.5) 62%, #000 82%); mask-image: linear-gradient(180deg, transparent 0%, transparent 42%, rgba(0,0,0,.5) 62%, #000 82%); } .cc-hero-art-on { padding-bottom: calc(var(--cc-sec-md) + 120px); } } /* ⚠️ MODO CLARO (8.24). El duotono está construido sobre `--cc-ink-900`, que es constante: no cambia con el tema. Eso en oscuro es justo lo que se quiere —las sombras de la imagen SON el fondo de la sección—, pero en claro la mitad derecha del hero se volvería una mancha oscura contra el papel. La salida no inventa nada: el sistema ya decidió el 2026-08-03 que ciertas piezas siguen oscuras en modo claro (la banda violeta, el cierre, el footer, la caja CTA de la nota — 8.25.5). Aquí el hero entero es esa isla: el fondo de la sección se queda en tinta y el arte sigue a sangre encima, así que la transición imagen→fondo vuelve a ser invisible, que es lo que la hacía funcionar en oscuro. Y el texto no hace falta arreglarlo a mano: la sección lleva además `cc-isla-oscura`, que es el mecanismo que ya existe desde el 2026-08-03 y devuelve de una vez los tokens de texto Y los de superficie a sus valores sobre oscuro. Escribir aquí un `color:` por elemento sería reimplementar eso peor — y es exactamente el bug de 8.25.8, donde la primera versión de la isla devolvía los colores de texto pero no los de superficie. */ /* ⚠️ Y los ids no son decoración, son ESPECIFICIDAD. `html[data-theme="light"] .cc-hero-art-on` pesa (0,2,0) y el fondo de la sección lo pone Bricks desde el ajuste `_background` como `#brxe-sds001{background-color:var(--bricks-color-xyartc)}`, que pesa (1,0,0) — y esa variable de paleta SÍ la voltea el modo claro, así que la sección se iba a blanco con el texto ya en blanco: titular invisible. Es 8.25.8 otra vez, la isla devolviendo los colores de TEXTO y no los de SUPERFICIE, y es 8.3: la paleta de Bricks vive en la BD y gana por id. Un `:is()` toma la especificidad de su argumento más específico, así que meter los 4 ids sube esta regla a (1,2,0) y pasa por encima sin `!important`. Es el mismo recurso que ya usa la lista de islas oscuras de más arriba. Si alguien renombra una sección esto deja de aplicar — por eso `servicios.mjs` lo mide en claro, para que no sea silencioso (8.42). */ html[data-theme="light"] :is(#brxe-smk001, #brxe-sdv001, #brxe-scr001, #brxe-sds001) { background-color: var(--cc-ink-900); } /* ── Imagen de tarjeta de servicio (2026-08-10) ─────────────────────────────── Segunda mitad del pedido de Ricardo: *"quiero que pongas igualmente las imágenes, aunque sean IA o recortes. Me gusta como se ve en la página original, pero nosotros démosle el toque más moderno"*. O sea vuelven las 11 de tarjeta que la primera pasada había descartado por genéricas, y la decisión de qué hacer con ellas se mueve de "cuáles" a "cómo". El "toque moderno" son cuatro cosas medibles, ninguna de gusto: 1. **Duotono al color de su unidad**, igual que el arte de cabecera. Es lo que convierte una colección de stock de bancos distintos —magenta, cian, beige, fucsia— en una serie. Con una rampa más suave que la del hero: ahí la escena estorba y se hunde, aquí la escena ES el motivo. 2. **Exposición nivelada**. Tres de los trece están fotografiados sobre blanco y pesaban el doble que sus vecinas en la grilla. Teñir del mismo color no iguala lo que el ojo lee primero, que es el brillo. 3. **Todas a 16:9**. Venían en 1.89:1, 4:3, 1.76:1 y 1.33:1. 4. **A sangre en la tarjeta**, no encajadas dentro del relleno. Una imagen con aire alrededor dentro de una caja con borde se lee como dos cajas; pegada a los cantos superiores es la tarjeta la que tiene una imagen. Peso: las 13 juntas ocupan **375 KB**. Los originales PNG de las mismas 13 sumaban **6,1 MB**, y `campanas-en-meta` sola pesaba 1,3 MB por una caja de 370px. El radio resta 1px al del contenedor: el borde de la tarjeta ocupa ese pixel y sin la resta asoma una uña de fondo entre la imagen y el borde en las dos esquinas de arriba. */ .cc-svc-card__media { display: block; /* Cancela el relleno de la tarjeta (34px 30px) para llegar a los cantos. ⚠️ El `max-width: none` no es opcional: el reset del theme lleva `img{max-width:100%}` y ese 100% es el ancho de CONTENIDO de la tarjeta (318px), así que recortaba los 378 de vuelta a 318 — los márgenes negativos sí aplicaban y la imagen quedaba pegada a la izquierda y a 60px del canto derecho. Se ve en una captura y no en el CSS. */ width: calc(100% + 60px); max-width: none; margin: -34px -30px 6px; aspect-ratio: 16 / 9; object-fit: cover; /* ⚠️ EL RADIO VUELVE A LA IMAGEN, Y NO SE RECORTA DESDE LA TARJETA. Costó tres intentos (Ricardo, 2026-08-25: *«las esquinas de las imágenes se ven raras»*), y los dos que fallaron enseñan más que el que funcionó: · Intento 1 — subir el radio al pleno. FALSO: el margen negativo de arriba cancela el RELLENO, no el borde, así que la imagen queda 1px DENTRO por cada lado (medido: tarjeta 130.0→410.0, imagen 131.0→409.0). Con radio 18 en un hueco de 17 se recorta de más y asoma el fondo de la tarjeta: en claro, un halo blanco sobre foto oscura. · Intento 2 — `overflow: hidden` en la tarjeta y radio 0 en la imagen, para tener UNA sola curva. Suena bien y **se ve peor**: el recorte redondeado de un elemento compuesto —una imagen con `object-fit`— Chromium lo resuelve con una máscara SIN SUAVIZAR, mientras el borde sí va suavizado. Entre la curva limpia del borde y la dentada del recorte aparece el fondo en escalones. Comparado a dpr 5 sobre las cuatro tarjetas: el escalón estaba en las cuatro, idéntico — que es lo que delató que no era la foto, porque cuatro fotos distintas no comparten artefacto. La forma que sí funciona es la original: el radio en la PROPIA imagen, que Chromium sí suaviza, y `calc(… - 1px)` porque la imagen vive en la caja de relleno. Que quede escrito: aquí el instinto de «pon overflow hidden y olvídate» produce un defecto visible, y solo se ve mirando a 5× — a tamaño natural pasa por «se ve raro». */ border-radius: calc(var(--cc-radius-lg) - 1px) calc(var(--cc-radius-lg) - 1px) 0 0; } /* ========================================================================== EL CONTROL DE PAUSA, EN REPOSO (2026-08-10) Ricardo: *"quita los símbolos de pause y reanudar del homepage: carrusel y el texto que cambia en el principio, que quede en bucle nomás"*. Y visualmente tiene razón: dos glifos de "⏸" sueltos en una portada son ruido de interfaz, no diseño — nadie los busca y ahí están, compitiendo con el CTA del hero y con los logos de marca. ⚠️ AHORA ES UNO SOLO: «el texto que cambia en el principio» dejó de cambiar el 2026-08-23 —el hero pasó a un mensaje fijo— así que su pausa se fue con él y aquí queda la del carrusel de marcas. La regla se mantiene igual de necesaria para esa. ⚠️ Pero **borrarlo no se puede**, y conviene que quede escrito por qué. El carrusel se mueve solo y dura más de 5 segundos, así que cae bajo **WCAG 2.2.2 (Pause, Stop, Hide), nivel A** — el mismo nivel que "tener texto alternativo". El criterio no pide un botón bonito: pide que exista **un mecanismo**. Y las pausas por `mouseenter` no cuentan, porque quien navega con teclado o con lector de pantalla nunca pasa el puntero por encima. La salida es la que usan los sitios grandes con carruseles: **el control existe siempre y solo se VE cuando hace falta**. Aparece al pasar el puntero por su carrusel o al entrar el foco con Tab, y el resto del tiempo es invisible. Lo que NO se hace, y es la trampa fácil: `display:none` o `visibility:hidden`. Las dos sacan el botón del orden de tabulación, o sea eliminan el mecanismo de verdad y dejarían el sitio incumpliendo el criterio con la apariencia de cumplirlo. Aquí solo baja la opacidad, que no quita presencia (es 8.14 al derecho: `opacity:0` NO saca del tab, y eso, que allí era el bug, aquí es justo la propiedad que se necesita). El `:focus-visible` propio del botón está en la lista a propósito: quien llega con Tab necesita verlo en cuanto lo enfoca, aunque el puntero esté en la otra punta. */ .cc-hero__pausa, .cc-marcas__pausa { opacity: 0; transition: opacity var(--cc-dur-base) var(--cc-ease-out); } /* El ancestro es el REAL, comprobado en el DOM y no supuesto: `.cc-marcas`, que es un contenedor propio. Escribirlo contra un `.cc-marcas-wrap` que no existe habría dejado el botón invisible para siempre — mecanismo eliminado de hecho, que es peor que no haber tocado nada. (Aquí acompañaba el del hero, cuyo ancestro tenía que ser su SECCIÓN `#brxe-sec001` porque el JS lo inyectaba dentro de la fila de dots. Se fue con el carrusel el 2026-08-23.) */ #brxe-sec001:hover .cc-hero__pausa, #brxe-sec001:focus-within .cc-hero__pausa, .cc-marcas:hover .cc-marcas__pausa, .cc-marcas:focus-within .cc-marcas__pausa { opacity: 1; } /* Quien pidió menos movimiento tiene los carruseles ya detenidos, así que el control no tiene nada que pausar: se queda visible para poder REANUDAR si quiere. */ @media (prefers-reduced-motion: reduce) { .cc-hero__pausa, .cc-marcas__pausa { opacity: 1; } } /* ========================================================================== FOOTER — LA RETÍCULA (2026-08-10) Ricardo: *"el footer no sé si me gusta mucho, está como todo muy acoplado"*. "Acoplado" es exacto y era medible. Lo que había: · **Tres columnas de `auto-fit` en 1180px**, o sea el ancho lo repartía el contenido: la de marca amontonaba cuatro cosas distintas —logo, claim, redes y el sello de Google Premier— en 272px de alto, mientras a la derecha de la columna de navegación quedaban ~260px vacíos. Todo el peso a la izquierda y aire muerto a la derecha. · **Una columna sin rótulo.** "NAVEGACIÓN" iba en versalitas; la dirección, el teléfono y el email no llevaban ninguno, así que esa columna se leía como texto suelto caído en medio del footer. · **Dos focos peleando.** El email era un botón violeta saturado —el único color pleno del footer— a 40px del sello blanco de Google. Dos centros de atención en la misma banda, ninguno gana. · **Entropía sin motivo:** 4 tamaños, **5 interlineados**, 4 pesos y 3 colores para 14 enlaces. Ahora son **cuatro columnas con rótulo** y una fila de cierre: marca (1.5fr) · Servicios · Compañía · Contacto (1.2fr) Tres decisiones que no son de gusto: 1. **La columna de Servicios es nueva y es la que llena el ancho.** No es relleno: pone **7 enlaces internos a las páginas comerciales en todas las páginas del sitio**, que es de lo más barato que se puede hacer por el posicionamiento de un sitio que ya rankea. El hueco muerto se cierra con contenido útil, no con aire. 2. **El sello de Google baja a la fila de cierre.** Es una credencial, no navegación: arriba obligaba a la columna de marca a medir el doble que sus vecinas y era lo primero que veías del footer. Abajo, junto al copyright, está donde se buscan las credenciales — y de paso la columna de marca queda con su altura natural. 3. **El email deja de ser botón.** Como enlace de texto la columna se lee igual que las otras tres y el footer deja de tener dos centros. El correo sigue siendo `mailto:` y sigue siendo el más destacado de su columna, por color, no por caja. La primera fila NO usa `auto-fit`: con `auto-fit` el ancho de cada columna depende de cuánto texto tenga, que es la versión de grilla del `space-between` que 8.27 ya sacó de aquí. Cuatro fracciones explícitas es lo que hace que la retícula sea una decisión. ========================================================================== */ .cc-foot__grid { display: grid; grid-template-columns: 1.5fr 1fr 1fr 1.2fr; gap: clamp(28px, 4vw, 56px); align-items: start; } /* Las 3 columnas de enlaces comparten UNA definición: un solo tamaño, un solo interlineado y un solo color. Es el trinquete de entropía de `ux.mjs` aplicado a mano — cuatro tamaños y cinco interlineados en 14 enlaces no los distingue nadie, solo hacen que el bloque se lea sucio. */ .cc-foot__grid > .brxe-block > .brxe-text:not(.cc-social):not(.cc-badge-google-wrap):not(.cc-foot__titulo), .cc-foot__grid > .brxe-block > .brxe-text:not(.cc-social) > p { /* UN tamaño y UN interlineado para las tres columnas de enlaces y la de contacto. La versión anterior tenía 4 tamaños y 5 interlineados para 14 enlaces: nadie distingue 14 de 15px, solo hacen que el bloque se lea sucio. El interlineado va en ems y no en `2` a secas para que no lo multiplique cada tamaño heredado — así salió el primer intento, con 6 interlineados en vez de uno. */ font-size: var(--cc-fs-sm); /* El interlineado es 1.6 y NO un valor propio, y las dos vueltas que costó valen como regla. Primero fue `1.9em`: como el footer es global y cada nodo heredaba su tamaño, salían seis valores computados distintos y los trinquetes de entropía de `ux.mjs` subieron en las TRES páginas a la vez (home 11→12, blog 4→5, servicios 7→8). Después `30px`: un solo valor, sí, pero **uno NUEVO** — y el trinquete no cuenta cuántos usa el footer, cuenta cuántos hay en la página. 1.6 es el que ya usan 67 nodos de la home. Con el tamaño forzado arriba da un único computado y, sobre todo, **no estrena ninguno**. La lección: en un componente global, un valor tipográfico nuevo no cuesta lo que ocupa, cuesta en todas las páginas. */ line-height: 1.6; margin: 0; } /* El correo: el elemento con más peso de su columna, con color en vez de caja. */ .cc-foot__mail a { color: var(--cc-fg-accent); font-weight: var(--cc-fw-semibold); text-decoration: none; border-bottom: 1px solid color-mix(in srgb, var(--cc-fg-accent) 40%, transparent); transition: border-color var(--cc-dur-base) var(--cc-ease-out); } .cc-foot__mail a:hover { border-bottom-color: var(--cc-fg-accent); } /* La fila de cierre: copyright a la izquierda, credencial a la derecha. */ .cc-foot__cierre { display: flex; /* `row` explícito: el elemento `block` de Bricks trae `flex-direction: column` y sobrevive a que esta clase declare `display:flex` — el copyright y el sello salían apilados y centrados. Es el primo del 8.33 que acaba de morder en la grilla de unidades: heredar la dirección del componente base y creer que la clase la manda. */ flex-direction: row; align-items: center; justify-content: space-between; gap: 24px; flex-wrap: wrap; } .cc-foot__cierre .cc-badge-google-wrap { margin-top: 0; } @media (max-width: 991px) { .cc-foot__grid { grid-template-columns: 1fr 1fr; } } @media (max-width: 575px) { .cc-foot__grid { grid-template-columns: 1fr; } .cc-foot__cierre { justify-content: flex-start; } } /* ========================================================================== FORMULARIOS (2026-08-10) La sección de cierre de la home sirve el formulario de contacto real —el mismo `[gravityform id="1"]` de /contacto/— desde un elemento `shortcode` de Bricks. Antes tenía una caja falsa y una nota de desarrollo escritas dentro de home.json, o sea versionadas; el detalle está en el encabezado de `functions.php`. ⚠️ LO QUE FALTA POR VER, y conviene que esté escrito: Gravity Forms es de licencia y NO está en el entorno local, así que el aspecto del formulario dentro de esta sección **no se ha podido verificar midiendo**. Lo de abajo es lo defendible sin verlo —heredar los colores de la isla y las escalas del sistema— y necesita una pasada visual en cuanto exista staging (docs/pendientes.md). ========================================================================== */ /* El marcador que se ve SOLO en local, donde el plugin no está. Deliberadamente sobrio y sin aire de componente: tiene que leerse como "aquí falta una pieza del entorno" y no como parte del diseño. */ .cc-form-ausente { margin: 0; padding: 18px 20px; border: 1px dashed var(--cc-border-soft); border-radius: var(--cc-radius-md); color: var(--cc-fg-muted); font-size: 14px; line-height: 1.6; } /* ⚠️ AQUÍ HABÍA 40 LÍNEAS QUE VESTÍAN ESTE FORMULARIO A MANO, y se retiraron el 2026-08-27 al meter la portada en el alcance de 8.113 (`.cc-home`, al final de este archivo). No estaban mal escritas: estaban escritas A CIEGAS —su propio comentario de arriba lo decía— y por eso les faltaba justo lo que no se puede adivinar sin ver el formulario real. Lo medido en el staging antes de retirarlas: input[type="url"] no estaba en la lista → 38px de alto contra 48 del resto el botón 107x38 y menta #ADEFDB → bajo el mínimo táctil de 44 las casillas 20x20 → bajo el 24x24 de WCAG 2.5.8 el fondo de campo lo pintaba la BD, no esto: (0,3,1) pierde contra (1,0,0) Mantenerlas además de 8.113 sería tener DOS sitios donde vive la misma decisión, que es lo que §5 pide no hacer. La única que sobrevive es la de abajo, y no describe el formulario sino su ISLA: `#brxe-sec127` es oscura en los dos temas, así que lo que 8.113 voltea con el tema tiene que quedarse quieto aquí. Se escribe SOLO lo que la isla no cubría ya (bloque del modo claro, arriba en este archivo). */ .cc-form-cierre .cc-form-ausente { color: var(--cc-fg-on-dark); } /* ========================================================================== RED DE ANCHO PARA LAS PÁGINAS DEL DISEÑO ANTERIOR (A-03, 2026-08-10) `/agencia-vtex-partner/` desbordaba 332px a 768 y 22px a 390. La auditoría localizó los dos orígenes midiendo, y ninguno era el carrusel —su `splide__track` ya recorta—: eran dos anchos escritos en PÍXELES que no caben en pantallas estrechas. · un `.brxe-container` con `width: 1100px` → 1100 − 768 = los 332px exactos. Es el gotcha 8.7 en su forma literal, sobreviviendo en una página que el rediseño no tocó. · el `h3.title` de un acordeón con `width: 363px` dentro de un padre de 310. Se arregla con `max-width` y no tocando el `width`, a propósito: son propiedades distintas, así que esto NO pelea especificidad con la regla por id que emite Bricks —le ganaría un `#brxe-xxx` cualquiera— y encima es inofensivo donde el ancho ya cabe. Y va en CSS versionado y no en el builder porque esas páginas son del diseño viejo: el equipo las sigue editando y un cambio suyo en la BD se perdería. ⚠️ Importa más desde el 2026-08-10: el mega-menú convirtió Agencia VTEX en uno de los siete destinos del header, o sea que ahora se llega a esa página desde las 32. ========================================================================== */ /* ⚠️ Dos correcciones que costó llegar a ellas, y las dos importan: 1. `#brx-content` no es decorativo. Bricks emite `#brxe-jrjcds { max-width: 1133px }`, una regla por ID (1,0,0) que le gana a cualquier clase suelta, así que la primera versión —`.brxe-container` a secas— no movió ni un píxel. Con el contenedor de contenido delante queda (1,1,0) y manda. Es 8.1 otra vez. 2. Y va acotada a ESTA PÁGINA, no a todo el sitio. La segunda versión aplicaba `max-width: 100%` a los containers de todas las páginas, y al ganarle también a los max-width legítimos ensanchó un contenedor de la PORTADA: el carrusel de marcas pasó a medir 1324px de ventana contra una pista de 1300 y **empezó a mostrar una marca dos veces**. Lo cazó `home.mjs` en la misma corrida. Una red de seguridad que se aplica donde no hace falta deja de ser una red y pasa a ser un cambio de diseño. El id de página es estable entre dumps —los ids vienen de producción, ver el paso 7 de `post-import.php`—, así que `page-id-7962` identifica a /agencia-vtex-partner/ en cualquier entorno. Si mañana otra página legacy desborda, se añade su id aquí. */ body.page-id-7962 #brx-content .brxe-container { max-width: 100%; } #brx-content .brxe-accordion .accordion-title .title { max-width: 100%; /* ⚠️ `max-width` NO basta, y por poco se da esto por arreglado: ciñe la CAJA pero no el texto. El título "¿Qué integraciones cubren (ERP/OMS/pagos…" no tiene dónde partir —las barras no son puntos de corte—, así que su min-content seguía midiendo 240px en un hueco de 161 y el desborde se mantenía intacto con la caja "correcta". Es 8.31, y la lección de instrumento es que medir el ancho del elemento decía que sí mientras la página seguía moviéndose de lado: hay que medir el `scrollWidth` del documento, que es lo que ve quien la usa. */ overflow-wrap: anywhere; } /* ========================================================================== DOS DESBORDES SUELTOS DEL DISEÑO ANTERIOR (A-08, 2026-08-10) Acotados por id de página por la lección de A-03: una red de ancho aplicada donde no hace falta deja de ser una red y pasa a ser un cambio de diseño. Los ids de página vienen de producción y son estables entre dumps (paso 7 de post-import.php). ========================================================================== */ /* /auditoria-gratis/ (8316). El primer diagnóstico —"una imagen más ancha que su hueco"— era FALSO, y `max-width: 100%` no movió nada: la imagen mide exactamente lo que su padre. Lo que la saca de la página es un DESPLAZAMIENTO: lleva `position: relative; left: 54%` con `transform: translateX(-50%)`, el truco clásico para centrar algo más ancho que su contenedor. Mientras la imagen sobresale por los dos lados el 4% de diferencia no se nota; cuando deja de sobresalir —en móvil— ese 4% se convierte en 16px de desborde limpio (medido: left=210.59, transform=-195). Se anula el desplazamiento solo por debajo de 768, donde ya no hay nada que centrar. Arriba se deja intacto: ahí el encuadre es deliberado y funciona. */ body.page-id-8316 #brx-content img { max-width: 100%; height: auto; } @media (max-width: 767px) { body.page-id-8316 #brx-content .brxe-image { position: static; transform: none; } } /* /politicas-de-privacidad/ (7904): dos enlaces cuyo texto ES una URL larga. Una URL no tiene espacios, así que su min-content es toda la cadena y empuja 49px fuera a 390. Va sobre los enlaces y no sobre todo el texto a propósito: `anywhere` en un párrafo normal parte palabras que sí tenían dónde cortar y se lee peor. */ body.page-id-7904 #brx-content a { overflow-wrap: anywhere; } /* ========================================================================== EL SUELO DE LA PÁGINA ES DEL TEMA, TAMBIÉN EN LAS PÁGINAS SIN REDISEÑAR (2026-08-10, pedido de Ricardo: "el navbar se ve mal en Agencia SEO e Influencer Marketing" + "estandarizar esas páginas al tema") El header del rediseño es translúcido al 72% con `backdrop-filter`, así que NO tiene color propio: toma el de lo que hay detrás. En 7 de las 12 páginas medidas el suelo ya es `rgb(10,10,15)` y el header se lee oscuro; en 5 el `body` sigue en BLANCO —herencia del diseño anterior— y ahí el mismo header se compone a un gris lavado. No es un fallo del header: es que debajo hay otro sitio. Medido el 2026-08-10 · suelo blanco en: /servicios/agencia-seo/, /servicios/influencer-marketing/, /newsletters/, /ecommerce-hub-2026/, /geo-aeo/. Se declara con el TOKEN y no con un hex, así que el modo claro —donde `--cc-bg` es papel— sigue funcionando sin una sola excepción. Y va sobre `html` y `body` a la vez porque el reparto varía por página: unas pintan en `html` y otras en `body`. */ /* ⚠️ EL SUELO Y EL TEXTO SON UN PAR, Y HASTA EL 2026-08-17 SOLO SE PINTABA EL SUELO. La regla de abajo pintó de oscuro las 30 páginas, incluidas las 4 LEGALES —cookies, aviso legal, descargo, y el índice de privacidad—, que NO están construidas con Bricks: su contenido sale del editor, así que su texto se quedó en el `#363636` por defecto del theme padre. Fondo #0A0A0F con texto #363636 es **1.63:1**, o sea la política de cookies entera dejó de leerse (56 nodos), y el aviso legal con ella. Nadie lo vio durante una semana por la razón de siempre: ninguna suite mira esas páginas. `a11y.mjs` recorría 5 y `tema.mjs` las 9 rediseñadas; las legales no están en ninguna lista, así que su contraste no falló — no se medía (8.53). Es además un fallo que NO se puede ver en producción, porque allí `assets/css/` no existe: vive solo en lo que este repo está a punto de desplegar. Gotcha 8.67. El arreglo es la otra mitad de la misma decisión, no una excepción: quien fija el fondo de la página fija su color de texto. Va con el TOKEN, así que el modo claro sigue saliendo gratis. Y hereda, o sea solo alcanza a lo que no declara color propio: los elementos de Bricks traen el suyo desde la BD y no se tocan. Medido en las 24 páginas: arregla 61 nodos y no empeora ni uno. */ html, body.wp-singular, body.home { background-color: var(--cc-bg); color: var(--cc-fg); } /* Los términos de la auditoría (8596) son la excepción, y por eso van aparte: sí están hechos con Bricks y su negro está ESCRITO EN EL BUILDER, o sea vive en la BD y la herencia de arriba no lo alcanza. Son exactamente DOS elementos —el `h1` y el bloque de texto— y de ellos hereda el resto de la página: 37 nodos a 1.06:1 con dos selectores. Se anula desde el theme y no desde el builder por §10 (un arreglo en la BD se pierde con el próximo volcado), y queda anotado en la tabla de `pendientes.md` de decisiones del builder que el theme está anulando: lo correcto es quitar ese color desde Bricks, y mientras no se haga, los dos dicen cosas distintas. */ body.page-id-8596 #brxe-uhnihz, body.page-id-8596 #brxe-vfrafq { color: var(--cc-fg); } /* Y sus DOS enlaces, que declaran el negro por su cuenta y por tanto tampoco heredan: la URL de las bases y el correo de contacto. NO se igualan al texto —eso los dejaría indistinguibles, que es WCAG 1.4.1 nivel A y el mismo fallo que el blog ya corrigió (`.cc-post__content a[href]`)—: van al token de enlace, que voltea con el tema, y conservan el subrayado como distintivo. Los cazó el chequeo nuevo después de arreglar el bloque de texto: 2 nodos a 1.06:1 que el arreglo del párrafo no alcanzaba. */ body.page-id-8596 #brxe-vfrafq a[href] { color: var(--cc-fg-link); text-decoration: underline; text-decoration-thickness: 1px; text-underline-offset: 3px; } /* Dos etiquetas heredadas que quedaban por debajo de AA, destapadas al poner el suelo del tema (2026-08-10). Las dos son el MISMO error y el sistema ya tiene su regla: sobre un acento claro el texto va en TINTA, no en blanco. · /servicios/influencer-marketing/ — blanco sobre el violeta viejo #6C6CFF: 4.02:1 · /portafolio/ — el filtro activo, blanco sobre el verde #08AA7A: 2.98:1 No se toca el color de fondo: cambiarlo sería rediseñar la pieza, y estas dos páginas no están rediseñadas. Se cambia solo el color del texto, que es lo que falla. */ body.page-id-24 #brx-content .brxe-posts li.active { color: var(--cc-ink-900); } /* Los botones violetas de /servicios/influencer-marketing/ (8763): blanco sobre #6C6CFF da 4.02:1 y el mínimo es 4.5. Se tiñe el BOTÓN y no todos los `strong` de la página — la primera versión hizo eso y volteó también los que van sobre fondo oscuro, pasando de 4 fallos a 12. Sobre un acento claro, tinta; es la misma regla del sistema. */ body.page-id-8763 #brx-content .bricks-button.bricks-background-primary, body.page-id-8763 #brxe-fzyonm { color: var(--cc-ink-900); } /* ⚠️ Y NO `.bricks-button` a secas: la página tiene además un botón sobre fondo oscuro, y teñirlo de tinta lo dejaba en 1:1 — cambiar un fallo de 4.02 por uno de 1.0 es empeorar midiendo mal. Se listan los que llevan el fondo claro. */ /* ========================================================================== TEMA ESTÁNDAR EN LAS 5 PÁGINAS QUE NO SE VAN A REDISEÑAR (2026-08-10) Pedido de Ricardo. La lista de páginas vive en `ccd_paths_tema_estandar()` y llega aquí como la clase `.cc-tema-estandar` en el body — una sola lista, ver 8.42. La regla del encargo es "estandarizar, NO rediseñar": se toca la capa de sistema de diseño —familia, escala de radios, escala de duraciones, forma de los botones— y NO la maqueta, la copia, las imágenes ni el relleno de los componentes. Por eso abajo no hay ni un `padding`, ni un `margin`, ni un `width`: nada que mueva una caja de sitio. El punto de partida, medido el 2026-08-10 contra la home (que es el tema): · 4 de 5 páginas caían a `-apple-system` en parte de su texto · agencia-seo: 14 tamaños y 21 interlineados (la home: 12 y 11) · radios fuera de escala: 19px, 20px, 25px, 13px, 12.6px, 18.6px · duraciones fuera de escala: 0.2s, 0.3s, 0.5s · botones: 2 definiciones por página, contra UNA en la home ========================================================================== */ /* 1. LA TIPOGRAFÍA. Es lo que más dice "esto es de otro sitio", y el fallo es el mismo que ya se documentó para el footer en style.css: el child theme no declaraba familia, así que todo elemento de Bricks que no la fijara en sus settings caía al font del navegador. Se declara una vez en la raíz y lo que ya dice Montserrat no cambia. */ body.cc-tema-estandar { font-family: var(--cc-font-sans); } /* 1b. EL SUELO, y SOLO en el 404 y en la búsqueda (2026-08-26, gotcha 8.105). En las páginas de la lista el fondo oscuro ya lo pinta Bricks desde sus estilos globales, así que aquí no hacía falta y por eso no estaba. El 404 y la búsqueda NO son páginas —son estados de la consulta—, ese estilo global no las alcanza y se quedaban con el `body` en blanco sobre el `html` de #0A0A0F: se veía una banda gris arriba, un bloque claro en medio y el pie negro debajo, en la misma pantalla. Se pintan con los TOKENS y no con el hex, que es lo que hace que el modo claro siga funcionando aquí sin una segunda regla: `--cc-bg` y `--cc-fg` ya se voltean. Va acotado con `:is()` a esos dos estados para no tocar el resto de la lista. */ body.cc-tema-estandar:is(.error404, .search) { background-color: var(--cc-bg); color: var(--cc-fg); } /* 1c. LA BÚSQUEDA SIN RESULTADOS, que era un callejón sin salida (2026-08-26, 8.105). Bricks pinta ahí un `
No se encontró nada.
` y nada más: `#brx-content` medía 67,8px, sin un enlace ni un campo. Y es justo donde lleva el buscador del 404 —la única salida del 404—, así que quien se perdía terminaba en una página vacía. El bloque lo emite `search.php` del child theme; esto lo viste. Todo sale de los tokens, así que el modo claro se voltea solo y no hace falta una segunda regla. */ .cc-sin-resultados { max-width: 720px; margin-inline: auto; padding-block: var(--cc-space-11) var(--cc-space-12); /* A 390px `#brx-content` no trae relleno propio (medido: 0px), así que sin esto el campo de búsqueda va de borde a borde de la pantalla. */ padding-inline: var(--cc-space-5); text-align: center; } .cc-sin-resultados__titulo { font-family: var(--cc-font-display); font-size: var(--cc-fs-d3); font-weight: var(--cc-fw-bold); line-height: var(--cc-lh-snug); letter-spacing: var(--cc-tracking-tight); color: var(--cc-fg-strong); margin: 0 0 var(--cc-space-5); /* El término lo escribe el visitante: una palabra larga sin espacios no puede empujar la caja y sacar la página de cuadro (8.7). */ overflow-wrap: anywhere; } .cc-sin-resultados__texto { font-size: var(--cc-fs-lead); line-height: var(--cc-lh-lead); color: var(--cc-fg-read); margin: 0 0 var(--cc-space-8); } .cc-sin-resultados__form { display: flex; /* ⚠️ `width:100%` NO es decorativo: `.brxe-container` es un flex column con `align-items:center`, así que sin esto el formulario se encoge a su contenido y queda descentrado respecto del titular. Es 8.101 tal cual: el ancho no lo decide el `max-width` del padre, lo decide el flex. Medido: 422px de 720. */ width: 100%; gap: var(--cc-space-3); /* Se envuelve en vez de encogerse: a 320px un campo y un botón en la misma fila dejan el campo en ~140px, que no da para leer lo que uno escribió. */ flex-wrap: wrap; justify-content: center; margin-bottom: var(--cc-space-9); } .cc-sin-resultados__form input[type="search"] { flex: 1 1 260px; min-width: 0; padding: var(--cc-space-3) var(--cc-space-5); font-family: inherit; font-size: var(--cc-fs-base); color: var(--cc-fg); background-color: transparent; border: 1px solid var(--cc-border); border-radius: var(--cc-radius-pill); transition: border-color var(--cc-dur-fast) var(--cc-ease); } .cc-sin-resultados__form input[type="search"]::placeholder { color: var(--cc-fg-muted); } .cc-sin-resultados__form input[type="search"]:focus-visible { outline: 2px solid var(--cc-fg-accent); outline-offset: 2px; border-color: var(--cc-fg-accent); } .cc-sin-resultados__form button { /* 44x44 mínimo por WCAG 2.5.8: el relleno vertical sale de ahí, no del gusto. */ min-height: 44px; padding: var(--cc-space-3) var(--cc-space-7); font-family: inherit; font-size: var(--cc-fs-sm); font-weight: var(--cc-fw-semibold); color: var(--cc-ink-900); background-color: var(--cc-fg-accent); border: 0; border-radius: var(--cc-radius-pill); cursor: pointer; transition: background-color var(--cc-dur-fast) var(--cc-ease); } .cc-sin-resultados__form button:hover { background-color: var(--cc-green-700, #08AA7A); } .cc-sin-resultados__salidas { display: flex; /* Mismo motivo que el formulario (8.101): sin ancho propio se encoge a su contenido y `justify-content:center` no centra nada. Medido a 390px: 299px pegados a la izquierda, con el titular centrado justo encima. */ width: 100%; flex-wrap: wrap; gap: var(--cc-space-3) var(--cc-space-6); justify-content: center; } .cc-sin-resultados__salidas a { /* Subrayado, no solo color: WCAG 1.4.1, la misma regla que los enlaces en prosa. */ display: inline-flex; align-items: center; min-height: 44px; padding-inline: var(--cc-space-2); font-size: var(--cc-fs-base); font-weight: var(--cc-fw-medium); color: var(--cc-fg-link); text-decoration: underline; text-underline-offset: 4px; text-decoration-thickness: 1px; transition: text-decoration-thickness var(--cc-dur-fast) var(--cc-ease); } .cc-sin-resultados__salidas a:hover { text-decoration-thickness: 2px; } /* 2. LOS RADIOS, a la escala de cc-tokens.css. La diferencia entre 19 y 18 no la ve nadie de a uno; lo que sí se ve es un sitio donde cada componente redondea distinto. Se mapea al valor de la escala más cercano, sin inventar ninguno nuevo. */ body.cc-tema-estandar #brx-content :is(.bricks-button, .brxe-button) { border-radius: var(--cc-radius-pill, 999px); } body.cc-tema-estandar #brx-content :is(.brxe-image, .brxe-block, .brxe-div, img) { border-radius: inherit; } /* 3. LOS BOTONES. La home tiene UNA definición y estas páginas dos cada una, con tamaños de 17.25px que no existen en ninguna escala. Se unifican forma, tamaño y peso —píldora, 15px, 700, la misma transición del sistema— y NO el relleno: cambiarlo movería las cajas, que es la línea que este bloque no cruza. ⚠️ El COLOR se deja como está a propósito. En estas páginas el fondo de cada botón viene de una regla por id, así que el CSS no puede distinguir el CTA sólido del fantasma, y pintarlos todos del acento convertiría en llamada principal a cuatro fichas de un selector. Es una decisión de jerarquía y la toma el equipo. */ body.cc-tema-estandar #brx-content :is(.bricks-button, .brxe-button) { font-family: var(--cc-font-sans); font-size: 15px; font-weight: 700; transition-duration: 0.18s; } /* 4. LAS DURACIONES a la escala (0.1 · 0.18 · 0.24 · 0.4 · 0.56). Las tres de fuera —0.2s, 0.3s, 0.5s— son indistinguibles a ojo de su vecina de la escala, así que alinearlas no cambia nada de lo que se ve y sí quita tres valores del sistema. */ /* `*` y no `[class*="brxe-"]`: en /equipo/ las duraciones de 0.5s y 0.3s viven en elementos internos sin clase de Bricks, así que el selector acotado las dejaba fuera. Aquí es seguro barrer: estas páginas no participan del sistema de movimiento —ese va por `ccd_pieza_con_movimiento()`— o sea que no hay ninguna duración deliberada que pisar, solo las que nadie eligió. */ body.cc-tema-estandar #brx-content * { transition-duration: 0.24s; } body.cc-tema-estandar #brx-content :is(a, button, .bricks-button) { transition-duration: 0.18s; } /* ========================================================================== NOSOTROS Y PORTAFOLIO: LA REJILLA SE QUEDA, LA TARJETA PASA A SER LA DEL TEMA (2026-08-10, pedido de Ricardo: "que se vean similar a la original, me gusta así") La composición NO se toca: mismas fotos, mismo orden, mismas columnas, misma copia. Lo que cambia es el vestido de cada tarjeta, que pasa a ser el mismo de las 4 hijas de /servicios/ — y los valores no se eligen aquí, se copian de esa pieza, que es la definición canónica: fondo `rgba(255,255,255,.06)`, radio 18px, borde de 1px, y la imagen recortada a la caja en vez de deformada. ⚠️ Va en CSS y NO versionando el JSON de estas dos páginas, a propósito. Versionarlas dejaría al equipo sin poder editarlas en el builder (§5: el JSON manda sobre la BD, y `post-import.sh` revierte lo que se toque). Estas dos se editan a menudo —el equipo entra, cambia una foto— y ese costo no compensa cuando el resultado se consigue con una hoja de estilo. Si algún día se rediseñan de verdad, entonces sí se versionan. ========================================================================== */ /* La tarjeta, idéntica en las dos páginas: una definición, no dos (8.40). ⚠️ SIN FONDO Y SIN CONTORNO, y esto costó tres rondas de "se ve mal el borde". La primera versión copiaba entera la tarjeta de las 4 hijas de /servicios/ —fondo `rgba(255,255,255,.06)` y filete de 1px—, y ahí la tarjeta es una CAJA DE TEXTO: el fondo separa el texto de la página y el filete la delimita. Aquí no: aquí la tarjeta es una FOTO a sangre. Un filete de 1px sobre una foto no se lee como borde, se lee como una raya; y un fondo bajo una imagen que ocupa todo solo asoma cuando algo no encaja — que es exactamente de dónde salían las muescas y las franjas que fuimos persiguiendo una por una. La lección, y es de diseño y no de CSS: **copiar un componente no es copiar sus valores, es copiar la decisión que los produjo.** El mismo sistema pide cosas distintas para una caja de texto y para una imagen a sangre. Del tema se queda lo que suma sin encajonar: el radio, el recorte de la foto y la elevación al pasar el puntero. */ body.cc-tema-estandar #brx-content :is(.brxe-div.card, .brxe-posts .repeater-item) { border-radius: var(--cc-radius-lg); overflow: hidden; /* la imagen se recorta al radio, no lo desborda */ /* `box-shadow` y no `transform`: la elevación dejó de ser geométrica el 2026-08-18 (8.79). La duración sigue en la escala, que es lo que exige `ux.mjs`. */ transition: box-shadow 0.24s; } body.cc-tema-estandar #brx-content :is(.brxe-div.card, .brxe-posts .repeater-item):hover { /* ⚠️ `!important` y no más especificidad, que es lo que se intentó primero. Bricks emite sobre estas fichas un `transform` propio —la matriz identidad de su animación de entrada, con `transition: transform .5s`— y una declaración con `!important` no se gana subiendo la especificidad: se gana con otra `!important`. Medido el 2026-08-17: sin esto, `/equipo/` se quedaba en `matrix(1,0,0,1,0,0)` al pasar el puntero mientras `/portafolio/` sí elevaba, con LA MISMA regla — la diferencia era que allí Bricks no escribe transform. `pendientes.md` lo dejó abierto desde el 2026-08-15 diciendo que arreglarlo «pedía volver a medir las dos páginas». Remedidas: /equipo/ pasa a -4px y /portafolio/ sigue en -4px, o sea la regla no le quita nada a la que ya funcionaba. */ /* ── Por qué NO es `translateY(-4px)` (2026-08-18) ─────────────────────────── Ricardo: *«en portafolios al pasar el mouse delante de algunos parpadea y hace la animación de bajar muy rápido, estilo bug»*. Y era literal. **La firma, medida:** con el puntero cerca del BORDE INFERIOR de una tarjeta, la secuencia de estado es `H____.HH____` — entra el hover, la tarjeta sube 4px, el cursor queda en el hueco que acaba de dejar, salta `mouseleave`, la tarjeta baja, el cursor vuelve a estar dentro, y otra vez. En el centro de la tarjeta la misma sonda da 45/45 estable: **el bug solo existe donde el movimiento cruza el puntero.** Y lo que se VE no es la tarjeta temblando —son 4px— sino el rótulo que se funde sobre la imagen reiniciando su transición en bucle, que es lo que Ricardo grabó. **Contraprueba:** anulando el `transform` en el navegador, 45/45 estable. Es la elevación, no Isotope ni el rótulo. ⚠️ **Y la salida obvia NO funciona acá:** extender el área de toque 4px hacia abajo con un `::after` —el patrón que este repo ya usa en `.cc-dot` y en el nav— queda RECORTADO, porque Isotope escribe `overflow: hidden` sobre la tarjeta. Medido: sigue parpadeando (3 cambios). Pelear con lo que escribe Isotope es 8.64. **Lo que sí funciona es que la caja nunca ENCOJA por ningún lado.** Con `transform-origin: bottom center` la tarjeta crece hacia arriba ~4px —el mismo gesto y la misma magnitud que antes— y el borde inferior se queda clavado, así que el puntero no puede quedarse fuera. Los lados crecen 3,5px dentro de un canalón de 30px, y hacia arriba no hay nada que invadir. Medido: **45/45 estable en el borde inferior, el superior y el centro**, y en las dos páginas que usan esta regla. Escala uniforme y no `scaleY`, que estiraría las fotos un 1,3%. Gotcha **8.79**. */ /* ⚠️ NINGÚN MOVIMIENTO, y esta es la tercera versión (2026-08-18). Las dos anteriores fallaron por la misma razón de fondo, que es la que hay que recordar: v1 `translateY(-4px)` — la ficha se quitaba de debajo del cursor en el borde inferior. Bucle. v2 `scale()` con origen abajo — arreglaba ESE borde, pero al FILTRAR el `:hover` oscila igual (7 cambios medidos, y es inevitable: las fichas se mueven bajo un cursor quieto). Ricardo lo vio: *«hace una animación de irse para abajo repetitivamente y sin texto»* — el «sin texto» era el retardo funcionando y el movimiento, esta regla. **Mientras el hover MUEVA algo, la oscilación se ve.** Y la oscilación no se puede eliminar. Así que la señal de elevación no puede ser geométrica: es una SOMBRA, que además es lo que «elevación» significa. La caja no se mueve ni un píxel, así que da igual cuántas veces entre y salga el estado. */ box-shadow: 0 12px 32px rgba(0, 0, 0, .5) !important; /* ── La segunda mitad de 8.79: el filtro ────────────────────────────────── Ricardo, después: *«al parecer pasa cuando pongo un filtro»*. Y es un mecanismo DISTINTO del de arriba, con su propia medida: al filtrar, Isotope recoloca las tarjetas y estas se deslizan **bajo un cursor quieto**, así que `mouseenter` y `mouseleave` se disparan solos. Medido pasando el ratón a distintos momentos: · 50ms tras filtrar (Isotope moviendo) -> `.HH.HH.H…` 6 cambios · 250ms (a media animación) -> `HH.H___HH…` 4 cambios · 1200ms (ya asentado) -> 45/45 estable, 0 cambios Eso NO se arregla con geometría: que una caja que se mueve cruce un puntero quieto es inevitable, y lo hace cualquier rejilla filtrable. Lo que se puede evitar es el ARTEFACTO, que es lo que se ve: el rótulo `.overlay-inner` de Bricks entrando y saliendo a `opacity .24s` en bucle — el «parpadea y baja muy rápido» del vídeo. ⚠️ Y no hay estado al que engancharse: **Isotope no marca la animación en el DOM** —medido: ni clase ni atributo cambian en el wrapper ni en los items durante los 1200ms—, así que un `pointer-events: none` mientras dura exigiría JavaScript propio escuchando sus eventos internos. No hace falta. La solución es INTENCIÓN DE HOVER: la entrada espera 100ms; la salida, no. Un hover espurio de la recolocación dura ~80ms y no llega a arrancar nada, mientras que uno de verdad se retrasa un valor imperceptible. El retardo va en la regla `:hover` —o sea gobierna la transición HACIA el estado— y el reposo lo deja en 0, que es como se consigue asimetría de entrada y salida con dos declaraciones. */ transition-delay: var(--cc-dur-instant); } /* La salida, inmediata: sin esto el retardo también frenaría el volver a su sitio. */ body.cc-tema-estandar #brx-content :is(.brxe-div.card, .brxe-posts .repeater-item) { transition-delay: 0s; } /* El rótulo de Bricks, el mismo trato: es LO QUE SE VE parpadear. */ body.cc-tema-estandar #brx-content :is(.brxe-div.card, .brxe-posts .repeater-item) .overlay-inner { transition-delay: 0s; } body.cc-tema-estandar #brx-content :is(.brxe-div.card, .brxe-posts .repeater-item):hover .overlay-inner { transition-delay: var(--cc-dur-instant); } /* La imagen, a sangre dentro de la tarjeta. `object-fit: cover` es el arreglo real: hoy /equipo/ sirve las 25 fotos con `fill`, o sea ESTIRADAS a la caja — las caras salen deformadas y eso sí se nota, aunque nadie lo hubiera nombrado. */ body.cc-tema-estandar #brx-content :is(.brxe-div.card, .brxe-posts .repeater-item) img { display: block; width: 100%; object-fit: cover; border-radius: 0; /* el radio lo pone la tarjeta, no la imagen */ } /* El texto de la tarjeta respira como en el rediseño: el relleno va DENTRO, no en la imagen, que por eso queda a sangre. */ body.cc-tema-estandar #brx-content :is(.brxe-div.card, .brxe-posts .repeater-item) > :not(img):not(picture):not(a) { padding-left: 18px; padding-right: 18px; } body.cc-tema-estandar #brx-content :is(.brxe-div.card, .brxe-posts .repeater-item) > :last-child:not(img) { padding-bottom: 18px; } /* ── Portafolio: el filtro y el icono de las tarjetas (2026-08-10) ─────────── Reportado por Ricardo: *"moderniza las categorías/filtro"* y *"las tarjetas tienen como un ojo, pero se ve mal en la mayoría"*. */ /* EL "OJO". Es un SVG de 300×150 con `fill: #000` que el bucle pinta IGUAL en las 28 tarjetas —no es el logo del proyecto, es decoración— y vive dentro del panel que aparece al pasar el puntero, o sea negro sobre un velo oscuro: un borrón que tapa la foto y no aporta nada. Se retira en vez de recolorearlo: un icono genérico repetido 28 veces no gana nada por ser visible, y el panel ya dice lo que hace falta con el título y la bajada. El campo sigue en el bucle, así que si mañana se quiere un icono POR proyecto, el sitio donde ponerlo ya existe. */ body.cc-tema-estandar #brx-content .brxe-posts .dynamic > svg { display: none; } /* EL FILTRO. Tenía borde de 3px, radio de 25px y 16px de texto: tres valores que no existen en ninguna escala del sistema. Pasa al lenguaje de los chips del rediseño — píldora, borde de 1px, 15px— y el activo toma el acento de marca en vez del verde viejo `#08AA7A`, con tinta encima, que es la regla del sistema sobre acento claro. */ /* ⚠️ El selector es `.bricks-isotope-filters li` y NO `.brxe-posts li:not(.repeater-item)`, y la diferencia tumbó la rejilla entera. Isotope mete DENTRO de su contenedor unos `li` de ayuda —invisibles— con los que calcula el ancho de columna; la primera versión los cazaba y les ponía relleno y borde, así que la columna medida creció y las 28 tarjetas colapsaron a UNA sola columna, apiladas en x=170. Medido: sin este bloque vuelven a x=170 y x=735. La regla que queda: en una rejilla posicionada por JS, un selector amplio no solo pinta de más — puede reprogramar la geometría. */ body.cc-tema-estandar #brx-content .bricks-isotope-filters li { border: 1px solid var(--cc-border-on-dark); border-radius: var(--cc-radius-pill, 999px); padding: 9px 18px; font-size: 15px; font-weight: 600; color: var(--cc-fg-read); background: transparent; transition: background-color 0.18s, border-color 0.18s, color 0.18s; } body.cc-tema-estandar #brx-content .bricks-isotope-filters li:hover { border-color: var(--cc-fg-accent); color: var(--cc-fg-accent); } body.cc-tema-estandar #brx-content .bricks-isotope-filters li.active { background: var(--cc-fg-accent); border-color: var(--cc-fg-accent); color: var(--cc-ink-900); } /* EL SALTO AL FILTRAR (2026-08-15, reportado por Ricardo: «los portafolios saltan»). Medido en el navegador, la causa no era la que parecía. Isotope **fija la altura del contenedor en UN fotograma** y anima las tarjetas después: t= 8 ms alto de la grilla 4633 -> 1324 (el pie sube 3.309px de golpe) t=362 ms terminan de desvanecerse las 20 que se van t=670 ms las 8 que quedan acaban de colocarse O sea hay **650ms en que el pie ya subió y las tarjetas todavía vuelan**. Eso es lo que se ve como un tirón: no lo dan las tarjetas, lo da todo lo que hay DEBAJO de ellas. Y si estabas más abajo del nuevo alto máximo, el navegador además te arrastra al hacer clamp del scroll (medido: 1800 -> 1327). Y hay un SEGUNDO defecto encima, que Ricardo describió aparte —«como que las tarjetas hacen doble animación»— y que la misma traza ya contenía: hasta t=344 ms cambian opacidad Y posición (las 20 que se van, desvaneciéndose) de t=368 a 660 cambia SOLO la posición (las 7 que quedan, aún viajando) O sea 316ms de cola en que ya no se desvanece nada y todavía hay tarjetas moviéndose: eso es el segundo gesto. No lo hace Isotope por su cuenta —lo alarga la transición de `transform` que esta misma hoja le pone a `.repeater-item` unas líneas más arriba, para la elevación al pasar el puntero—. Comprobado: anulando esa transición, todo el movimiento se resuelve en 12ms. LA CURA, Y ES UNA SOLA DECISIÓN PARA LOS DOS DEFECTOS: que todo termine a la vez. Medido sobre cuatro combinaciones de valores del sistema —los tokens, no valores inventados, que `ux.mjs` tiene un trinquete sobre eso—: tarjetas | altura | cola | desfase | mayor salto de altura por fotograma --------- -------- ------- --------- ------------------------------------ (nada) (nada) 282ms — 3.309 px <- el estado que se reportó 100ms 240ms 29ms 45ms 617 px 100ms 400ms 49ms 200ms 372 px 180ms 400ms 133ms 33ms 374 px <- elegida 240ms 560ms 282ms 137ms 266 px ⚠️ El compromiso es real y conviene tenerlo escrito: 3.309px no se pueden recorrer rápido Y suave a la vez. Cuanto más corta la transición de altura, mayor el tirón por fotograma. Se elige `fast`+`slow` porque **las tarjetas y la página terminan juntas** (33ms de desfase): mientras queda cola de movimiento la altura sigue viajando, así que no se lee como dos gestos sino como uno que acaba. Las variantes de 100ms cortan más la cola pero dejan la página moviéndose 200ms después de que las tarjetas ya pararon, que es cambiar un desajuste por otro. ⚠️ Se apunta SOLO al contenedor y a sus hijos DIRECTOS: el bloque de arriba documenta que un selector amplio dentro de una rejilla posicionada por JS le reprograma la geometría. ⚠️ Y no anima al CARGAR la página —comprobado midiendo el alto durante los primeros 1,5s—: en la primera maquetación la altura se fija antes de que esta hoja aplique. Gotcha 8.64, con sus chequeos en `ux.mjs`. */ body.cc-tema-estandar #brx-content ul.bricks-layout-wrapper.isotope { transition: height var(--cc-dur-slow) var(--cc-ease); } /* ⚠️ LA POSICIÓN NO SE ANIMA, Y ESTO ES LO QUE DE VERDAD SE VEÍA MAL. Acortar la animación no bastó: Ricardo seguía viéndolo después de bajarla a 180ms. Al mirar la secuencia fotograma a fotograma —en vez de fiarse de los tiempos— aparece el motivo, y no es la duración: **mientras las tarjetas viajan a su nueva casilla se SOLAPAN unas con otras**. Las que se van todavía son opacas y se cruzan con las que llegan, así que a mitad del gesto la rejilla es un revoltijo. Medido, contando pares de tarjetas visibles cuyas cajas se cortan: posición animada 180ms -> pico de 11 PARES solapados, solape presente de 27 a 326ms solo desvanecido -> 0 pares, en ningún fotograma Por eso aquí solo se transiciona `opacity`. Las tarjetas aparecen ya en su sitio y se desvanecen; la altura del contenedor sigue viajando, que es lo que evita el tirón. Una rejilla filtrada no necesita que sus piezas viajen: necesita que el cambio se entienda. ⚠️ Lección de método, y es la de 8.15 otra vez: **la métrica que se eligió primero —cuánto dura cada fase— daba «arreglado» mientras el defecto seguía ahí.** El defecto no era temporal, era espacial. Cuando alguien insiste en que sigue viéndolo, lo que hay que cambiar es lo que se mide, no el umbral. ⚠️ `!important` porque Isotope escribe `transition-duration` INLINE mientras anima, y una hoja no le gana a un estilo inline. Es 8.1 en su versión de JavaScript. */ body.cc-tema-estandar #brx-content ul.bricks-layout-wrapper.isotope > li { transition: opacity var(--cc-dur-fast) linear !important; } /* La elevación al pasar el puntero se conserva declarando su transición EN el `:hover`: entra suave y sale seca. Si estuviera en la regla base volvería a animar `transform` y con ella el reacomodo de Isotope — que es justo lo que acabamos de quitar. */ body.cc-tema-estandar #brx-content ul.bricks-layout-wrapper.isotope > li:hover { transition: opacity var(--cc-dur-fast) linear, transform var(--cc-dur-fast) var(--cc-ease) !important; } @media (prefers-reduced-motion: reduce) { /* Sin transición se vuelve al cambio instantáneo, y es lo correcto: quien pide menos movimiento prefiere un salto brusco a una animación de medio segundo (8.24). */ body.cc-tema-estandar #brx-content ul.bricks-layout-wrapper.isotope, body.cc-tema-estandar #brx-content ul.bricks-layout-wrapper.isotope > li { transition: none; } } /* Las fichas de /equipo/: nombre y cargo alineados igual. Medido, el desajuste no era una preferencia sino una incoherencia dentro de la MISMA ficha: el nombre es una caja de ancho automático que el flex centra, con el texto a la izquierda dentro —así que los nombres cortos PARECEN centrados (Dayana Verde a 41px del borde) y los largos no (Mauricio Dinamarca a 18px)— y el cargo es una caja de ancho fijo con el texto centrado. Dos criterios en dos líneas que se leen juntas. Se unifican a la IZQUIERDA porque es lo que hace el resto del sitio: las tarjetas de /servicios/ y los propios títulos de área de esta página ("Gerencia", "Finanzas"). */ /* ⚠️ `.card p` y no `.card > .brxe-div > p`: el cargo de varias fichas cuelga un nivel más abajo, así que el selector de hijo directo dejaba tres alineaciones distintas donde el objetivo era una. */ body.cc-tema-estandar #brx-content .brxe-div.card p { width: 100%; text-align: left; } /* Y un respiro entre la foto y el nombre: sin él el texto arranca pegado al borde de la imagen, que es lo que más se notaba en la primera ficha. */ body.cc-tema-estandar #brx-content .brxe-div.card > .brxe-div { padding-top: 14px; } /* ⚠️ Y los CONTENEDORES del texto, no solo los `p`. El nombre vive en una caja de ancho automático que el flex de la ficha centra, así que ponerle `text-align: left` al párrafo no movía nada: el texto ya estaba a la izquierda DE SU CAJA, y la caja estaba centrada. Medir el desplazamiento contra el padre lo ocultaba —daba 0— y solo se ve midiendo contra la ficha. Es 8.15: la referencia equivocada convierte un fallo en un número correcto. */ body.cc-tema-estandar #brx-content .brxe-div.card > .brxe-div, body.cc-tema-estandar #brx-content .brxe-div.card > .brxe-div > * { width: 100%; align-items: flex-start; } /* ⚠️ 8.33 POR CUARTA VEZ, y esta la vio Ricardo antes que ninguna prueba: las fichas de /equipo/ salían ESCALONADAS. El contenedor de cada área es un flex con `align-items: flex-start`, así que cada ficha toma la altura de su propia foto — y las fotos vienen en dos proporciones (1.07 y 1.00), o sea tarjetas de 257 y 270px con sus tops en 2488, 2489, 2491 y 2495. Seis fichas en fila y ninguna alineada con su vecina. Se arregla por donde corresponde y no con un alto fijo a ojo: · la fila ESTIRA a sus hijas (`align-items: stretch`), que es lo que 8.33 pide re-declarar siempre que se hereda un eje de Bricks; · y la foto adopta UNA proporción para todas, así el recorte lo decide el sistema y no el archivo que subió cada quien. Cuadrada porque es la que ya tienen: 1.00 y 1.07 medidas, o sea nadie va a notar el ajuste y todas quedan iguales. Es la misma exigencia que `servicios.mjs` ya le hace a las tarjetas del rediseño: no basta con que compartan definición, tienen que ocupar la misma caja. */ body.cc-tema-estandar #brx-content .brxe-div.card { height: 100%; } body.cc-tema-estandar #brx-content .brxe-block:has(> .brxe-div.card), body.cc-tema-estandar #brx-content .brxe-div.card { align-self: stretch; } body.cc-tema-estandar #brx-content .brxe-div:has(> .brxe-block > .brxe-div.card), body.cc-tema-estandar #brx-content .brxe-block:has(> .brxe-div.card) { align-items: stretch; } /* ⚠️ Y el ANCHO fijo, que es la mitad que faltaba. La ficha no declara ancho, así que toma el natural de su foto: medidas 7 anchuras distintas —200, 196, 193, 172, 171, 165 y 154— con sus altos detrás. `aspect-ratio` por sí solo no lo arregla: fija la proporción, no el tamaño. ⚠️⚠️ Y la lección de instrumento, que es la cara: la primera medición dijo "25 fichas, todas de 200×200, uniforme" y era MENTIRA — se tomó antes de que las imágenes decodificaran, cuando todas ocupaban el mismo hueco reservado. Ricardo lo vio en pantalla mientras la prueba decía que estaba bien. Para medir una rejilla que depende del tamaño de sus imágenes hay que esperar a `img.decode()`, no a `networkidle` (8.15). */ body.cc-tema-estandar #brx-content .brxe-div.card { width: 200px; } body.cc-tema-estandar #brx-content .brxe-div.card > img { width: 100%; aspect-ratio: 1 / 1; height: auto; object-fit: cover; } /* ⚠️ El bloque de texto NO lleva radio propio. Traía 18px en las cuatro esquinas, así que sus esquinas SUPERIORES se redondeaban justo donde topa con la foto y dejaban dos muescas —una a cada lado— con el fondo de la tarjeta asomando: es el "se ve mal el borde en ambos lados" que reportó Ricardo. Medido, los dos hijos llegan a los bordes (izq=+0, der=-0): el defecto no era una sangría sino un radio de más. La tarjeta ya recorta con `overflow: hidden`, o sea que el redondeo exterior está resuelto y cualquier radio en el hijo solo puede restar. */ body.cc-tema-estandar #brx-content :is(.brxe-div.card, .brxe-posts .repeater-item) > * { border-radius: 0; } /* ⚠️ La franja muerta del pie. En /portafolio/ la tarjeta mide 319px y la imagen 301: los 18 que sobran son el panel de título, que va `visibility: hidden` hasta el hover pero SIGUE OCUPANDO SITIO. En las 28 tarjetas quedaba una banda oscura al pie que se lee como un borde mal rematado —es lo que reportó Ricardo— y que además rompe la proporción: la foto ya no llena su caja. Se saca del flujo con `position: absolute`, que es lo que el panel quería ser desde el principio: aparece ENCIMA al pasar el puntero y no reserva nada mientras no se ve. Con eso la imagen ocupa la tarjeta entera y el borde vuelve a ser un rectángulo limpio. */ /* Medido: todo el contenido de la tarjeta acaba en 301px y la tarjeta mide 319. Los 18 que sobran no son un panel oculto —esa fue mi primera hipótesis y no movió nada— sino `padding-bottom: 18px` en el propio enlace. Con la tarjeta sin fondo no se veía; con fondo y borde se convierte en una banda muerta al pie de las 28. */ /* ⚠️ Con `!important`, y no por pereza. La regla que pone ese relleno la genera Bricks para el elemento y gana incluso a un selector de (1,3,2) como el de aquí abajo —se probó y el computado seguía en `0px 0px 18px`—. La alternativa era encadenar el id generado del bucle (`#brxe-vxzbum`), que cambia si alguien rehace la sección en el builder: más frágil y más difícil de encontrar dentro de seis meses. */ body.cc-tema-estandar #brx-content .brxe-posts .repeater-item > a { padding-bottom: 0 !important; } /* ========================================================================== TEXTO SOBRE LA BANDA VIOLETA (2026-08-13) Las dos bandas violetas —el giro y los números— son islas oscuras, pero NO son la misma superficie que las otras islas del sitio, y eso rompe la suposición que el bloque de islas venía haciendo. El cierre, el footer y los velos de carrusel son casi negros (#0a0a0f); el violeta es `#4B2FBF`, bastante más claro. El mismo token da resultados opuestos: --cc-ink-meta (#898989) sobre #0a0a0f → 5.4:1 ✅ --cc-ink-meta (#898989) sobre #4B2FBF → 2.44:1 ❌ Saltó al fusionar Respaldo dentro de Métricas: las píldoras de trayectoria vivían sobre el suelo oscuro y pasaron al violeta con sus colores intactos. En oscuro se arregló subiendo el alfa en `#brxe-sec061`, pero en CLARO la regla de islas gana por especificidad (1,1,1 contra 1,0,0) y volvía a bajarlos. De ahí que `a11y.mjs` pasara y `tema.mjs` no: **el mismo fallo tapado en un tema y visible en el otro**, que es exactamente lo que 8.24 dice que hay que medir en los dos. Va con la MISMA especificidad que la regla de islas y DESPUÉS en el archivo, que es lo que decide un empate. Y cubre las dos bandas, no solo la que falló: la otra (el giro) tiene hoy poco texto atenuado y mañana puede tenerlo. ========================================================================== */ :is(#brxe-sec035, #brxe-sec061), html[data-theme="light"] :is(#brxe-sec035, #brxe-sec061) { --cc-fg-muted: rgba(255, 255, 255, 0.86); --cc-fg-read: rgba(255, 255, 255, 0.94); } /* ⚠️ Y un color de FONDO sólido bajo el degradado de la banda del giro. No es decorativo y no lo pinta nadie: el degradado es un `background-image`, así que cualquiera que suba por el DOM buscando un fondo sólido —el medidor de contraste de las suites, un lector, un navegador que no pinte el degradado— no encuentra ninguno y cae al fondo de PÁGINA. En claro eso daba "texto claro sobre fondo claro, 1.7:1" para una bajada que en pantalla está a ~5:1 sobre violeta: un fallo inventado por el instrumento. La salida no es enseñarle al medidor a leer degradados sino no dejar el hueco: un degradado debería declarar siempre su color de base. */ body #brxe-sec035.cc-banda-violeta { background-color: var(--cc-violet-600); } /* ============================================================================= MAQUETA DEL FORMULARIO — solo local (2026-08-15) ============================================================================= Acompaña a `ccd_form_maqueta()` en `functions.php`. Existe para poder DISEÑAR y MEDIR `/contacto/` en local: sin ella el formulario ocupa 1.374px contra los 1.067 que mide la página en producción, y cualquier decisión de layout se toma sobre una página que no existe. Es lo que llevó a la auditoría a apuntar «la mitad vacíos» (ver la corrección en `pendientes.md`). ⚠️ Todo cuelga de `.cc-form-maqueta`, una clase que **solo emite la maqueta**. En producción Gravity Forms registra su propio shortcode, la maqueta no llega a existir y estas reglas no encuentran a nadie: no pueden filtrarse. Es la misma guarda de dos capas que ya tiene el PHP, pero en CSS. No pretende ser el formulario final: pretende ocupar lo que ocupa el real, para que las medidas de la página signifiquen algo. ========================================= */ .cc-form-maqueta { --mq-linea: color-mix(in srgb, var(--cc-fg-read) 28%, transparent); } .cc-form-maqueta .cc-form-ausente { border: 1px dashed var(--mq-linea); border-radius: var(--cc-radius-md); padding: 10px 14px; margin: 0 0 var(--cc-space-6); font-size: 13px; /* ⚠️ Era `--cc-fg-muted` y lo tumbó `a11y.mjs` el 2026-08-27 con **3.94:1**, al entrar la maqueta en la tarjeta de 8.113: el mismo #898989 daba 4.68:1 sobre el fondo de sección y 3.94 sobre la tarjeta. No cambió el color: cambió lo que tiene detrás, que es el modo de fallo que describe 8.37 al revés — la regla siguió correcta y su contexto no. Se sube al token de lectura, que está medido en los dos temas (9.64:1 sobre sección) y sigue siendo más quieto que el cuerpo. */ color: var(--cc-fg-read); } .cc-form-maqueta .gform_fields, .cc-form-maqueta .gfield_checkbox { list-style: none; margin: 0; padding: 0; } .cc-form-maqueta .gform_fields { display: grid; gap: var(--cc-space-6); } .cc-form-maqueta .gfield_label { display: block; margin-bottom: 6px; font-size: 15px; font-weight: 700; color: var(--cc-fg-read); } .cc-form-maqueta .gfield_required { color: var(--cc-fg-accent); } /* Los dos campos por fila del formulario real (nombre+apellido, email+teléfono). */ .cc-form-maqueta .ginput_complex { display: grid; grid-template-columns: 1fr 1fr; gap: var(--cc-space-4); } .cc-form-maqueta input, .cc-form-maqueta textarea { width: 100%; background: transparent; border: 0; border-bottom: 1px solid var(--mq-linea); padding: 8px 2px; color: var(--cc-fg-read); font: inherit; font-size: 15px; } .cc-form-maqueta textarea { resize: none; } /* ⚠️ 24x24 y no el tamaño nativo (13px). Lo pide WCAG 2.5.8 y lo mide `a11y.mjs`, que cubre esta página. En producción las casillas de Gravity Forms miden 13px, así que la maqueta es aquí a propósito MÁS estricta que el original: sirve de recordatorio de lo que el formulario real debería cumplir cuando se pueda auditar en staging (§12). */ .cc-form-maqueta input[type="checkbox"] { width: 24px; height: 24px; flex: 0 0 auto; border: 1px solid var(--mq-linea); } /* Duración explícita y del sistema: sin ella los campos heredan un `0.2s` que no está en ninguna escala, y el trinquete de entropía de `ux.mjs` lo caza. */ .cc-form-maqueta input, .cc-form-maqueta textarea, .cc-form-maqueta .gform_button { transition-duration: var(--cc-dur-fast); } /* Las 8 casillas van en flujo, como en producción: no una por línea. */ .cc-form-maqueta .gfield_checkbox { display: flex; flex-wrap: wrap; gap: 10px var(--cc-space-4); } .cc-form-maqueta .gfield_checkbox li { display: flex; align-items: center; gap: 8px; } .cc-form-maqueta .gfield_checkbox label { font-size: 14px; color: var(--cc-fg-read); } .cc-form-maqueta .charleft { display: block; margin-top: 6px; font-size: 12px; color: var(--cc-fg-muted); } .cc-form-maqueta .gform_footer { margin-top: var(--cc-space-6); display: flex; justify-content: flex-end; } .cc-form-maqueta .gform_button { border: 0; border-radius: var(--cc-radius-pill, 999px); padding: 12px 32px; background: var(--cc-fg-accent); color: var(--cc-ink-900); font: inherit; font-weight: 700; } @media (max-width: 767px) { .cc-form-maqueta .ginput_complex { grid-template-columns: 1fr; } } /* ============================================================================= /equipo/ — fichas: nombres cortados y dos tarjetas moradas (2026-08-15) ============================================================================= Reportado por Ricardo: *«las tarjetas se ven feas, los nombres se ven raros… hay algunas con un borde morado no sé por qué. En móvil algunos nombres se cortan»*. Las tres cosas son reales y las tres salen del MISMO sitio: valores fijos escritos a mano en el builder, que viven en la BD y no aguantan un texto más largo que el que había el día que se escribieron. 1. EL RECORTE. El bloque de texto de cada ficha lleva `height: 70px` fijo (`#brxe-xsiwel` en el CSS de la página). A 1440 sobra, porque los nombres caben en una línea. A 390 la caja se estrecha, «José Andrés Pinto» pasa a dos líneas (54px) y «Auxiliar Administrativo Contable» a tres (42px): **96px de contenido en 70px de caja**, y `overflow: hidden` —que esta hoja pone para que la foto se recorte al radio— se come los 11px que sobresalen del borde de la ficha. Se pasa a `height: auto` con el 70 como MÍNIMO: las fichas de nombre corto quedan exactamente igual que hoy y solo crecen las que lo necesitan. ⚠️ No se toca el `overflow: hidden` de la ficha: es lo que redondea la foto. El problema nunca fue el recorte, era la caja demasiado baja. 2. EL MORADO. Dos fichas —Dayana Verde y José Andrés Pinto, las dos de Finanzas— llevan `background: var(--bricks-color-kwgdoe)`, o sea `#4B2FBF`, puesto **desde el builder** sobre su id. Las otras 24 llevan la superficie de siempre. No hay ninguna regla que lo explique —ni el área ni el cargo— así que se lee como un descuido, no como una jerarquía. Se normaliza al mismo fondo que el resto. ⚠️ Y ojo: **esto es una decisión de diseño tomada en la BD y aquí se está anulando desde el theme.** Si el violeta fuera deliberado —destacar Finanzas— la vía correcta es al revés: quitarlo del builder y declarar la variante en el sistema. Queda anotado en `pendientes.md`. ========================================================================== */ body.cc-tema-estandar #brx-content .brxe-div.card > .brxe-div { height: auto; min-height: 70px; } /* ⚠️ Y la segunda mitad del arreglo, sin la cual el primero EMPEORA lo que venía a arreglar. Al dejar crecer el bloque de texto, cada ficha pasó a medir lo que pedía su contenido: se acabó el recorte, pero **6 de 15 filas quedaron con tarjetas de distinta altura** — que es justo el «se ven feas» del que salió todo. `height: 100%` no sirve para igualarlas: se resuelve contra un padre de altura indefinida, así que cada una acaba con la suya. Lo que sí iguala es dejar que el flex las estire — `height: auto` y `align-self: stretch`—: todas las de una fila toman la altura de la más alta. Medido en las dos: recorte 0px y **0 filas desparejas de 17 a 390px y de 11 a 1440**. */ /* ⚠️ `!important` en `align-self`, y no por comodidad: Bricks emite `#brxe-tjpttd { align-self: flex-start !important }` desde el builder. La especificidad de esta regla YA le gana (1 id + 3 clases contra 1 id), así que sin el `!important` parecía correcta y no aplicaba — se vio leyendo el computado, no el CSS. Es 8.1 literal. */ body.cc-tema-estandar #brx-content .brxe-div.card { height: auto !important; align-self: stretch !important; background-color: var(--cc-surface-1, rgb(28, 26, 42)); } /* ============================================================================= /portafolio/ — los filtros también en móvil (2026-08-15) ============================================================================= Pedido de Ricardo: *«quiero que se vean y funcionen los filtros en la versión móvil»*. No estaban rotos: la página tiene **DOS rejillas** y el builder alterna entre ellas. #brxe-vxzbum la buena: 28 proyectos CON filtros -> `display:none` bajo 767px #brxe-bnvyqj una copia: la mitad de proyectos, SIN filtros -> la que se ve en móvil O sea en un teléfono no solo faltaban los filtros: se veían **la mitad de los proyectos**. Se invierte la alternancia y el móvil pasa a usar la rejilla buena. Medido a 390 y 414px con la regla puesta: los 7 filtros se reparten en 3 filas, cada uno de 46px de alto —por encima de los 24 que pide WCAG 2.5.8—, la página NO desborda (`scrollWidth` = ancho del viewport) y **el filtrado funciona**: 28 tarjetas pasan a 8 al pulsar «Creatividad». Isotope no necesita nada más; la rejilla cae a una columna sola. ⚠️ Esto ANULA desde el theme una decisión tomada en el builder, y por eso va aquí y no en la BD: un arreglo en la BD se pierde con el próximo volcado de producción (§10). La copia `#brxe-bnvyqj` sigue existiendo en la página — lo suyo es borrarla desde el builder, y mientras no se haga, esta regla la mantiene oculta en todos los anchos. Queda anotado en `pendientes.md`. ============================================ */ @media (max-width: 767px) { body.cc-tema-estandar #brx-content #brxe-vxzbum { display: block !important; } body.cc-tema-estandar #brx-content #brxe-bnvyqj { display: none !important; } } /* ============================================================================= /portafolio/ — la costura bajo la cabecera (2026-08-15) ============================================================================= Ricardo: *«el fondo de Portafolio no me gusta»*. Medido, hay una firma concreta y no es una cuestión de gusto: la banda del titular usa `#0D0D0D` sobre una página de `#0A0A0F`. Los dos son tokens del sistema —`--cc-bg-deep` y `--cc-bg`— pero **no son el mismo negro**: uno es gris neutro y el otro lleva el tinte azul del fondo principal. Tres puntos de diferencia por canal, lo justo para que se vea un rectángulo mal recortado bajo la cabecera y no para que parezca deliberado. Y lo que lo cierra: `/portafolio/` es la **única** página del sitio que hace esto. Medida la primera sección de las seis principales: /portafolio/ rgb(13,13,13) sobre rgb(10,10,15) <- costura /equipo/ transparente /blog/ transparente /contacto/ transparente /servicios/ rgb(10,10,15) = el fondo / rgb(10,10,15) = el fondo Se pasa a transparente, que es lo que hacen las otras. Una banda de título solo se justifica si CONTRASTA de verdad; a Δ3 no separa nada, solo ensucia. ⚠️ El color venía del builder, así que esto vuelve a anular una decisión de la BD — con el mismo criterio que las otras tres de hoy: en el theme para que sobreviva al volcado, y anotado en `pendientes.md` para resolverlo en su origen. */ /* ⚠️ Se apunta al ID y no a `section:first-of-type`. La primera versión usaba el selector genérico y habría tocado la primera sección de TODAS las páginas de tema estándar —`/brands/` tiene ahí un `rgb(25,25,25)` que sí es suyo—. El defecto es de una página; el arreglo también. Es el mismo criterio que el resto de parches heredados de esta hoja, que van por id. */ body.cc-tema-estandar #brx-content #brxe-xskses { background-color: transparent; } /* ══════════════════════════════════════════════════════════════════════════ /contacto/ — datos y formulario (2026-08-16) ══════════════════════════════════════════════════════════════════════════ El defecto que arregla esta rejilla está medido en `pendientes.md`: «la columna izquierda muere mucho antes que la derecha —la foto y la caja de dirección acaban donde el formulario aún tiene 150px por delante— y debajo queda una banda muerta». ⚠️ Y el diagnóstico ORIGINAL de esa página era falso, lo que conviene recordar antes de tocar nada aquí: la auditoría del 2026-08-09 le atribuyó «1.391px de alto, la mitad vacíos» midiendo en LOCAL, donde Gravity Forms no está montado. Contra producción la página mide 1.067 y el formulario ocupa 689×868 (8.62). O sea la mitad derecha nunca estuvo vacía; la que se queda corta es la IZQUIERDA, y es la que esto llena. La cura no es estirar la columna: es darle contenido real. Hasta hoy solo tenía la dirección. Ahora lleva los tres datos que el sitio YA publica en su pie —dirección, teléfono y correo— más la vía que no es el formulario. Ninguno es copia nueva. ────────────────────────────────────────────────────────────────────────── */ .cc-contacto-grid { display: grid; /* `1fr 1.15fr` y no `1fr 1fr`: el formulario son 16 campos y la columna de datos son cuatro líneas. Partir por la mitad le da al lado ligero el mismo peso que al pesado, que es justo el desequilibrio del que venimos. */ grid-template-columns: 1fr 1.15fr; gap: var(--cc-space-10); align-items: start; } /* Un solo breakpoint, y es el mismo que usa el resto del sistema (8.19): bajo 767 el header ya apila, así que apilar aquí a otro ancho crearía un tercer punto de quiebre que nadie recuerda. */ @media (max-width: 767px) { .cc-contacto-grid { grid-template-columns: 1fr; gap: var(--cc-space-8); } } .cc-contacto-datos { display: flex; flex-direction: column; gap: var(--cc-space-5); } /* La foto de la oficina (2026-08-16). Va PRIMERA en la columna y no de adorno: sitúa, y la dirección que viene justo debajo la nombra. Es además el primer material PROPIO que entra en una pieza rediseñada — hasta hoy las imágenes del sistema eran stock, por bien tratado que estuviera, y el hallazgo 5 de la auditoría del 2026-08-09 lleva desde entonces pidiendo exactamente esto. ⚠️ Se sirve desde el THEME y no desde la biblioteca de medios, por la misma razón que los logos de partners: los ids de adjunto no sobreviven a un volcado (§10), así que un JSON versionado que cite uno se rompe solo. */ /* ⚠️ La clase va sobre el `` MISMO, no sobre un envoltorio: el elemento `image` de Bricks emite la etiqueta directa cuando no hay enlace ni pie de foto. La primera versión de esta regla era `.cc-contacto-foto img { … }` y no aplicó NUNCA — 8.9 literal, un selector escrito contra markup que no existe. Se veía bien igual, por pura suerte: la fuente ya viene a 16:9, así que el `aspect-ratio` que no llegaba a aplicarse no hacía falta. Con otra foto habría salido deformada y nadie habría entendido por qué. Se cubren las DOS formas por si un día lleva enlace, que es cuando Bricks sí envuelve. */ .cc-contacto-foto, .cc-contacto-foto img { display: block; width: 100%; height: auto; margin: 0 0 var(--cc-space-2); aspect-ratio: 16 / 9; object-fit: cover; border-radius: var(--cc-radius-md); } /* ⚠️ Y aquí está la mitad del arreglo que la rejilla NO resuelve, medida y no supuesta. Con los tres datos puestos, la columna izquierda mide 283px contra los 1.014 del formulario: quedaban **731px de banda muerta** a 1440. Darle más contenido sería escribir copia, que es decisión del equipo (§7), así que la salida es que el panel ACOMPAÑE en vez de quedarse atrás — el hueco deja de leerse como abandono porque el ojo nunca lo tiene delante. `top` sale de la altura real del header pegajoso (85px, medida de 320 a 1440 el 2026-07-29, gotcha 8.19) más aire. Si el header cambia de alto, este número se queda corto y el panel se mete debajo: por eso va con el número explicado y no suelto. ⚠️ Depende de que el contenedor NO recorte y de `align-items: start` en la rejilla — sin eso el ítem se estira a la altura de la fila y un `sticky` dentro de una caja de su mismo alto no tiene por dónde deslizarse, que es 8.26 literal: el header declaraba `position: sticky` desde que se construyó y nunca se pegó porque su padre lo ceñía. */ @media (min-width: 768px) { .cc-contacto-datos { position: sticky; top: calc(85px + var(--cc-space-6)); } } /* ========================================================================== EL CIERRE DE LA PORTADA ACOMPAÑA A SU FORMULARIO (2026-08-17) Ricardo: *"este texto del homepage ¿puedes hacer que baje con el formulario, como en contacto?"*. Es el MISMO caso y por eso reusa el mismo mecanismo, no uno nuevo: el titular y su bajada miden 291px al lado de un formulario de 1.077, así que al desplazarse el texto desaparecía por arriba y quedaban 786px de columna vacía junto a los campos — exactamente lo que el panel de datos de /contacto/ vino a resolver. ⚠️ Las dos condiciones que un `sticky` necesita ya se cumplían aquí, y conviene decir cuáles son porque son la mitad de 8.26: el contenedor es `grid` con `align-items: start` —si estirara el ítem a la altura de la fila, no tendría por dónde deslizarse— y no recorta (`overflow: visible`). Medido antes de tocar nada: 291px de contenido en una fila de 1.077 dejan 786px de recorrido. El `top` sale de la altura real del header pegajoso (85px, 8.19) más aire, igual que en /contacto/. Si el header cambia de alto, este número se queda corto: por eso va explicado y no suelto. ========================================================================== */ @media (min-width: 768px) { .cc-cierre-texto { position: sticky; top: calc(85px + var(--cc-space-6)); } } /* Sin movimiento pedido, nada se mueve: un panel que persigue al usuario es justamente lo que `prefers-reduced-motion` viene a apagar (8.23). */ @media (prefers-reduced-motion: reduce) { .cc-contacto-datos, .cc-cierre-texto { position: static; } } .cc-contacto-titulo { margin: 0 0 var(--cc-space-2); color: var(--cc-fg-strong); font-family: var(--cc-font-sans); font-weight: 700; font-size: var(--cc-fs-h3); line-height: 1.2; } /* Cada dato es rótulo arriba y valor abajo. Se usa `grid` y no dos párrafos para que el rótulo y su valor no se puedan separar al reflowear. ⚠️ Y va sobre el div Y sobre su `
` interior, que no es redundancia: el elemento `text` de Bricks ENVUELVE su contenido en un `
`. Con la regla solo en el div, la rejilla se aplicaba a un contenedor de un único hijo y los `span` seguían en línea: en pantalla salía «DIRECCIÓNAv. Andrés Bello 2687», pegado y sin salto. Es 8.9 —un selector contra markup que no existe— y esta vez NO lo cazó ninguna medición: lo vio Ricardo en la captura. Las sondas miraban la caja del panel y su altura, que eran correctas; nadie le había preguntado a la página si el rótulo y su valor caían en líneas distintas. 8.53 otra vez. */ .cc-contacto-dato, .cc-contacto-dato > p { display: grid; gap: 4px; margin: 0; } .cc-contacto-rotulo { color: var(--cc-fg-muted); font-size: 13px; font-weight: 700; letter-spacing: 0.04em; text-transform: uppercase; } .cc-contacto-valor { color: var(--cc-fg-read); font-size: var(--cc-fs-base); line-height: 1.5; } /* ⚠️ El teléfono y el correo son enlaces, así que NO pueden distinguirse solo por color: es WCAG 1.4.1 nivel A, y es exactamente el fallo que `ux.mjs` cazó en el cuerpo de las notas el 2026-07-29. Van subrayados desde el principio. */ /* ⚠️ `inline-flex` + `min-height` y NO `padding`: el teléfono y el correo son enlaces, o sea objetivos táctiles, y a su alto natural median **22px** contra los 24 que pide WCAG 2.5.8. Lo cazó `a11y.mjs` en la primera corrida de esta página, que es exactamente para lo que está. Se agranda el ÁREA sin tocar el tamaño visible del texto — el mismo criterio con el que se resolvieron los puntos del carrusel y las flechas (8.17). Con `padding` se habría movido la línea base respecto del rótulo de arriba. */ a.cc-contacto-valor { display: inline-flex; align-items: center; min-height: 24px; width: fit-content; color: var(--cc-fg-strong); text-decoration: underline; text-underline-offset: 3px; text-decoration-thickness: 1px; transition: color var(--cc-dur-fast) var(--cc-ease), text-decoration-thickness var(--cc-dur-fast) var(--cc-ease); } a.cc-contacto-valor:hover, a.cc-contacto-valor:focus-visible { color: var(--cc-fg-accent); text-decoration-thickness: 2px; } /* La vía alternativa al formulario. Existe porque una página de conversión no debería tener UNA sola puerta: quien no quiere escribir un formulario hoy se va sin dejar rastro. Son enlaces de navegación, no copia nueva. */ .cc-contacto-alt, .cc-contacto-alt > p { display: flex; flex-wrap: wrap; gap: var(--cc-space-5); margin: 0; } .cc-contacto-alt { margin-top: var(--cc-space-3); } /* El formulario ocupa su columna entera: si se deja a su ancho natural, Gravity Forms colapsa los campos a ~420px y reaparece el hueco que esta rejilla vino a cerrar. */ .cc-contacto-form { width: 100%; } .cc-contacto-form .gform_wrapper { width: 100%; } /* ⚠️ NO se reusa `.cc-form-cierre`, y la tentación era grande porque hace justo esto. Esa clase está escrita para `#brxe-sec127`, que es ISLA OSCURA EN LOS DOS TEMAS, así que pinta con `--cc-fg-on-dark`: blanco fijo. La sección de /contacto/ SÍ voltea con el tema, o sea heredarla daría blanco sobre fondo claro — que es exactamente el fallo A-02 de la auditoría del 2026-08-10, en otra pieza. Y no es teórico: la primera versión de esta página usaba `--cc-fg-on-dark` en sus títulos y enlaces, y `tema.mjs` la tumbó con **1.16:1** en modo claro. Las mismas medidas de caja, con tokens que voltean. ⚠️ El formulario REAL no se puede ver en local (Gravity Forms es de licencia, 8.62), así que esto se verifica contra la maqueta de 16 campos que emite el theme y queda pendiente de confirmar contra staging cuando exista (§12). */ .cc-contacto-form .gform_wrapper, .cc-contacto-form .cc-form-ausente { color: var(--cc-fg-read); } .cc-contacto-form .gform_wrapper .gfield_label { color: var(--cc-fg-strong); font-size: 15px; font-weight: 600; } .cc-contacto-form .gform_wrapper .gfield_description { color: var(--cc-fg-muted); } .cc-contacto-form .gform_wrapper input[type="text"], .cc-contacto-form .gform_wrapper input[type="email"], .cc-contacto-form .gform_wrapper input[type="tel"], .cc-contacto-form .gform_wrapper textarea, .cc-contacto-form .gform_wrapper select { min-height: 48px; /* área de toque cómoda (8.17) */ padding: 12px 14px; background: var(--cc-bg-surface); border: 1px solid var(--cc-border-soft); border-radius: var(--cc-radius-sm); color: var(--cc-fg-strong); font-family: inherit; font-size: 16px; /* 16px evita el zoom automático de iOS al enfocar */ } .cc-contacto-form .gform_wrapper :is(input, textarea, select):focus-visible { outline: 2px solid var(--cc-fg-accent); outline-offset: 2px; } /* ⚠️ El fondo sale de `--cc-green-500` y NO de `--cc-fg-accent`, y la diferencia la encontró `tema.mjs` tumbando esta página con **3.7:1** en modo claro. `--cc-fg-accent` es un token de TEXTO: en claro voltea a `--cc-green-ink` (#067A57, verde oscuro) para poder leerse sobre papel. Usado como FONDO hace justo lo contrario — un botón oscuro con tinta encima. El emparejamiento correcto es el que ya usa el CTA de la portada: verde de marca fijo en los dos temas con tinta encima. `--cc-fg-accent` se queda solo en el anillo de foco, donde su papel de primer plano sí es el correcto. */ .cc-contacto-form .gform_wrapper .gform_footer input[type="submit"], .cc-contacto-form .gform_wrapper .gform_footer button { min-height: 48px; padding: 0 26px; background: var(--cc-green-500); border: 0; border-radius: var(--cc-radius-pill, 999px); color: var(--cc-ink-900); font-family: inherit; font-size: 16px; font-weight: 700; cursor: pointer; } /* ══════════════════════════════════════════════════════════════════════════ /portafolio/ en TELÉFONO: el título del proyecto no cabe y lo recorta la tarjeta ══════════════════════════════════════════════════════════════════════════ Reportado por Ricardo el 2026-08-16 como «las tarjetas muy anchas». La firma medida a 390px es otra y es peor que ancho: título "Tecno Fast | Estrategia Crecimiento Acelerado" 31,5px → 4 líneas, 176px tarjeta li.repeater-item 219px, overflow: hidden El alto de la tarjeta lo fija **Isotope** (la rejilla con filtros, 8.64), así que no crece con el contenido: lo que no cabe se recorta. En pantalla el título aparece cortado por la mitad —«Estrategia» partida— y en la tarjeta siguiente desaparece entero, porque cada una hereda el mismo alto. ⚠️ La cura NO es quitar el `overflow` ni tocar el alto: los dos los escribe Isotope por JS mientras maqueta, así que una regla nuestra o pierde o le desordena la rejilla — que es exactamente lo que costó el gotcha 8.64. Lo que sí es nuestro es el TAMAÑO del título, y a 31,5px estaba escalado para escritorio. Se baja solo bajo 767px y solo dentro de la rejilla de proyectos. La escala sale de los tokens del sistema, no de un número inventado. */ @media (max-width: 767px) { #brx-content .repeater-item :is(h1, h2, h3, h4, h5, .brxe-heading) { font-size: var(--cc-fs-lg); line-height: 1.22; } } /* ========================================================================== NO HAY REGLAS DE MODO CLARO PARA `.cc-tema-estandar`, Y ES DELIBERADO (2026-08-17) Se escribieron y se retiraron el mismo día. Llegaron a dejar `agencia-seo` e `influencer-marketing` con CERO nodos bajo AA en claro volcando superficie y texto al token a la vez — la mitad de la vuelta (solo superficie) las empeoraba de 27 a 35 nodos, que es 8.67 en el otro sentido y vale para cualquier página legacy. Se retiraron porque el resultado no valía: 14 de sus superficies grandes son FOTOS oscuras, así que la página en claro se ve casi igual que en oscuro. Dar el conmutador ahí es el «control que no cambia nada» de 8.68. Sin esas dos páginas en la lista del conmutador, estas reglas no se activarían nunca: código muerto. El detalle está en `ccd_paths_tema_claro_medido()` del child theme. Si algún día se rediseñan, esto se rehace en media hora; lo que no se puede rehacer es el tiempo de quien lea una hoja llena de reglas que no aplican. ========================================================================== */ /* ========================================================================== DOS DEFECTOS DE LOS FORMULARIOS QUE NO SON DEL MODO CLARO (2026-08-17) Los dos estaban en el tema OSCURO, o sea a la vista de cualquiera, y salieron al barrer las páginas legacy. Van juntos porque los dos los pinta Gravity Forms. ========================================================================== */ /* 3.a. El botón de envío daba 1:1 y 1.06:1 — literalmente invisible. Es un botón de contorno: texto en tinta (#0A0A0F), relleno transparente y borde verde, sobre una sección negra. En `/auditoria-seo/` y `/auditoria-gratis/` el MISMO botón sí viene relleno de verde y por eso allí se lee: es la misma pieza con dos tratamientos. Se unifica al relleno, que es el que ya funciona y el del sistema. ⚠️ Y de paso: ese borde venía en `#0BE5A2`, el verde ANTERIOR al cambio de paleta del 2026-07-23. Llevaba ahí desde entonces porque nada mira el color de un borde. Se reconoce el botón por su clase de Gravity Forms y no por su color, por lo mismo que en 8.66: una excepción definida por el color que quiere permitir no protege nada. */ /* ⚠️ El selector incluye `.cc-seo-form` desde el 2026-08-17: al re-esqueletar `/servicios/agencia-seo/`, la página salió de `.cc-tema-estandar` —ya no es una página «estandarizada», es una pieza del sistema— y con ella se fue este arreglo, dejando el botón otra vez ilegible. Un arreglo colgado de la clase de un ESTADO transitorio se pierde el día que ese estado cambia; el formulario, en cambio, sigue siendo el mismo. */ body.cc-tema-estandar #brx-content .gform_button, .cc-seo-form .gform_button { background-color: var(--cc-green-500); border-color: var(--cc-green-500); color: var(--cc-ink-900); } body.cc-tema-estandar #brx-content .gform_button:hover, .cc-seo-form .gform_button:hover { background-color: var(--cc-green-700, #12b98a); border-color: var(--cc-green-700, #12b98a); } /* 3.b. El contador de caracteres (`.charleft`) iba en gris #898989 sobre la banda violeta: 2.95:1, bajo el mínimo de 4.5. Hereda del texto de su banda en vez de traer un gris propio — el gris de un formulario está pensado para fondo blanco, y aquí no hay ninguno. */ body.cc-tema-estandar #brx-content .charleft, body.cc-tema-estandar #brx-content .ginput_counter, .cc-seo-form :is(.charleft, .ginput_counter) { color: inherit; opacity: .78; } /* ========================================================================== LOS RÓTULOS DE MÉTRICA DE agencia-seo: 9px y solapados (M-02 + M-03, 2026-08-17) La auditoría móvil del 2026-08-16 los anotó como DOS hallazgos —«texto bajo 11px» y «13 solapes de texto»— y son UNO: los 18 rótulos («Impresiones», «Sesiones», «Conversiones») van a 9px con `margin-top: -5px`, así que se meten 5px dentro de la cifra que tienen encima. Remedido con el instrumento corregido: 32 solapes, no 13. La primera cuenta subía a 49 porque contaba padre e hijo como si se pisaran. `pendientes.md` los dejó sin tocar «porque no tienen clase común y sería una lista de ids que se pudre». No hacía falta: son el SEGUNDO `.brxe-text-basic` de su div, o sea el que va debajo de la cifra, y eso sí es un selector estructural. Medido: caza los 18 de esta página y CERO en influencer-marketing, /portafolio/, /equipo/ y la de VTEX, que son las otras cuatro con tema estándar. Se sube a `--cc-fs-xs`, que es el valor de la escala; no se estrena ninguno nuevo (§7). Y se quita el margen negativo, que es lo que producía el solape. */ body.cc-tema-estandar #brx-content .brxe-div > .brxe-text-basic + .brxe-text-basic { margin-top: 0; font-size: var(--cc-fs-xs); line-height: 1.35; } /* ========================================================================== /servicios/agencia-seo/ — LOS COMPONENTES QUE EL SISTEMA NO TENÍA (2026-08-17) Re-esqueletado de la página: misma copia, mismas imágenes de contenido, mismo orden de secciones, reconstruida con el vocabulario del sistema. Casi todo reutiliza lo que ya había (`cc-svc-head`, `cc-svc-grid`, `cc-svc-card`, `cc-svc-num`, `cc-band`, `cc-isla-oscura`, `cc-btn-marca`). Lo de abajo es lo que faltaba. El componente de verdad nuevo es UNO: la tarjeta de caso —logo de cliente más tres métricas—, que no existe en ninguna otra pieza. Las demás clases son su familia y el vestido de dos elementos NATIVOS de Bricks (las pestañas y el acordeón), que se re-visten en vez de reconstruirse: funcionan, son accesibles por teclado y el acordeón además emite el `faqSchema`. NINGÚN TOKEN NUEVO: todo sale de las escalas existentes (§7). ========================================================================== */ /* ── LA TABLA DE CASOS ───────────────────────────────────────────────────── Ricardo, 2026-08-17: *"¿no hay una forma más bonita de presentar los casos de éxito SEO?"*. La había, y el motivo de que no lo pareciera era medible: la sección repetía los tres rótulos DIECIOCHO veces y el periodo cinco, con las 18 cifras al mismo tamaño. Eso no es una colección de tarjetas, es una tabla comparativa dibujada como si no lo fuera — y perdía justo lo que un caso de éxito tiene que permitir: comparar. El sistema ya presenta cifras en la portada, y al revés: UNA que manda a 64px y las de apoyo a 20px, con rótulos en versalitas. Aquí se aplica esa jerarquía a una matriz. ────────────────────────────────────────────────────────────────────────── */ .cc-casos { display: flex; flex-direction: column; } .cc-casos__cab, .cc-caso { display: grid; grid-template-columns: minmax(150px, 1.1fr) repeat(3, minmax(0, 1fr)); gap: 16px; align-items: center; } .cc-casos__cab { padding-bottom: 10px; border-bottom: 1px solid color-mix(in srgb, var(--cc-fg) 20%, transparent); } .cc-casos__col { letter-spacing: 0.12em; text-transform: uppercase; } /* La primera columna es la del cliente y su rótulo no aporta —el logo lo dice—, así que se reserva el espacio sin escribirlo. Se deja en el DOM para el lector de pantalla. */ .cc-casos__cab > .cc-casos__col:first-child { visibility: hidden; } .cc-caso { padding: 18px 0; border-bottom: 1px solid color-mix(in srgb, var(--cc-fg) 12%, transparent); } .cc-caso:last-child { border-bottom: 0; } .cc-caso__quien { display: flex; flex-direction: column; gap: 8px; align-items: flex-start; } /* El logo se normaliza por ALTURA y no por ancho: son seis marcas con proporciones muy distintas —un wordmark ancho y un monograma cuadrado en la misma columna— y un tope de ancho recortaría a las anchas. Es la lección de la trust bar de la portada. */ img.cc-caso__logo { height: 26px; width: auto; max-width: 100%; } .cc-caso__periodo { letter-spacing: 0.06em; text-transform: uppercase; } .cc-caso__cifra { font-variant-numeric: tabular-nums; } /* ⚠️ El rótulo de cada celda se oculta VISUALMENTE en escritorio, no con `display:none`. La cabecera de columna ya lo dice al ojo, pero un lector de pantalla no asocia una celda con su columna cuando la «tabla» son divs: sin esto, cada cifra se leería suelta y sin decir de qué es. La técnica de recorte lo saca de la vista y lo deja en el árbol. */ @media (min-width: 768px) { .cc-caso__rotulo { position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip-path: inset(50%); white-space: nowrap; } } /* Bajo 767px la matriz no cabe: la cabecera se retira, cada caso pasa a ser una ficha y los rótulos vuelven a verse. El contenido es el mismo; cambia quién lo etiqueta. */ @media (max-width: 767px) { .cc-casos__cab { display: none; } .cc-caso { grid-template-columns: 1fr 1fr; gap: 14px 20px; padding: 20px 0; } .cc-caso__quien { grid-column: 1 / -1; } } /* ⚠️ Y UNA sola columna bajo 480px. Con dos, a 320px cada celda mide 126px y la cifra más larga —«14.119.000», 8 dígitos a 29px— pide 134: desbordaba la página 34px. Lo cazó `responsive.mjs` a 320, que es el ancho que existe justo para esto (8.7). Se parte la rejilla en vez de encoger la cifra: el número es lo que la sección viene a enseñar, y achicarlo para que quepa es resolver el síntoma. */ @media (max-width: 479px) { .cc-caso { grid-template-columns: 1fr; } } /* ── Las pestañas, re-vestidas ─────────────────────────────────────────── */ .cc-seo-pane { display: grid; grid-template-columns: minmax(min(280px, 100%), 349px) minmax(0, 1fr); gap: clamp(20px, 3vw, 40px); /* ⚠️ `stretch` y no `start`, y esto es la mitad del «se ve desordenado» que reportó Ricardo: con `start` cada columna medía lo suyo —436px la de la imagen y 246 la de la lista— así que la línea divisoria, que es el borde de la segunda, MORÍA a media altura y dejaba un escalón. Estirando, la divisoria recorre la fila entera y las dos columnas se leen como dos mitades de lo mismo. */ align-items: stretch; } .cc-seo-pane > h3 { grid-column: 1 / -1; } /* 349px es el `_widthMax` que traía esa columna en el original: es lo que pone la divisoria cerca de la ilustración en vez de perdida a media página. */ .cc-seo-pane__izq { display: flex; flex-direction: column; gap: 20px; align-items: flex-start; max-width: 349px; } /* ⚠️ LA LÍNEA DIVISORIA entre las dos columnas. El original la traía como un elemento `divider` de Bricks —vertical, 1px, 315px de alto, blanco, oculto en móvil— y se perdió al re-esqueletar. La echó de menos Ricardo, y tenía razón: sin ella las dos columnas se leen como dos bloques sueltos y no como las dos mitades de una misma explicación. Vuelve como BORDE de la segunda columna y no como elemento: hace lo mismo, voltea sola con el tema —un `#ffffff` fijo se vería como una raya negra en claro— y ahorra un nodo por pestaña. Se retira bajo 767px, igual que hacía el original. */ .cc-seo-pane__der { border-left: 1px solid color-mix(in srgb, var(--cc-fg) 22%, transparent); padding-left: clamp(20px, 3vw, 35px); } /* La lista es texto de lectura y la columna daba 755px: por encima de `--cc-measure`, que es el ancho con el que se lee el resto del sitio. Lo cazó `ux.mjs` en cuanto la página entró en esa prueba — el mismo chequeo que corrigió las bajadas de las otras piezas. */ .cc-seo-pane__der > .brxe-text { max-width: var(--cc-measure); } @media (max-width: 767px) { .cc-seo-pane__der { border-left: 0; padding-left: 0; } } /* La ilustración es la misma en las 4 pestañas y no aporta información: se acota para que no gobierne el alto de la fila, que es lo que hacía con su tamaño natural. */ /* 202px es el ancho al que la servía la página anterior (medido sobre su render). A 320 la ilustración —que es la MISMA en las cuatro pestañas y no aporta información— dominaba la columna y empujaba la descripción lejos del texto al que acompaña. */ img.cc-seo-pane__art { width: 100%; max-width: 202px; height: auto; } .cc-seo-pane__lista ul { margin: 0; padding-left: 1.1em; display: grid; gap: 10px; } @media (max-width: 767px) { .cc-seo-pane { grid-template-columns: 1fr; } } /* ── El formulario de auditoría, a dos columnas ────────────────────────── */ .cc-seo-form { display: grid; grid-template-columns: repeat(auto-fit, minmax(min(320px, 100%), 1fr)); gap: clamp(24px, 4vw, 48px); align-items: center; } .cc-seo-form__art img { width: 100%; height: auto; border-radius: var(--cc-radius-lg); } /* ── Los 7 pasos numerados ─────────────────────────────────────────────── */ .cc-seo-pasos { display: grid; grid-template-columns: repeat(auto-fit, minmax(min(280px, 100%), 1fr)); gap: 20px; } .brxe-block.cc-seo-pasos { align-items: stretch; } /* misma trampa que cc-svc-grid */ .cc-seo-paso { display: flex; flex-direction: column; gap: 8px; /* ⚠️ ESTO ES UN PASO DEL MÉTODO, NO UNA PESTAÑA. El 2026-08-25 se bajó este `padding-top` de 16 a 8 creyendo que era la marca de la pestaña activa, y se le dejó un comentario que hablaba de pestañas. No lo era: la barra de la pestaña vive en `.cc-seo-tabs .tab-title`. Restaurado a 16, que es el aire con el que se diseñó la rejilla de siete pasos. Buscar por el VALOR y no por el componente es cómo se edita la regla equivocada. */ padding-top: 16px; border-top: 2px solid var(--cc-fg-accent); } /* ── Ritmo vertical y arreglos de la revisión visual de agencia-seo (2026-08-17) ── Los cuatro salieron de MIRAR la página después de que las 10 suites dieran verde. Es el mismo patrón de siempre: lo que no se le pregunta a una suite, no falla. */ /* 1. El aire entre el titular de sección y su contenido. El contenedor de Bricks es un flex column con `gap: normal` —o sea cero—, así que los 9 titulares quedaban pegados a su grilla. El valor sigue la escala de la portada. */ .cc-seo-cont { gap: clamp(22px, 3vw, 36px); } /* Y la MEDIDA DE LECTURA. Los párrafos sueltos de una sección —la banda del 40 %, la bajada del hero— heredaban el ancho del contenedor (1180px) y quedaban muy por encima de `--cc-measure`, que es el valor con el que se lee el resto del sitio. Solo alcanza a los hijos DIRECTOS: dentro de una tarjeta la columna ya acota sola. */ .cc-seo-cont > .brxe-text { max-width: var(--cc-measure); } /* 2. La maqueta del panel de pestaña. ⚠️ La rejilla NO va en `.tab-pane` sino en un bloque hijo, y el motivo es de cascada moderna: Bricks emite `.brxe-tabs-nested .tab-pane.brx-open{display:block!important}` DENTRO de `@layer bricks`, y una `!important` dentro de una capa le gana a una `!important` sin capa por mucha especificidad que tenga — la prioridad de capas se INVIERTE para las importantes. Se probó con (0,2,0), con (0,4,0) y con `!important`: las tres pierden. El panel se queda con su `display` y la maqueta vive en un hijo nuestro. */ /* Las 4 tarjetas de «Más allá del SEO» caben en UNA fila: con el mínimo de 320px de `cc-svc-grid` entraban tres y la cuarta quedaba sola, que se lee como un descuadre y no como una decisión. Son cuatro conceptos hermanos (SXO, GEO, ESO, AEO), así que la fila de cuatro también es lo correcto semánticamente. */ .cc-seo-cuatro { grid-template-columns: repeat(auto-fit, minmax(min(240px, 100%), 1fr)); } /* ⚠️ Los rótulos de pestaña, TODOS a la misma altura. Medidos: 66, 66, 66 y 96px —el cuarto trae un `
` en la copia y ocupa dos líneas—, así que la fila quedaba dentada y los cuatro indicadores de pestaña activa aparecían a alturas distintas. Es la otra mitad del «desordenado». Se estiran todos al más alto en vez de recortar el que sobra: el salto de línea está en el contenido y ese no se toca (§5). */ .cc-seo-tabs .tab-menu { align-items: stretch; } .cc-seo-tabs .tab-title { display: flex; align-items: flex-start; } /* ── LA FILA DE PESTAÑAS PARECE UNA FILA DE PESTAÑAS (2026-08-25) ────────── Ricardo: *«no sé, se ve simple/feo/desordenado»* sobre esta sección. Mirado a tamaño real, eran cuatro cosas concretas y ninguna es de contenido: 1. NO HABÍA FILA. Cuatro textos sueltos flotando bajo el H2, sin nada que los agrupe ni línea base común: no se leían como un control, se leían como una lista suelta. Ahora una regla recorre el ancho y las pestañas se apoyan en ella — que es lo que convierte cuatro palabras en un selector. 2. LA MARCA DE LA ACTIVA ESTABA ARRIBA Y DESPEGADA. Con `border-top` quedaba a media altura entre el titular y el rótulo, así que se leía como una raya suelta bajo el H2 y no como «esta es la pestaña abierta». Pasa ABAJO, montada sobre la regla: es el patrón que todo el mundo reconoce y de paso desaparece el hueco. 3. LA SEGUNDA LÍNEA DEL CUARTO RÓTULO IBA INDENTADA. «(Linkbuilding)» aparecía centrada respecto de su primera línea, que es lo que más descuadraba la fila. El `
` está en la copia y no se toca (§5); lo que se corrige es la alineación del texto. 4. LA CITA FLOTABA. Es la voz del cliente y lo único distinto entre las cuatro pestañas, pero iba pegada al borde y con peso de titular, compitiendo con el H2 de la sección. ────────────────────────────────────────────────────────────────────────── */ .cc-seo-tabs .tab-menu { gap: clamp(18px, 2.4vw, 34px); border-bottom: 1px solid color-mix(in srgb, var(--cc-fg) 16%, transparent); } .cc-seo-tabs .tab-title { /* La marca de la activa vive abajo: se reserva su grosor en todas para que ninguna salte de posición al abrirse. */ padding: 0 0 12px; border-top: 0; border-bottom: 2px solid transparent; text-align: left; transition: color var(--cc-dur-fast, .18s) var(--cc-ease-out, ease), border-color var(--cc-dur-fast, .18s) var(--cc-ease-out, ease); } .cc-seo-tabs .tab-title.brx-open { border-bottom-color: var(--cc-fg-accent); } /* El rótulo inactivo se apaga un punto más, para que la activa gane sin subir de tamaño. */ .cc-seo-tabs .tab-title:not(.brx-open) { color: var(--cc-fg-muted); } .cc-seo-tabs .tab-title:hover { color: var(--cc-fg); } /* La cita: se acerca a su panel, pierde el peso de titular y gana una barra de acento que la marca como voz del cliente. No cambia una palabra. */ .cc-seo-pane > h3 { margin: 4px 0 6px; padding-left: 14px; border-left: 3px solid var(--cc-fg-accent); font-weight: 600; } /* 3. ⚠️ Aquí había un `white-space: nowrap` para que «Enlaces externos (Linkbuilding)» no cayera en dos líneas. Se retiró: el salto NO era del ancho, está EN LA COPIA — el rótulo trae un `
` literal desde la página anterior. La regla no hacía nada y además intentaba discutirle a un contenido que esta tanda se comprometió a respetar verbatim. Si algún día molesta, se quita el `
` del contenido, no con CSS. */ /* 4. La FAQ no parecía una FAQ: cinco titulares sueltos, sin separadores y sin ninguna señal de que se abren. Un acordeón que no se anuncia como tal no lo usa nadie. */ .cc-seo-faq > .brxe-block { border-bottom: 1px solid rgba(255, 255, 255, 0.12); } .cc-seo-faq .accordion-title-wrapper { padding: 6px 0; } .cc-seo-faq .accordion-title-wrapper::after { content: ""; flex: 0 0 auto; width: 10px; height: 10px; margin-left: 16px; border-right: 2px solid var(--cc-fg-accent); border-bottom: 2px solid var(--cc-fg-accent); transform: rotate(45deg); transition: transform var(--cc-dur-fast, .18s) var(--cc-ease-out, ease); } .cc-seo-faq > .brx-open .accordion-title-wrapper::after { transform: rotate(-135deg); } html[data-theme="light"] .cc-seo-faq > .brxe-block { border-bottom-color: rgba(32, 30, 44, 0.16); } /* ── DOS SECCIONES A FORMATO REGISTRO (2026-08-25) ───────────────────────── Ricardo, al ver la página con las reglas de las 4 hijas aplicadas por accidente: *«no me disgustaba cómo se veían unas partes con el tema de los otros servicios»* — «Más allá del SEO» y «Somos Agencia Full Service»—. Tenía razón, así que se hace **a propósito** y solo en esas dos, en vez de dejar que 25 reglas ajenas se apliquen enteras. Por qué encajan y las demás no: son grupos de hermanos sin jerarquía interna —cuatro disciplinas, cinco capacidades— y sin imagen que aporte. Es la forma para la que se diseñó la entrada de registro en las hijas (8.93). La apertura y la matriz de casos NO se tocan: son lo único que solo puede ser de esta página. ⚠️ UNA DIFERENCIA DELIBERADA CON EL REGISTRO DE LAS HIJAS: allí la descripción se oculta y aparece al hover, y allí funciona porque cada entrada lleva a una página de servicio. Aquí la descripción ES el contenido —«SXO (Search Experience Optimization)» sin su línea no dice nada— y en táctil no hay hover. Se queda visible siempre. Copiar un patrón incluye decidir qué parte de él NO aplica. ────────────────────────────────────────────────────────────────────────── */ .cc-seo-registro { grid-template-columns: 1fr; gap: 0; border-bottom: 1px solid var(--cc-rule-on-dark); } .cc-seo-registro > .cc-svc-card { position: relative; background: none; border: 0; /* El mismo hairline del registro de las hijas: `--cc-rule-on-dark` voltea solo con el tema, que es lo que 8.96 dejó resuelto. */ border-top: 1px solid var(--cc-rule-on-dark); border-radius: 0; /* Sin fondo ni radio, una sombra dibuja el contorno de una caja que no existe: es 8.97, y se apaga aquí en vez de esperar a que la herede otro estado. */ box-shadow: none; padding: 22px 0 22px 38px; display: flex; flex-direction: column; gap: 8px; transition: border-top-color var(--cc-dur-base) var(--cc-ease-out); } .cc-seo-registro > .cc-svc-card:hover { transform: none; box-shadow: none; /* El acento de la fila apuntada sale de SU unidad cuando la tiene —las 5 de Full Service llevan una cada una— y del verde de marca cuando no. */ border-top-color: var(--cc-unidad, var(--cc-fg-accent)); } /* ⚠️ Y LO MISMO OTRA VEZ PARA EL MODO CLARO, que es 8.32 y no un descuido (2026-08-26, gotcha 8.110). Las dos reglas de arriba son (0,2,0); las de tarjeta del modo claro —`html[data-theme="light"] .cc-svc-card`, con su fondo blanco, su borde teñido de unidad y su sombra de elevación— son (0,2,1). En oscuro nadie compite y el registro se ve como debe; **al voltear a claro ganaban ellas** y cada fila volvía a ser una caja blanca con sombra y una línea azul de reposo que se lee como un hover pegado. Lo reportó Ricardo el 2026-08-26 con dos capturas: «se mantiene ese color azul sin tener el mouse encima» y «claramente se ve el rectángulo con la sombra». ⚠️ Y NO es que la regla del registro estuviera mal: es que el registro de las hijas sí está protegido —su selector lleva `body.cc-servicios…:not(.cc-maqueta-propia)`, que suma especificidad de sobra— y `agencia-seo` queda FUERA de ese `:not()` por llevar `cc-maqueta-propia`. O sea el arreglo de 8.97 nunca alcanzó a esta página, y el bug que Ricardo reportó el 2026-08-24 seguía vivo aquí, en otra pieza. */ html[data-theme="light"] .cc-seo-registro > .cc-svc-card { background: none; border: 0; border-top: 1px solid var(--cc-rule-on-dark); border-radius: 0; box-shadow: none; } html[data-theme="light"] .cc-seo-registro > .cc-svc-card:hover { box-shadow: none; border-top-color: var(--cc-unidad, var(--cc-fg-accent)); } /* ⚠️ ESTAS ENTRADAS NO VAN NUMERADAS, y quitarlo fue una corrección de Ricardo el mismo día: *«¿no está mal o no se ve raro que todo esté enumerado?»*. Tiene razón, y el argumento es de página, no de sitio: Con el registro puesto, esta página tenía TRES listas numeradas y **solo una está ordenada de verdad** — «Nuestro método SEO paso a paso», que es una secuencia y donde el `01–07` dice algo cierto. Las otras dos son grupos de hermanos: cuatro disciplinas paralelas y cinco capacidades. Numerarlas insinúa un orden que no existe y se lee como ranking (¿SXO es la primera y AEO la cuarta?). Y el daño de fondo es el otro: usar el mismo recurso para las tres lo VACÍA. Cuando la única lista que sí es una secuencia comparte marcador con dos que no lo son, el lector deja de leer los números como información. Un recurso estructural tiene que codificar algo verdadero; si no, es decoración que además miente. (Las 4 hijas viejas SÍ numeran sus servicios, que tampoco son secuencia. Ahí no colisiona con nada, y su patrón no se toca: la decisión de aquí es de esta página.) En su lugar queda una marca de UNIDAD: conserva el color del área —que es taxonomía real de la casa— sin afirmar un orden. Y en «Más allá del SEO» el rótulo ya es el marcador: `SXO`, `GEO`, `ESO`, `AEO` no necesitan nada delante. */ .cc-seo-registro > .cc-svc-card::before { content: ""; position: absolute; left: 0; top: 32px; width: 18px; height: 2px; border-radius: 2px; background: var(--cc-unidad, var(--cc-fg-accent)); opacity: .9; } /* El título de la entrada deja de ser un titular de tarjeta y pasa a ser el rótulo de una fila: mismo tamaño de lectura, sin la escala grande que pedía la caja. */ .cc-seo-registro .cc-svc-card__title { font-size: var(--cc-fs-lg); line-height: var(--cc-lh-snug); } .cc-seo-registro .cc-svc-card__texto { max-width: var(--cc-measure); } @media (min-width: 900px) { /* En pantalla ancha la fila se abre en dos: el rótulo a la izquierda y su descripción a la derecha. Es lo que Ricardo señaló como «mostrándose a la derecha», y de paso acorta la línea de lectura a la mitad del ancho disponible. */ .cc-seo-registro > .cc-svc-card { display: grid; grid-template-columns: minmax(0, 30ch) minmax(0, 1fr); column-gap: clamp(28px, 4vw, 64px); align-items: baseline; } /* ⚠️ PERO NO TODAS LAS ENTRADAS TIENEN RÓTULO. Las cinco de «Full Service» son solo texto —su copia ya empieza por el nombre del área: «Performance Marketing: …»—, así que sin esto su párrafo caía en la columna del rótulo, encajonado a 30ch, con la segunda columna vacía a la derecha. Se detecta la ausencia con `:has()` en vez de inventar una clase: la estructura ya lo dice. */ .cc-seo-registro > .cc-svc-card:not(:has(> .cc-svc-card__title)) > .cc-svc-card__texto { grid-column: 1 / -1; } } /* ── LA APERTURA QUE ARGUMENTA CON LA EVIDENCIA (2026-08-25) ─────────────── Pedido de Ricardo: *«que sea único y siga el tema de la página»*. Lo segundo lo daba ya el vocabulario del sistema; lo primero no, y la medición lo decía: la página compartía TODO con `/servicios/diseno/` y no tenía un solo rasgo que solo pudiera ser suyo. Lo único que ninguna plantilla puede copiar de esta página son sus **18 cifras medidas de 6 clientes con nombre**. Estaban en la segunda sección, después de una ilustración de stock de un navegador. Ahora el titular y la matriz son UNA sola apertura, así que sobre el pliegue hay resultados con nombre de cliente en vez de un mockup genérico. ⚠️ UNA sección y no dos con el mismo fondo, y no es un detalle de implementación: el trinquete de `ux.mjs` exige que ninguna pareja de secciones consecutivas comparta fondo —el umbral salió medido de las 7 piezas—, y dos oscuras seguidas se ven exactamente como el tramo plano que Ricardo llamó «sosa». Una sección no tiene pareja. ────────────────────────────────────────────────────────────────────────── */ .cc-seo-apertura .cc-seo-evidencia { width: 100%; display: flex; flex-direction: column; gap: var(--cc-space-md, 24px); /* La regla separa el argumento de su prueba. Es el mismo hairline de la matriz, así que el bloque entero se lee como una sola pieza de lectura y no como dos cosas pegadas. */ margin-top: var(--cc-space-lg, 40px); padding-top: var(--cc-space-lg, 40px); border-top: 1px solid color-mix(in srgb, var(--cc-fg) 12%, transparent); } /* ⚠️ El H1 se mide en CARACTERES, no en píxeles, y el defecto era de caja y no de copia: medido a 1440 antes de esto, «Agencia SEO en Chile / SEO Técnico, Contenidos & / eCommerce» caía en CUATRO líneas con la última colgando sola. `balance` reparte, y la medida evita que en pantallas anchas se estire a una línea larguísima. */ .cc-seo-h1 { max-width: 19ch; text-wrap: balance; } /* Los titulares de sección, con el mismo criterio que el H1: medida en caracteres y equilibrio. Sin esto «Servicios SEO completos para tu negocio» deja «negocio» solo en la segunda línea, que es el mismo defecto de caja que tenía el H1. */ .cc-seo-cont .cc-svc-head > .brxe-heading { max-width: 26ch; text-wrap: balance; } /* Las cifras de la matriz mandan sobre el resto de la apertura: es lo que la sección viene a demostrar. No se estrena tamaño — se sube un escalón de la escala existente. */ .cc-seo-apertura .cc-caso__cifra { font-size: var(--cc-fs-h3); } /* ── LA MATRIZ DEJA DE SER UNA PLANILLA (2026-08-25) ─────────────────────── Ricardo: *«toda esta parte no me gusta»*, sobre los casos y las pestañas. Medido, la matriz tenía cuatro defectos y ninguno es de contenido — el contenido se deja intacto: 1. LAS TRES CIFRAS AL MISMO PESO. Una fila mezcla un ABSOLUTO (impresiones) con dos PORCENTAJES, y los tres iban al mismo tamaño: gana el número más largo, no el que argumenta. `2.782.000` pesaba más que `121,80%` por tener más dígitos. El sistema ya resuelve esto en la portada —UNA cifra manda y las de apoyo bajan—, y el propio comentario de `.cc-casos` decía que aplicaba esa jerarquía… pero no estaba aplicada: las tres celdas salían con el mismo tamaño. 2. QUÉ COLUMNA MANDA. Sesiones, y es una regla UNIFORME, no elegir la mejor cifra de cada cliente: sesiones es tráfico orgánico, que es lo que una agencia SEO vende. Con una regla por fila la tabla dejaría de ser comparable, que es su única razón de ser. 3. SEIS FILAS SIN RITMO. Nada ayudaba a seguir una fila de izquierda a derecha en 1180px. 4. EL PERIODO COMPITIENDO con el logo del cliente en la primera columna. ⚠️ Lo que NO se toca, porque es contenido y no presentación: que Palmers y MK repitan `121,80%` y `59%` exactos (REVISAR-DATO abierto desde el 2026-08-17), que los porcentajes no digan si son variación, y el logo de MK, que es un cuadrado gris ilegible por el archivo. Los tres están en `pendientes.md`. ────────────────────────────────────────────────────────────────────────── */ /* ⚠️ EL TAMAÑO Y EL COLOR DE LAS CIFRAS NO ESTÁN AQUÍ, y el intento fallido queda escrito para que nadie lo repita: Bricks emite la tipografía por elemento como `#brxe-{font-size:...}`, un selector de ID (1,0,0), así que `.cc-caso > .cc-caso__celda:nth-child(3) .cc-caso__cifra` —(0,3,0)— NO aplica (8.1). Se declara en `gen-agencia-seo-v3.py`, que es donde ya se declara el tamaño. Aquí solo queda lo que el ID no gobierna: el interletrado de la cifra que manda. */ .cc-caso__cifra--manda { letter-spacing: -0.02em; } /* ⚠️ AQUÍ HUBO UNA CEBRA Y SE RETIRÓ EL MISMO DÍA (2026-08-25), por dos razones y las dos se vieron mirando, no midiendo: 1. CAÍA EN LAS FILAS EQUIVOCADAS. La regla era `:nth-child(even)` con el comentario «así la primera queda limpia»… pero `.cc-casos__cab` es el primer hijo del contenedor, así que desplaza la paridad y el teñido caía en la 1ª, 3ª y 5ª — exactamente lo contrario de lo escrito. Un comentario que afirma lo que la regla no hace es peor que no tener comentario. 2. Y AUNQUE CAYERA BIEN, SOBRA. Con la cifra de sesiones en acento verde, la fila ya tiene un ancla para el ojo; el teñido solo añadía barras flotantes que no alineaban con la cabecera. Los hairlines que ya tenía la tabla hacen el trabajo. Se deja escrito para que nadie la reponga «para dar ritmo». */ /* Las columnas numéricas se alinean a la DERECHA, cabecera incluida. Es lo que hace comparables tres columnas de cifras de largo distinto —`2.782.000` contra `470.700`— y de paso recoge el vacío que quedaba entre la última cifra y el borde de la tabla: los números terminaban donde acababa su texto, no donde acaba su columna. Con `tabular-nums`, que la tabla ya usa, las unidades quedan una debajo de otra. */ /* ⚠️ HACE FALTA `align-items`, NO BASTA `text-align`, y la primera versión se quedó a medias: la cabecera se alineó y las cifras no. Los bloques de Bricks son FLEX EN COLUMNA, así que cada hijo se encoge a su contenido y queda pegado al inicio del eje — `text-align` se aplica dentro de una caja que ya mide lo mismo que su texto, o sea no hace nada. Lo que mueve la caja es el alineamiento del flex. */ .cc-caso > .cc-caso__celda { align-items: flex-end; text-align: right; } .cc-casos__cab > .cc-casos__col:not(:first-child) { text-align: right; } @media (max-width: 767px) { /* En fichas ya no hay columnas que comparar: vuelve a la izquierda, con su rótulo. */ .cc-caso > .cc-caso__celda { align-items: flex-start; text-align: left; } } /* El periodo deja de competir con el logo: se separa de él y baja de peso. Es dato de contexto, no identidad del cliente. */ .cc-caso__periodo { opacity: .72; } .cc-caso__quien { gap: 12px; } @media (max-width: 767px) { /* En fichas, la cifra que manda no puede ser la mitad de alta que la ficha: se acota. */ .cc-caso > .cc-caso__celda:nth-child(3) .cc-caso__cifra { font-size: var(--cc-fs-h3); } .cc-caso { padding-inline: 0; background: none; } .cc-caso:nth-child(even) { background: none; } } /* ── LAS PESTAÑAS: LA COLUMNA IZQUIERDA DEJA DE ESTAR VACÍA (2026-08-25) ─── Medido: la ilustración ocupa 202×202 px en una columna de 349, con la descripción caída al fondo — la mitad izquierda se lee como un hueco con dos cosas en los extremos, mientras la derecha lleva cuatro viñetas largas. Y la ilustración es **la misma en las cuatro pestañas** (medido: `imgs-pestanas-seo.webp` ×4), así que no informa de nada: si sirve igual para «SEO técnico» que para «Linkbuilding», no dice nada de ninguno. No se retira —es contenido— pero deja de gobernar la columna: baja a 132px y se agrupa con la descripción a la que acompaña, en vez de flotar arriba con el texto al fondo. ⚠️ Y queda dicho lo que NO arregla el CSS: la ilustración está FUERA DE PALETA (lilas y azules claros que no son ningún token). Las 4 imágenes de tarjeta de esta misma página se retiñeron el 2026-08-17 con `tools/img/seo-tarjetas-duotono.py`; esta no, porque es un icono plano y la receta es para foto. Hace falta una variante, y eso es asset. ────────────────────────────────────────────────────────────────────────── */ /* ⚠️ `img.cc-seo-pane__art` sigue aquí y en el rediseño YA NO SE USA: la ilustración se retiró del panel el 2026-08-25. La regla se conserva porque `/lab-agencia-seo/` —la copia del re-esqueleto de agosto, que está para comparar— sí la lleva. Si esa copia se retira, esta regla se va con ella. */ img.cc-seo-pane__art { max-width: 132px; } /* ── LA SECCIÓN DE PESTAÑAS DEJA DE VERSE DESORDENADA (2026-08-25) ───────── Ricardo: *«lo de "Servicios SEO completos para tu negocio" lo encuentro muy desordenado, además la imagen la encuentro innecesaria»*. Medido, eran tres cosas distintas: 1. LA ILUSTRACIÓN. Retirada en el generador — era la misma en las 4 pestañas. 2. LA COLUMNA IZQUIERDA quedaba con la descripción caída al fondo, porque el grupo se repartía a los extremos de una columna estirada. Ahora arranca ARRIBA, a la misma altura que la primera viñeta de su derecha: las dos mitades empiezan juntas, que es lo que hace que se lean como una sola explicación. 3. LA BARRA DE LA PESTAÑA ACTIVA vivía a 16px de su propio rótulo, así que no se leía como suya sino como una raya suelta encima de la fila. A 8px es del rótulo. ────────────────────────────────────────────────────────────────────────── */ /* ── EL PANEL SE APILA: CITA · DESCRIPCIÓN · LISTA A DOS COLUMNAS (2026-08-25) ── Ricardo, sobre esta sección: *«se ve simple/feo/desordenado»*, y tras arreglar la fila de pestañas seguía sobrando algo — **aire**. Medido: la columna izquierda llevaba cuatro líneas de descripción y luego ~200px de hueco, porque su alto lo mandaba la lista de la derecha. Dos columnas de peso muy distinto no son dos columnas: son una columna y un margen ocupado. Ahora las tres piezas se apilan y cada una usa el ancho que le corresponde: la cita abre, la descripción la sigue como entradilla acotada a la medida de lectura, y la lista —que es lo que más pesa— baja a todo el ancho en DOS columnas. La sección encoge y no queda ni un hueco sin función. ⚠️ La divisoria vertical se retira con la rejilla: era el borde de la segunda columna, y sin dos columnas no separa nada. Vuelve a ser lo que ya avisaba su comentario original — un elemento que existe para explicar una relación— y esa relación ahora la explica el orden. */ .cc-seo-pane { grid-template-columns: 1fr; gap: clamp(14px, 1.6vw, 22px); } .cc-seo-pane__izq { justify-content: flex-start; gap: 16px; /* Entradilla: texto de lectura, acotado como el resto del sitio. */ max-width: var(--cc-measure); } .cc-seo-pane__der { border-left: 0; padding-left: 0; } /* La lista a dos columnas. `auto-fit` con un mínimo de 340px: a 1180 entran dos, y en cuanto no caben vuelve sola a una sin necesidad de otra consulta de medios. El hueco entre columnas es mayor que el de filas para que no se lean como una sola lista. */ .cc-seo-pane__lista ul { /* ⚠️ DOS COLUMNAS FIJAS, no `auto-fit`. Con `auto-fit` y un mínimo de 340px a 1180 de ancho entran TRES, y las listas de estas pestañas tienen CUATRO puntos: la cuarta caía sola en una segunda fila. Es exactamente el descuadre 3+1 que ya se corrigió en las tarjetas de «Más allá del SEO» unas líneas más arriba — cuando el número de elementos es conocido y pequeño, la rejilla se declara, no se negocia. */ grid-template-columns: repeat(2, minmax(0, 1fr)); gap: 12px 48px; } @media (max-width: 900px) { .cc-seo-pane__lista ul { grid-template-columns: 1fr; } } /* ⚠️ Y HAY QUE SOLTAR LA MEDIDA DEL CONTENEDOR, o las dos columnas no caben. La regla `.cc-seo-pane__der > .brxe-text { max-width: var(--cc-measure) }` se puso el 2026-08-17 porque `ux.mjs` cazó la lista a 755px, por encima del ancho con el que se lee el resto del sitio. Sigue siendo correcta para UNA columna y deja de serlo para dos: la medida de lectura es una propiedad de la LÍNEA, no del bloque, y aquí cada columna mide ~566px — por debajo del límite— mientras el bloque mide 1180. Cap al bloque y la rejilla no puede partir; cap por columna y se lee igual de bien en la mitad de alto. */ /* ⚠️ La especificidad importa aquí: quien pone el tope es `.cc-seo-pane__der > .brxe-text` (0,2,0), así que `.cc-seo-pane__lista` a secas (0,1,0) NO lo levanta — medido, la lista seguía a 700px. Se encadenan las dos clases sobre el mismo elemento, que es lo mínimo para ganar sin inventar un `!important`. */ .cc-seo-pane__der > .brxe-text.cc-seo-pane__lista { max-width: none; /* ⚠️ Y NO BASTA CON QUITAR EL TOPE: hay que estirar. Es la MISMA trampa que en la tabla de casos — los bloques de Bricks son flex, así que el hijo se encoge a su contenido y se queda en 700px aunque su `max-width` sea `none`. Medido en el árbol: contenedor 1180, lista 700, `max-width: none`. Dos veces el mismo tropiezo en la misma tanda: en este theme, ante «no ocupa el ancho», mirar el FLEX antes que el `max-width`. */ width: 100%; align-self: stretch; } .cc-seo-pane__lista li { max-width: var(--cc-measure); } /* La cita del cliente deja de competir con el H2 de la sección. Sigue siendo el elemento que abre el panel —es lo único distinto entre las cuatro pestañas y por eso se queda arriba— pero baja de peso y gana aire por debajo. */ .cc-seo-pane > h3 { margin-bottom: 4px; } /* Las viñetas eran los puntos por defecto del navegador. Pasan al sistema: un guion de acento, que es lo que usa el resto del sitio en sus listas. No cambia una palabra. */ .cc-seo-pane__lista ul { list-style: none; padding-left: 0; } .cc-seo-pane__lista li { position: relative; padding-left: 22px; } .cc-seo-pane__lista li::before { content: ""; position: absolute; left: 0; top: 0.68em; width: 10px; height: 2px; background: var(--cc-fg-accent); border-radius: 2px; } @media (max-width: 767px) { /* En móvil la matriz se convierte en fichas (ver `.cc-caso` arriba) y el bloque crece mucho: la separación se acorta para que el CTA no quede a dos pantallas del titular. */ .cc-seo-apertura .cc-seo-evidencia { margin-top: var(--cc-space-md, 24px); padding-top: var(--cc-space-md, 24px); } .cc-seo-apertura .cc-caso__cifra { font-size: var(--cc-fs-h4); } } /* ========================================================================== LA CAPA DE TEMA ESTÁNDAR, AMPLIADA A BOTONES, FAQ Y TARJETAS (2026-08-17) Ricardo, tras revisar el re-esqueleto de `/servicios/agencia-seo/`: *«deja SEO como estaba, pero ¿no se puede dejar de tal manera con el tema de la página? ejemplo botones, preguntas frecuentes, tarjetas»*. La respuesta no es un mecanismo nuevo: es exactamente lo que `.cc-tema-estandar` viene a hacer desde el 2026-08-10 —«estandarizar, NO rediseñar»— solo que la capa cubría familia tipográfica, radios y duraciones, y se quedaba corta en esos tres componentes. Medido antes de escribir: · los botones tenían TRES tratamientos en la misma página: relleno verde con radio de píldora, contorno con el verde VIEJO #0BE5A2, y el de Gravity Forms con radio 19px y 17,25px de letra, escapándose de la capa entera; · el acordeón de la FAQ no tenía NADA: cinco titulares sueltos, sin separadores y sin ninguna señal de que se abren; · las tarjetas de «Más allá del SEO» no tenían superficie ni radio, y una traía un borde azul #0081C6 de la paleta anterior. ⚠️ Se toca la capa de SISTEMA y no la maqueta: ni un padding, ni un margin, ni un width que mueva una caja de sitio. Es la regla del encargo original de esta clase, y es lo que hace que esto valga para las 5 páginas de la lista y no solo para SEO. ========================================================================== */ /* 1. LOS BOTONES, uno solo. El de contorno pasa al verde vigente —el #0BE5A2 es de antes del 2026-07-23 y llevaba ahí desde entonces porque nada mira el color de un borde— y el de Gravity Forms entra en la misma forma que los demás en vez de traer la suya. */ body.cc-tema-estandar #brx-content :is(.bricks-button, .brxe-button, .gform_button) { border-radius: var(--cc-radius-pill, 999px); font-family: var(--cc-font-sans); font-weight: 700; } body.cc-tema-estandar #brx-content :is(.bricks-button, .brxe-button):not([class*="bricks-background"]) { border-color: var(--cc-fg-accent); } body.cc-tema-estandar #brx-content .gform_button { font-size: var(--cc-fs-sm); padding: 12px 28px; } /* 2. LA FAQ. Aquí la capa NO dibuja nada: alinea y colorea lo que la página ya trae. ⚠️ ESTA REGLA EMPEZÓ DIBUJANDO UN CHEVRON Y ESE ERA EL BUG (Ricardo, 2026-08-17: *«en seo el preguntas frecuentes se ve mal»*). Se veían dos por fila: el `i.ion-ios-arrow-down` nativo —gris y pegado al final del texto, o sea a una x distinta en cada fila, porque sigue el ancho del titular— y el verde que añadía un `::after` nuestro, al borde derecho. El origen tiene nombre: la afirmación «el acordeón no tenía NADA» se midió sobre la página RE-ESQUELETADA, que se revirtió horas después. Medir una versión y escribir la regla para otra es 8.62 con otro disfraz. ⚠️ Y EL PRIMER ARREGLO TAMPOCO BASTÓ, que es la parte que vale la pena recordar. Se hizo condicional —dibujar solo si no hay `> .brxe-icon`— y el inventario decía que `/agencia-vtex-partner/` no tenía icono, así que la rama de dibujo parecía necesaria. **El inventario estaba mal: preguntaba solo por HIJOS DIRECTOS.** VTEX usa el acordeón clásico de Bricks, con otra estructura —`.accordion-title-wrapper > .accordion-title > h3 + i.expanded + i`—, o sea dos iconos anidados un nivel más abajo. Sí tenía chevron; el detector no lo veía. Y como ahí el envoltorio es `display: block` y no `flex`, el `::after` no se iba a la derecha: caía a la línea siguiente, contra el margen izquierdo, como una marca verde debajo de cada pregunta. Lo delata que la medición daba VERDE: contaba «0 dobles» porque su idea de «nativo» era la equivocada. Un chequeo solo prueba la pregunta que sabe hacer (8.53). Remedido con la estructura real, las 3 páginas con FAQ de esta lista YA TRAEN chevron: `agencia-seo` 5/5, `influencer-marketing` 4/4 y `agencia-vtex-partner` 7/7. O sea la rama de dibujo no la necesitaba nadie: era código especulativo, y encima rompía. Se borró. **La capa estandariza lo que hay; cuando cree que falta algo, conviene mirar otra vez.** */ body.cc-tema-estandar #brx-content .brxe-accordion-nested > .brxe-block { border-bottom: 1px solid color-mix(in srgb, var(--cc-fg) 12%, transparent); } body.cc-tema-estandar #brx-content .accordion-title-wrapper { padding: 6px 0; } /* El chevron se va al borde derecho y toma el acento. `margin-left: auto` es el arreglo de verdad y no el color: sin él el icono queda donde termine el texto, así que cada fila lo tiene a una x distinta y la columna no existe. ⚠️ NO se le pone `transform`: Bricks ya lo rota al abrir —medido, pasa a `matrix(-1,0,0,-1,0,0)`, o sea 180°— y una rotación nuestra encima se sumaría a la suya. Los dos selectores son las dos estructuras de acordeón que Bricks emite, no una duplicación: `> .brxe-icon` es el anidado (SEO, influencer) y `.accordion-title .icon` el clásico (VTEX), donde además hay dos iconos —abierto y cerrado— y por eso se colorean los dos. VTEX ya los alineaba solo, así que ahí esto es solo color. */ body.cc-tema-estandar #brx-content .accordion-title-wrapper > .brxe-icon { margin-left: auto; color: var(--cc-fg-accent); } body.cc-tema-estandar #brx-content .accordion-title .icon { color: var(--cc-fg-accent); } /* 3. LAS TARJETAS con imagen reciben la superficie del sistema. Se reconocen por ESTRUCTURA —un bloque cuyo hijo directo es una imagen— y no por una lista de ids, que es lo que `pendientes.md` lleva advirtiendo que se pudre. `:has()` ya se usa en esta hoja (`body.blog .brxe-section:has(.cc-postgrid)`), así que no estrena técnica. ⚠️ Y pide imagen **Y TEXTO** como hijos directos, no solo imagen. La primera versión pedía solo la imagen y Ricardo lo cazó en el acto —*«se ve mal SEO»*—: encajonaba la ilustración del hero y la del formulario, que son envoltorios de una imagen sola, no tarjetas. Medido: de 7 coincidencias a 5 en agencia-seo, y las dos que se van son justamente las de 1100px y 550px. Una tarjeta es una imagen CON algo que decir al lado; un bloque con una imagen dentro es cualquier cosa. ⚠️ Y el borde sale del token: una de estas tarjetas traía #0081C6, azul de la paleta anterior, que sobre el fondo actual no pertenece a nada. ⚠️⚠️ TERCERA CONDICIÓN, Y ES LA QUE FALTABA: la tarjeta tiene que ser MIEMBRO DE UN CONJUNTO. «Imagen + texto» seguía encajonando cosas que no son tarjetas, y Ricardo cazó dos el 2026-08-17: el `
` de `/portafolio/` —«Portafolio CC» con el punto verde de marca al lado, que es una imagen de 20x15— y la ilustración con pie del panel «SEO técnico», que convive con una lista de viñetas y no con otras tarjetas. Se midieron los 18 candidatos de las 5 páginas contra varios discriminadores —tamaño de la imagen, orden imagen/texto, número de hijos, presencia de titular— y el único que separa sin excepciones es CUÁNTOS HERMANOS COMPARTEN SU MISMA FORMA: hermanos = 1 -> los 6 falsos positivos, sin excepción (`Portafolio CC`, la ilustración de SEO y sus 3 gemelas de pestaña oculta, y el `
` «Recibe una propuesta» de influencer) hermanos >= 3 -> los 12 verdaderos, sin excepción (SXO/GEO/ESO/AEO, y los dos grupos de influencer) Y no es una correlación que salió de los datos: es la definición. **Una tarjeta es una unidad que se repite.** Un bloque con imagen y texto que está SOLO en su contenedor es una maqueta —una ilustración con su pie, un titular con su adorno—, y ponerle superficie lo convierte en un componente que no existe. ⚠️ CÓMO SE ESCRIBE «TIENE HERMANA», Y POR QUÉ NO COMO PARECE. Lo natural sería preguntar por el padre —«aquí dentro hay dos o más»— pero eso obliga a meter la forma DENTRO de un `:has()`, y la forma ya contiene `:has()`. **`:has()` no se puede anidar dentro de otro `:has()`**: el selector no es inválido a medias, el navegador descarta la regla ENTERA y en silencio. Escrito así estuvo un rato, y el síntoma engañaba: `agencia-seo` parecía correcta —sus 4 tarjetas seguían con borde, pero era el borde propio de Bricks, no este— mientras influencer-marketing perdía los suyos. Comprobado con `querySelectorAll`, que lanza excepción con el selector anidado y es la forma barata de no confiar en la vista. Así que la pregunta se hace de lado, con el hermano siguiente, que no necesita anidar: · `FORMA + FORMA` -> todas las del conjunto menos la primera · `FORMA:has(+ bloque > imagen)` -> la primera, mirando hacia adelante La unión es «pertenece a una serie». Contrastado contra los 18 candidatos de las 5 páginas: **18/18**, sin un solo falso positivo ni negativo. */ body.cc-tema-estandar #brx-content :is(.brxe-block, .brxe-div):has(> .brxe-image):has(> :is(.brxe-text, .brxe-heading, .brxe-text-basic)) + :is(.brxe-block, .brxe-div):has(> .brxe-image):has(> :is(.brxe-text, .brxe-heading, .brxe-text-basic)), body.cc-tema-estandar #brx-content :is(.brxe-block, .brxe-div):has(> .brxe-image):has(> :is(.brxe-text, .brxe-heading, .brxe-text-basic)):has(+ :is(.brxe-block, .brxe-div) > .brxe-image) { border-radius: var(--cc-radius-lg); border: 1px solid color-mix(in srgb, var(--cc-fg) 10%, transparent); background: color-mix(in srgb, var(--cc-fg) 5%, transparent); overflow: hidden; /* Las del conjunto miden lo mismo aunque su texto no. Sin esto, la tarjeta de AEO —la de pie más largo— bajaba 22px respecto a sus tres hermanas, y con el borde puesto ese desnivel se ve: la superficie es lo que vuelve visible una desalineación que antes no lo era. O sea lo arregla quien lo causó. */ align-self: stretch; transition: transform var(--cc-dur-fast, .18s) var(--cc-ease-out, ease), border-color var(--cc-dur-fast, .18s) var(--cc-ease-out, ease); } body.cc-tema-estandar #brx-content :is(.brxe-block, .brxe-div):has(> .brxe-image):has(> :is(.brxe-text, .brxe-heading, .brxe-text-basic)) + :is(.brxe-block, .brxe-div):has(> .brxe-image):has(> :is(.brxe-text, .brxe-heading, .brxe-text-basic)):hover, body.cc-tema-estandar #brx-content :is(.brxe-block, .brxe-div):has(> .brxe-image):has(> :is(.brxe-text, .brxe-heading, .brxe-text-basic)):has(+ :is(.brxe-block, .brxe-div) > .brxe-image):hover { transform: translateY(-4px); border-color: color-mix(in srgb, var(--cc-fg-accent) 45%, transparent); } /* ========================================================================== ACORDEÓN EN MÓVIL: EL CHEVRON NO SE VA A LA LÍNEA DE ABAJO (2026-08-26, 8.112) ========================================================================== Reportado por Ricardo desde su teléfono: *«las preguntas frecuentes también se ven mal»*. Medido a 390px en `/servicios/agencia-seo/`: .accordion-title-wrapper 342x56 flex-wrap: WRAP padding: 0 └ h3 342x46 ← ocupa el ancho ENTERO └ ::after (el chevron) 10x10 ← no le queda sitio: cae a la 2ª línea O sea la marca de desplegar aparecía DEBAJO de la pregunta, pegada a la línea separadora, y con `min-height:56px` el contenido (46+10) llenaba la fila al milímetro: cero aire arriba y abajo. Una pregunta de una sola línea se veía bien, y por eso pasaba desapercibido en el escritorio, donde ninguna llega a dos líneas. ⚠️ NO es un defecto del componente: la página VTEX usa el mismo acordeón y ahí está bien (`nowrap`, `padding: 6px 0`, la fila crece a 60px con títulos de dos líneas). Es la configuración de ESTA página, que Bricks escribe como `#brxe-seo211 .accordion-title-wrapper` — (1,1,0), así que hace falta un ID para ganarle y `#brx-content` es el único genérico que existe en todas las páginas de Bricks. `body` delante lo deja en (1,2,0), que gana pase lo que pase con el orden de carga. Se acota a ≤767px a propósito: sobre ese ancho el `flex-wrap` ya vale `nowrap` y los títulos caben en una línea, así que tocarlo ahí sería cambiar algo que funciona. */ @media (max-width: 767px) { body #brx-content .accordion-title-wrapper { flex-wrap: nowrap; align-items: center; gap: var(--cc-space-4); /* Deja respirar las preguntas de dos líneas. La fila crece porque Bricks fija `min-height` y no `height`. */ padding-block: var(--cc-space-3); } /* Sin esto, `nowrap` no encoge el título —un hijo flex no baja de su contenido— y el chevron se sale de la caja en vez de bajar de línea: el mismo bug con otro síntoma. Es 8.101 desde el otro lado. */ body #brx-content .accordion-title-wrapper > * { min-width: 0; } /* Y el chevron no puede encogerse a cero al apretar. */ body #brx-content .accordion-title-wrapper::after { flex: 0 0 auto; } } /* ============================================================================= FORMULARIOS DE GRAVITY FORMS (2026-08-26, gotcha 8.113) ============================================================================= Ricardo, comparando `/contacto/` con la landing del E-Commerce Blend: *«es más decente del que tenemos»*. Tenía razón, y era medible: campo URL 38px de alto contra 48 del resto · borde VERDE en todos los campos botón de enviar 38px ← por debajo del mínimo de 44 de WCAG 2.5.8 botón en menta pálido #ADEFDB, que no es ningún valor de la paleta ⚠️ Y la causa no es descuido: **nadie lo había visto nunca**. Gravity Forms es de licencia y en local no está, así que el theme pinta una MAQUETA (`ccd_form_maqueta()`), cuyo propio comentario dice que «no pretende ser el formulario final: pretende ocupar lo que ocupa el real». Resolvió lo suyo —el layout de la página— y dejó este hueco, que solo se ve donde hay GF de verdad: el staging, que existe desde el 2026-08-25. Lo que se veía era el tema `orbital` de Gravity Forms **sin tematizar**, con sus valores de fábrica (azul #204ce5, fondo blanco, borde gris). POR QUÉ SE TOCAN VARIABLES Y NO REGLAS. El tema `orbital` está enteramente dirigido por una familia `--gf-color-*` de la que deriva todo lo demás. Sobrescribir esas variables —que es la vía que el propio framework documenta— es robusto: no pelea con la especificidad de GF, no se rompe cuando actualicen sus hojas, y hace falta una sola declaración por decisión en vez de una por selector. POR QUÉ NO SE COPIA EL CSS DE LA LANDING. El suyo vive en los ajustes de Bricks de `/ecommerce-blend/`, o sea EN LA BD (§10): no viaja en git y habría que rehacerlo en cada entorno y en cada página. Aquí cubre los 10 formularios del sitio de una vez. ⚠️ EL ALCANCE EXCLUYE LAS LANDINGS DE EVENTO, y no por casualidad: su `` no lleva NINGUNA clase `cc-`, así que acotar a las páginas que el theme gobierna las deja fuera sola. Se comprobó midiendo las dos: `/ecommerce-blend/` es `page-id-9590` y nada más. Eso importa porque esas landings ya se ven bien y son la referencia, no el problema. ⚠️ Y EXCLUÍA TAMBIÉN LA PORTADA, que no es lo mismo: ahí no había landing ajena que respetar sino la pieza más trabajada del sitio sirviendo EL MISMO formulario 1 desde `#brxe-sec127`. Su `` tampoco llevaba clase `cc-`, así que «acotar a las páginas que el theme gobierna» la dejó fuera junto con las landings — el criterio era correcto y el marcador no existía. Se añade `.cc-home`, que emite `body_class` por `is_front_page()`. Lo que se veía mientras tanto está medido en 8.114: los selectores de id que la BD incrusta DENTRO del formulario ganaban por un punto de especificidad. Y NO ES UNA COPIA, ES UNA TRADUCCIÓN. La landing es de tema oscuro fijo; `/contacto/` tiene conmutador, así que todo sale de tokens que ya voltean (`--cc-fg`, `--cc-border`, `--cc-fg-read`) y solo la superficie del campo necesita su propio valor por tema. Y el verde es el de la escala (`--cc-green-500`), no el `#0BE5A2` de la landing: estrenar un valor fuera de la paleta es 8.18. ========================================== */ body:is(.cc-servicios, .cc-tema-estandar, .cc-home) #brx-content .gform_wrapper { /* La superficie del campo: en oscuro es un vidrio sobre el fondo y en claro es papel hundido. El valor de dark vive en `cc-tokens.css` desde el 2026-08-27, porque una isla oscura necesita recuperarlo en modo claro sin volver a escribir el rgba (8.114). */ --cc-form-superficie: var(--cc-form-superficie-on-dark); /* La familia raíz de GF. De estas seis deriva el tema entero. */ --gf-color-primary: var(--cc-green-500); --gf-color-primary-contrast: var(--cc-ink-900); --gf-color-primary-darker: var(--cc-green-700); --gf-color-in-ctrl: var(--cc-form-superficie); --gf-color-in-ctrl-contrast: var(--cc-fg); --gf-color-in-ctrl-light: var(--cc-border); --gf-color-in-ctrl-light-darker: var(--cc-border); --gf-color-out-ctrl-dark: var(--cc-fg-read); --gf-color-out-ctrl-light: var(--cc-border-soft); --gf-ctrl-radius: var(--cc-radius-sm); } html[data-theme="light"] body:is(.cc-servicios, .cc-tema-estandar, .cc-home) #brx-content .gform_wrapper { --cc-form-superficie: var(--cc-bg-surface); } /* Los controles. Las variables no cubren el ALTO ni el tamaño de letra, así que van aquí. La especificidad (1,3,1) le gana al `#gform_wrapper_N[data-form-index]` que GF inyecta en línea, que es (1,1,0) — sin esto no aplica nada de lo de abajo. */ body:is(.cc-servicios, .cc-tema-estandar, .cc-home) #brx-content .gform_wrapper :is(input[type="text"], input[type="email"], input[type="tel"], input[type="url"], input[type="number"], select, textarea) { /* 48px, no 44: el mínimo táctil es 44 y un campo de texto se toca peor que un botón porque hay que acertar dentro para colocar el cursor. Es además el alto que ya tenían los campos buenos de esta página, así que no cambia el layout que se diseñó. */ min-height: 48px; padding: 0 var(--cc-space-3); /* ⚠️ 16px NO ES ESTÉTICO: bajo 16px, iOS hace ZOOM al enfocar un campo y deja al visitante con la página descuadrada y sin forma obvia de volver. La landing usa 14px y por eso le pasa. Es el motivo por el que este valor no se «mapea a la escala» hacia abajo. */ font-family: var(--cc-font-sans); font-size: var(--cc-fs-sm); color: var(--cc-fg); background-color: var(--cc-form-superficie); border: 1px solid var(--cc-border); border-radius: var(--cc-radius-sm); transition: border-color var(--cc-dur-fast) var(--cc-ease); } body:is(.cc-servicios, .cc-tema-estandar, .cc-home) #brx-content .gform_wrapper textarea { min-height: 120px; padding: var(--cc-space-3); line-height: var(--cc-lh-relaxed); } body:is(.cc-servicios, .cc-tema-estandar, .cc-home) #brx-content .gform_wrapper :is(input, select, textarea):focus-visible { outline: 2px solid var(--cc-fg-accent); outline-offset: 2px; border-color: var(--cc-fg-accent); } body:is(.cc-servicios, .cc-tema-estandar, .cc-home) #brx-content .gform_wrapper ::placeholder { color: var(--cc-fg-muted); opacity: 1; /* Firefox lo atenúa por su cuenta y el marcador queda ilegible. */ } /* La etiqueta. Va por debajo del cuerpo pero NO por debajo de 12px, que es donde a11y empieza a marcar. */ body:is(.cc-servicios, .cc-tema-estandar, .cc-home) #brx-content .gform_wrapper :is(.gfield_label, legend.gfield_label) { font-family: var(--cc-font-sans); font-size: var(--cc-fs-xs); font-weight: var(--cc-fw-semibold); color: var(--cc-fg-read); margin-bottom: var(--cc-space-2); } /* El botón. Era lo peor del formulario: 38px de alto —bajo el mínimo táctil— y un menta pálido que no está en la paleta. Se alinea con el CTA flotante, que es el mismo gesto: verde de marca, tinta casi negra encima (13.14:1) y forma de píldora. */ body:is(.cc-servicios, .cc-tema-estandar, .cc-home) #brx-content .gform_wrapper :is(input[type="submit"], button[type="submit"], .gform_button) { min-height: 48px; padding: var(--cc-space-3) var(--cc-space-8); font-family: var(--cc-font-sans); font-size: var(--cc-fs-sm); font-weight: var(--cc-fw-bold); color: var(--cc-ink-900); background-color: var(--cc-green-500); border: 0; border-radius: var(--cc-radius-pill); cursor: pointer; transition: background-color var(--cc-dur-fast) var(--cc-ease); /* A TODO EL ANCHO, como en la landing del Blend. No es capricho de tamaño: en un formulario largo el envío es el único paso siguiente, y un botón pequeño alineado a la izquierda compite con el resto de la columna en vez de cerrarla. Ocupar la línea es lo que lo convierte en el final del recorrido. */ width: 100%; } body:is(.cc-servicios, .cc-tema-estandar, .cc-home) #brx-content .gform_wrapper :is(input[type="submit"], button[type="submit"], .gform_button):hover { background-color: var(--cc-green-700); } /* El área de texto. ⚠️ `min-height` NO basta: GF le pone la clase `textarea small`, que fija `height`, y una altura explícita gana a un mínimo. Medido antes de esto: 50px con `rows='10'` en el markup, o sea el atributo tampoco mandaba. */ body:is(.cc-servicios, .cc-tema-estandar, .cc-home) #brx-content .gform_wrapper textarea:is(.small, .medium, .large, [class]) { height: auto; min-height: 140px; padding: var(--cc-space-3); line-height: var(--cc-lh-relaxed); resize: vertical; } /* Casillas y radios. Medido en el staging: 20x21 px, por debajo del mínimo de 24x24 de WCAG 2.5.8 — y `a11y.mjs` ya lo venía marcando contra el servidor. Aquí no se puede crecer «un poco»: o pasa el mínimo o no. */ body:is(.cc-servicios, .cc-tema-estandar, .cc-home) #brx-content .gform_wrapper :is(input[type="checkbox"], input[type="radio"]) { width: 24px; height: 24px; accent-color: var(--cc-green-500); cursor: pointer; } /* EL SELECTOR DE PAÍS del teléfono (`phoneFormat: formatted` + `defaultCountry: cl`). ⚠️ NO es un ``**, así que se cae de las reglas escritas para campos. con el teclado (Tab) outline: 0px ← un control operable SIN foco visible con el panel abierto outline: 3px rgba(32,76,229,0.65) Ese `#204ce5` es **el azul de fábrica de Gravity Forms**, el mismo que 8.113 dio por sustituido — y no lo estaba: `--gf-color-primary` sí se cambió, pero el contorno sale de OTRA familia (`--gf-ctrl-outline-color`) que nadie había tocado. Es 8.37 en su versión de variables: la decisión estaba tomada y una rama del árbol no se enteró. El anillo sale de `--cc-fg-accent`, que es el token de PRIMER PLANO y voltea con el tema (en la isla oscura de la portada se queda en verde de marca, que es lo correcto). */ body:is(.cc-servicios, .cc-tema-estandar, .cc-home) #brx-content .gform_wrapper { --gf-ctrl-outline-color: var(--cc-fg-accent); /* ⚠️ Y EL TRIPLETE, que es lo que de verdad pintaba el azul. Con solo el hex cambiado, el contorno del estado abierto seguía dando `rgba(32,76,229,0.65)`: esa rama de GF no usa `--gf-color-primary` sino `rgba(var(--gf-color-primary-rgb), .65)`, y el `-rgb` seguía siendo el de fábrica. Medido antes y después sobre el mismo nodo, con el panel abierto. ⚠️ **Aquí NO va una regla de `:focus-visible`**, y se probó a ponerla: el child theme ya da un anillo verde de 3px a todo `button` —`:where(a, button, input, …):focus-visible`— así que una regla propia solo habría creado un segundo sitio donde vive la misma decisión, y encima con otro grosor. Lo que faltaba era el color, no el anillo. */ --gf-color-primary-rgb: var(--cc-green-500-rgb); --gf-color-in-ctrl-primary-rgb: var(--cc-green-500-rgb); } /* ⚠️ LA OPCIÓN RESALTADA DEL DESPLEGABLE, EN BLANCO SOBRE BLANCO (2026-08-27, 8.114). Ricardo, con el selector abierto: *«al seleccionar se ve en blanco»*. Medido: .gform-phone__country-item--focused background rgb(245,245,245) color rgb(255,255,255) .gform-phone__country-item--active idem idem → 1.06:1 `#F5F5F5` es `--gf-color-secondary-darker`, de la familia `--gf-color-secondary-*` que 8.113 **no tocó**: tematizó `primary` y `in-ctrl` —lo que se ve sin interactuar— y esta familia solo aparece al abrir un desplegable, o sea nunca salió en una captura. Es el mismo modo de fallo que el azul del contorno: la decisión estaba tomada y una rama del árbol no se enteró (8.37 en versión de variables). Se tematiza la familia entera y NO solo la fila resaltada, que es la vía de 8.113: de `secondary` cuelgan también el hover del botón terciario y los menús que traiga GF mañana. El resalte sale de `color-mix` sobre `--cc-fg` en vez de un hex: en oscuro `--cc-fg` es blanco y levanta la fila, en claro es tinta y la hunde — el mismo gesto con el signo que toque, sin dos valores que mantener. */ body:is(.cc-servicios, .cc-tema-estandar, .cc-home) #brx-content .gform_wrapper { --gf-color-secondary: var(--cc-bg-surface); --gf-color-secondary-contrast: var(--cc-fg); --gf-color-secondary-darker: color-mix(in srgb, var(--cc-fg) 14%, transparent); --gf-color-secondary-lighter: var(--cc-bg-surface); --gf-color-in-ctrl-light-lighter: color-mix(in srgb, var(--cc-fg) 14%, transparent); --gf-ctrl-btn-bg-color-hover-tertiary: color-mix(in srgb, var(--cc-fg) 14%, transparent); } /* ⚠️ LA MARCA «PRÓXIMAMENTE» DE CANAL.DATA (2026-08-27, gotcha 8.118). El mega-menú ya distinguía los tres ítems de esa unidad —van en ``, en gris atenuado y sin cursor de enlace: medido, **6:1** de contraste contra el **12.37:1** de los enlaces de al lado—, así que la decisión estaba tomada y aplicada. Lo que faltaba es que se dijera. La distinción vivía en el NOMBRE DE LA CLASE y en el tono, y eso no es una afirmación: lo destapó una auditoría hecha leyendo el DOM, que dio por rotos tres ítems sin `href`. Si un lector humano del markup lo lee así, un visitante que ve tres líneas grises apagadas también. Va en la CABECERA de la columna y no en cada ítem: los tres son la misma unidad, y repetir la palabra tres veces convierte una aclaración en ruido. ⚠️ Y va en el MARKUP, no en un `::after`. Es la decisión opuesta a la del guion de los silos (`.cc-silo__vacio::after`) y por la misma regla: aquello es SEÑALIZACIÓN —no se lee en voz alta ni se traduce— y esto es CONTENIDO, que sí. No estrena ningún valor: 14px es `--cc-fs-xs`, que ya usa la portada, y el color es el mismo `--cc-fg-muted` de los tres ítems. Y no mueve el trinquete tipográfico ni aunque lo estrenara: el panel va `hidden`, así que `ux.mjs` —que filtra por `offsetParent`— no lo cuenta. */ .cc-mega__pronto { margin-left: 8px; font-size: var(--cc-fs-xs); font-weight: var(--cc-fw-medium); color: var(--cc-fg-muted); white-space: nowrap; } /* ========================================================================== /geo-aeo/ — H3. La maqueta propia, con la capa de sistema (2026-08-31) ========================================================================== DE DÓNDE VIENE ESTE BLOQUE. Hasta hoy el diseño entero de `/geo-aeo/` eran **8.736 caracteres de CSS a nivel de PÁGINA** guardados en `_bricks_page_settings.customCss`, o sea **en la BD** (§10), que Bricks compilaba a `uploads/bricks/css/post-9485.min.css`. Ninguna otra pieza rediseñada tiene eso: medido el 2026-08-31, `/servicios/`, `/contacto/`, `servicios/creatividad` y `servicios/agencia-seo` tienen ese campo **vacío** y su estilo vive acá. `/geo-aeo/` era la excepción, y esto la deshace. POR QUÉ IMPORTABA. Ese CSS clavaba siete colores a mano, y **cuatro son valores que el sistema RETIRÓ el 2026-07-23**: #0BE5A2 ×12 → var(--cc-green-500) (#3DEDB4) #191919 ×5 → var(--cc-bg) (#0A0A0F) #1E1E1E ×4 → var(--cc-bg-band) (#101016) #442ABA ×2 → var(--cc-bg-impulse) (#4B2FBF) O sea la página era una foto de la paleta anterior al cambio, y por eso `tema.mjs` decía que **responde al tema un 0 %**: sus fondos no eran tokens, así que el conmutador ahí era un control que no cambiaba nada. ⚠️ EL ALCANCE `body.cc-geo` NO ES COSMÉTICO, ES LA RED. De las 61 clases de esta página, **11 reusan nombres del sistema con otros valores** —`.cc-btn`, `.cc-card`, `.cc-hero`, `.cc-dot`, `.cc-badge`, `.cc-tabs`, `.cc-tab`, `.cc-cta`, `.cc-dato`, `.cc-servicios`, `.cc-bt`—. Traerlas acá sin acotar las haría **globales** y rompería el sitio entero. Cada regla va prefijada, y las dos únicas que no lo están son los `@keyframes`, que no tienen alcance. ⚠️ Y ESO DEJA UNA DEUDA ESCRITA, a propósito: mientras esas 11 existan, hay dos definiciones del mismo nombre en el repo y solo el prefijo las separa. Reconciliarlas —que la página use el `.cc-btn` del sistema— cambia su aspecto, y el pedido del 2026-08-31 fue explícito: «hazlo parecido a como está». Se deja para cuando esa página se rediseñe de verdad, no ahora. LO QUE SÍ SE CAMBIÓ ADEMÁS DE LOS COLORES: · los rellenos de sección a mano (104/108, 100/100, 110/110, 96/96) → `--cc-sec-*`; · los blancos con alfa ALTOS (.62–.86), que son TEXTO, → `--cc-fg-read` y `--cc-fg-muted`, porque en claro un blanco sobre papel es invisible; · los BAJOS (.06–.16), que son filetes y velos, → `--cc-hairline-on-dark` y `--cc-rule-on-dark`, que voltean con el tema; · la guarda de `prefers-reduced-motion`, que el original **no tenía** (ver abajo). Los tres `rgba(0,0,0,…)` que quedan son canales de MÁSCARA, no colores de diseño: ahí el negro significa «opaco» y sustituirlo por un token sería un error. ========================================================================== */ /* ⚠️ LOS DOS ERRORES DE MAPEO QUE CAZÓ `tema.mjs` AL ESTRENAR ESTE BLOQUE, y la regla que los explica: en este sistema hay tokens de PALETA y tokens de ROL, y **solo los de rol voltean con el tema**. (a) Verde de paleta como color de TEXTO. `--cc-green-500` es paleta: en claro sigue siendo #3DEDB4 y sobre papel blanco da **1.5:1**. Los 6 casos —`.cc-eyebrow`, `.cc-badge`, `.cc-check`, `.cc-card-tag`, `.cc-step-num`, `.cc-faq-sign`— pasan a `--cc-fg-accent`, que es el token de ROL y voltea a `--cc-green-ink` (#067A57). (b) Texto SOBRE el verde. Al revés: el FONDO es paleta y no voltea, así que el texto tiene que ser un oscuro **estable**. Llevaban `--cc-bg-deep`, que sí voltea, o sea en claro quedaba papel claro sobre verde: **1.43:1**. Pasan a `--cc-ink-900`. La forma general: al portar CSS clavado, un hex de fondo y un hex de texto **no se traducen al mismo tipo de token**, aunque el hex sea idéntico. Fondo → rol; texto sobre un color de marca → paleta. Sustituir por hex, como hizo la primera pasada de este porte, produce exactamente estos dos fallos y ninguna otra suite los ve: el contraste en OSCURO era correcto en los diez casos. */ body.cc-geo .cc-sec {font-family:'Montserrat',-apple-system,'Helvetica Neue',Arial,sans-serif;-webkit-font-smoothing:antialiased;color:var(--cc-fg);display:block;} body.cc-geo .cc-sec, body.cc-geo .cc-sec *, body.cc-geo .cc-sec *::before, body.cc-geo .cc-sec *::after {box-sizing:border-box;} body.cc-geo .cc-wrap {width:100%;max-width:1240px;margin:0 auto;padding:0 48px;} body.cc-geo .cc-dot {display:inline-block;width:16px;height:16px;border-radius:50%;background:var(--cc-green-500);margin-left:10px;vertical-align:baseline;} body.cc-geo .cc-btn {display:inline-flex;align-items:center;gap:10px;padding:17px 34px;border-radius:999px;background:var(--cc-green-500);color:var(--cc-ink-900);font-weight:700;font-size:17px;text-decoration:none;transition:transform .18s,background-color .18s;font-family:inherit;border:none;cursor:pointer;} body.cc-geo .cc-btn:hover {background:var(--cc-green-400);transform:translateY(-2px);color:var(--cc-ink-900);} body.cc-geo .cc-arrow {font-size:18px;line-height:1;} body.cc-geo .cc-eyebrow {color:var(--cc-fg-accent);font-weight:600;font-size:13px;letter-spacing:.14em;text-transform:uppercase;margin-bottom:16px;} body.cc-geo .cc-h2 {font-weight:800;font-size:42px;line-height:1.1;margin:0;color:var(--cc-fg);letter-spacing:-.01em;} body.cc-geo .cc-head-center {text-align:center;margin-bottom:52px;} body.cc-geo .cc-head-center .cc-h2 {max-width:720px;margin:0 auto;} body.cc-geo .cc-head-left {max-width:760px;margin-bottom:56px;} /* HERO */ body.cc-geo .cc-hero{position:relative;overflow:hidden;background:linear-gradient(180deg,var(--cc-bg-deep) 55%,var(--cc-bg) 100%);} body.cc-geo .cc-hero::before {content:"";position:absolute;top:-55%;left:50%;width:1700px;height:1700px;transform:translateX(-50%);background:repeating-conic-gradient(from 0deg at 50% 50%, color-mix(in srgb, var(--cc-sky-500) calc(0 * 100%), transparent) 0deg, color-mix(in srgb, var(--cc-sky-500) calc(.32 * 100%), transparent) .55deg, color-mix(in srgb, var(--cc-green-500) calc(.22 * 100%), transparent) 1.5deg, rgba(0,0,0,0) 2.9deg);-webkit-mask:radial-gradient(circle at 50% 50%, #000 0%, rgba(0,0,0,.6) 34%, transparent 60%);mask:radial-gradient(circle at 50% 50%, #000 0%, rgba(0,0,0,.6) 34%, transparent 60%);animation:ccSpin 45s linear infinite;opacity:.55;pointer-events:none;z-index:0;} body.cc-geo .cc-hero::after {content:"";position:absolute;inset:0;background-image:radial-gradient(var(--cc-fg-muted) 1px,transparent 1px);background-size:44px 44px;-webkit-mask:radial-gradient(circle at 50% 40%,#000 0%,transparent 55%);mask:radial-gradient(circle at 50% 40%,#000 0%,transparent 55%);opacity:.12;pointer-events:none;z-index:0;} @keyframes ccSpin{to{transform:translateX(-50%) rotate(360deg);} } @keyframes ccPulse{0%,100%{opacity:.85} 50% {opacity:.35} } body.cc-geo .cc-hero-wrap {position:relative;max-width:1000px;padding:118px 48px 140px;text-align:center;z-index:1;} body.cc-geo .cc-badge {display:inline-flex;align-items:center;gap:9px;padding:8px 16px;border:1px solid color-mix(in srgb, var(--cc-green-500) calc(.4 * 100%), transparent);border-radius:999px;font-size:12.5px;font-weight:600;letter-spacing:.12em;text-transform:uppercase;color:var(--cc-fg-accent);margin-bottom:30px;} body.cc-geo .cc-badge-dot {width:7px;height:7px;border-radius:50%;background:var(--cc-green-500);animation:ccPulse 2.4s ease-in-out infinite;flex:none;} body.cc-geo .cc-hero-h1 {font-weight:800;font-size:66px;line-height:1.02;letter-spacing:-.02em;margin:0 auto 26px;max-width:900px;color:var(--cc-fg);} body.cc-geo .cc-hero-h1 .cc-dot {width:16px;height:16px;} body.cc-geo .cc-hero-sub {font-size:20px;line-height:1.55;color:var(--cc-fg-read);max-width:660px;margin:0 auto 40px;} body.cc-geo .cc-hero-sub strong {color:var(--cc-fg);font-weight:700;} /* SERVICIOS */ body.cc-geo .cc-servicios{background:var(--cc-bg);padding: var(--cc-sec-md) 0 108px;} body.cc-geo .cc-tabs {display:flex;flex-wrap:wrap;justify-content:center;gap:8px;margin-bottom:48px;} body.cc-geo .cc-tab {background:transparent;border:1px solid var(--cc-rule-on-dark);border-radius:999px;padding:12px 22px;font-family:inherit;font-weight:600;font-size:14.5px;color:var(--cc-fg-read);cursor:pointer;transition:all .18s;} body.cc-geo .cc-tab:hover {border-color:var(--cc-fg-muted);color:var(--cc-fg);} body.cc-geo .cc-tab.is-active {background:var(--cc-green-500);border-color:var(--cc-green-500);color:var(--cc-ink-900);} body.cc-geo .cc-panel {display:none;background:var(--cc-bg-band);border:1px solid var(--cc-hairline-on-dark);border-radius:24px;padding:56px 56px 52px;} body.cc-geo .cc-panel.is-active {display:block;} body.cc-geo .cc-panel-head {margin-bottom:40px;max-width:820px;} body.cc-geo .cc-quote {font-weight:700;font-size:30px;line-height:1.22;margin:0 0 14px;color:var(--cc-fg);} body.cc-geo .cc-panel-desc {font-size:18px;line-height:1.6;color:var(--cc-fg-read);margin:0;} body.cc-geo .cc-bullets {display:grid;grid-template-columns:1fr 1fr;gap:2px;background:var(--cc-hairline-on-dark);border-radius:16px;overflow:hidden;} body.cc-geo .cc-bullet {background:var(--cc-bg-band);padding:26px 28px;display:flex;gap:16px;align-items:flex-start;} body.cc-geo .cc-check {flex:none;width:26px;height:26px;border-radius:8px;background:color-mix(in srgb, var(--cc-green-500) calc(.14 * 100%), transparent);color:var(--cc-fg-accent);display:flex;align-items:center;justify-content:center;font-size:14px;font-weight:800;margin-top:2px;} body.cc-geo .cc-bt {font-weight:700;font-size:16px;color:var(--cc-fg);margin-bottom:5px;} body.cc-geo .cc-bd {font-size:15px;line-height:1.55;color:var(--cc-fg-read);} /* CONCEPTS */ body.cc-geo .cc-concepts{background:var(--cc-bg-deep);padding: var(--cc-sec-md) 0 110px;} body.cc-geo .cc-cards {display:grid;grid-template-columns:repeat(4,1fr);gap:20px;} body.cc-geo .cc-card {background:var(--cc-bg-band);border:1px solid var(--cc-hairline-on-dark);border-radius:18px;padding:32px 28px;} body.cc-geo .cc-card-sov {border-color:color-mix(in srgb, var(--cc-violet-500) 35%, transparent);} body.cc-geo .cc-card-tag {display:inline-block;font-weight:800;font-size:15px;letter-spacing:.02em;color:var(--cc-fg-accent);margin-bottom:14px;} body.cc-geo .cc-tag-violet {color:var(--cc-violet-100);} body.cc-geo .cc-card-title {font-weight:700;font-size:16px;color:var(--cc-fg);margin-bottom:12px;line-height:1.3;} body.cc-geo .cc-card-desc {font-size:15px;line-height:1.6;color:var(--cc-fg-read);margin:0;} /* DATO */ body.cc-geo .cc-dato{background:var(--cc-bg-impulse);padding: var(--cc-sec-md) 0;} body.cc-geo .cc-dato-grid {max-width:1080px;display:grid;grid-template-columns:1fr 1fr;gap:60px;align-items:start;} body.cc-geo .cc-dato-h {font-weight:800;font-size:44px;line-height:1.12;margin:0;color:var(--cc-fg);} body.cc-geo .cc-dato-text {display:flex;flex-direction:column;gap:22px;} body.cc-geo .cc-dato-text p {font-size:18px;line-height:1.65;color:var(--cc-fg-read);margin:0;} /* METODO */ body.cc-geo .cc-metodo{background:var(--cc-bg);padding: var(--cc-sec-md) 0 108px;} body.cc-geo .cc-steps {display:grid;grid-template-columns:1fr 1fr;gap:2px;background:var(--cc-hairline-on-dark);border:1px solid var(--cc-hairline-on-dark);border-radius:20px;overflow:hidden;} body.cc-geo .cc-step {background:var(--cc-bg);padding:34px 36px;display:flex;gap:22px;align-items:flex-start;} body.cc-geo .cc-step-num {flex:none;font-weight:800;font-size:34px;color:var(--cc-fg-accent);line-height:1;width:44px;} body.cc-geo .cc-step-t {font-weight:700;font-size:19px;color:var(--cc-fg);margin-bottom:8px;} body.cc-geo .cc-step-d {font-size:15.5px;line-height:1.6;color:var(--cc-fg-read);margin:0;} /* SOMOS */ body.cc-geo .cc-somos{background:var(--cc-bg-deep);padding: var(--cc-sec-md) 0;} body.cc-geo .cc-somos-wrap {max-width:900px;text-align:center;} body.cc-geo .cc-somos-h {font-size:40px;line-height:1.16;margin:0 0 24px;} body.cc-geo .cc-somos-p {font-size:19px;line-height:1.6;color:var(--cc-fg-read);margin:0 auto;max-width:680px;} /* FAQ */ body.cc-geo .cc-faq{position:relative;background:var(--cc-bg);padding: var(--cc-sec-md) 0 104px;overflow:hidden;} body.cc-geo .cc-faq::before {content:"";position:absolute;inset:0;background:repeating-linear-gradient(115deg,color-mix(in srgb, var(--cc-green-500) calc(.05 * 100%), transparent) 0px,color-mix(in srgb, var(--cc-green-500) calc(.05 * 100%), transparent) 2px,transparent 2px,transparent 26px);pointer-events:none;z-index:0;} body.cc-geo .cc-faq-wrap {position:relative;max-width:920px;z-index:1;} body.cc-geo .cc-faqs {display:flex;flex-direction:column;gap:12px;} body.cc-geo .cc-faq-item {background:var(--cc-bg-band);border:1px solid var(--cc-hairline-on-dark);border-radius:14px;overflow:hidden;} body.cc-geo .cc-faq-q {width:100%;display:flex;align-items:center;justify-content:space-between;gap:20px;text-align:left;background:transparent;border:none;padding:22px 26px;cursor:pointer;font-family:inherit;} body.cc-geo .cc-faq-q>span:first-child {font-weight:600;font-size:17px;color:var(--cc-fg);} body.cc-geo .cc-faq-sign {flex:none;width:28px;height:28px;border-radius:50%;background:var(--cc-hairline-on-dark);color:var(--cc-fg-accent);display:flex;align-items:center;justify-content:center;font-size:18px;font-weight:600;line-height:1;} body.cc-geo .cc-faq-item.is-open .cc-faq-sign {background:var(--cc-green-500);color:var(--cc-ink-900);} body.cc-geo .cc-faq-a {display:none;padding:0 26px 24px;font-size:16px;line-height:1.65;color:var(--cc-fg-read);} body.cc-geo .cc-faq-item.is-open .cc-faq-a {display:block;} /* CTA */ body.cc-geo .cc-cta{background:var(--cc-bg-impulse);padding: var(--cc-sec-sm) 0;position:relative;} body.cc-geo .cc-cta-wrap {max-width:900px;text-align:center;position:relative;} body.cc-geo .cc-cta-h {font-weight:800;font-size:40px;line-height:1.12;margin:0 0 18px;color:var(--cc-fg);} body.cc-geo .cc-cta-p {font-size:18px;line-height:1.6;color:var(--cc-fg-read);margin:0 auto 38px;max-width:560px;} body.cc-geo .cc-anchor {position:absolute;top:-110px;left:0;} /* RESPONSIVE */ @media(max-width:1000px){body.cc-geo .cc-hero-h1{font-size:52px;}body.cc-geo .cc-h2, body.cc-geo .cc-dato-h{font-size:34px;}body.cc-geo .cc-dato-grid{grid-template-columns:1fr;gap:28px;}body.cc-geo .cc-cards{grid-template-columns:1fr 1fr;} } @media(max-width:768px){body.cc-geo .cc-wrap{padding:0 24px;}body.cc-geo .cc-hero-wrap{padding:80px 24px 96px;}body.cc-geo .cc-hero-h1{font-size:40px;}body.cc-geo .cc-hero-sub{font-size:18px;}body.cc-geo .cc-h2, body.cc-geo .cc-dato-h, body.cc-geo .cc-somos-h, body.cc-geo .cc-cta-h{font-size:30px;}body.cc-geo .cc-bullets, body.cc-geo .cc-steps{grid-template-columns:1fr;}body.cc-geo .cc-panel{padding:32px 24px;}body.cc-geo .cc-quote{font-size:24px;} } @media(max-width:560px){body.cc-geo .cc-cards{grid-template-columns:1fr;}body.cc-geo .cc-hero-h1{font-size:34px;} } /* ⚠️ LA GUARDA QUE EL ORIGINAL NO TENÍA. Las dos animaciones de esta página —el giro del resplandor del hero y el latido del punto de la insignia— corrían SIN condición. El sistema de movimiento del sitio respeta `prefers-reduced-motion` en todo lo demás (8.11–8.13, 8.24), así que esta página era el único sitio donde un usuario que pide menos movimiento lo recibía igual. No es estética: es la red de seguridad del grupo. */ @media (prefers-reduced-motion: reduce) {body.cc-geo .cc-hero::before, body.cc-geo .cc-badge-dot{ animation: none !important; } } /* ⚠️ LAS ISLAS VIOLETAS NO VOLTEAN, Y POR ESO SU TEXTO TAMPOCO PUEDE. Tercera capa del mismo error, y la que costó dos vueltas de `tema.mjs` verlo. `.cc-dato` y `.cc-cta` llevan `background: var(--cc-bg-impulse)` — un color de MARCA, estable en los dos temas. Dentro de ellas, los tokens de ROL sí voltean, así que en claro pasaba esto: 1.14 : 1 «Las marcas que no aparecen en IA…» --cc-fg → gris oscuro sobre violeta 1.14 : 1 «Cada vez más usuarios resuelven…» --cc-fg-read → gris sobre violeta 1.76 : 1 «SHARE OF VOICE» --cc-fg-accent → verde ink sobre violeta O sea el arreglo anterior —pasar los verdes de texto a `--cc-fg-accent`— era correcto en general y **equivocado dentro de una isla de marca**, donde lo que hace falta es lo contrario: valores estables. La regla, y es la que hay que llevarse: **el tipo de token del texto lo decide si su FONDO voltea o no, no el tema de la página.** Se resuelve con una sola regla acotada a las dos islas en vez de tocando cada clase: así una sección violeta nueva hereda el arreglo sin que nadie se acuerde. */ body.cc-geo :is(.cc-dato, .cc-cta) :is(h1, h2, h3, h4, p, li, span, strong, .cc-h2) { color: var(--cc-white); } body.cc-geo :is(.cc-dato, .cc-cta) :is(.cc-eyebrow, .cc-card-tag, .cc-check, .cc-step-num) { /* Menta de PALETA, no `--cc-fg-accent`: sobre el violeta da 6,5:1 en los dos temas. */ color: var(--cc-fg-mint); } /* ⚠️ EL ÚLTIMO, y es el caso que NO se resuelve eligiendo mejor el token: `.cc-tag-violet` —la etiqueta «SHARE OF VOICE», que va violeta a propósito para distinguirse de las tres verdes— llevaba `--cc-violet-100` (#BAAEE7). Es un lila CLARO, pensado para leerse sobre fondo oscuro: ahí da 9:1, y sobre la tarjeta clara del modo claro **1.76:1**. Y acá no sirve cambiar de token, porque **no existe un token de ROL para texto violeta** —el sistema tiene `--cc-fg-accent` para el verde y nada equivalente en violeta—. Las dos salidas eran estrenar un token de rol nuevo, que es decisión del equipo (§7), o declarar los dos valores acá con el mismo mecanismo que usa `cc-tokens.css`. Se elige lo segundo: es la solución más pequeña y no añade vocabulario al sistema por una etiqueta. El claro va a `--cc-violet-600` (#4B2FBF): 7,4:1 sobre la tarjeta. El oscuro se queda como está. Y el selector es `html[data-theme="light"]`, que es exactamente el que usa el bloque claro de los tokens — no un inventado. */ html[data-theme="light"] body.cc-geo .cc-tag-violet { color: var(--cc-violet-600); } /* ========================================================================== /geo-aeo/ — pasada VISUAL sobre el feedback de Ricardo (2026-08-31, tarde) ========================================================================== Cuatro puntos, con sus palabras, y cada arreglo alineado con lo que el sistema YA hace en otras páginas en vez de estrenar tratamiento (§7). ========================================================================== */ /* (1) «Esta parte no me gusta» — la banda violeta del cierre. El diagnóstico: la banda se leía como una TARJETA flotando entre dos zonas blancas, no como una banda del sitio. El sistema tiene su propio tratamiento y es plano y a sangre: `.cc-banda-violeta { background-color: var(--cc-violet-600) }`, sin radio. Acá se le quita el radio y se fuerza el ancho completo para que ancle con el resto de la página. */ body.cc-geo :is(.cc-dato, .cc-cta) { border-radius: 0; margin-inline: 0; width: 100%; max-width: none; } /* (2) «Las preguntas frecuentes se ven distintas a las otras páginas» — cierto, y medido: `/servicios/agencia-seo/` usa el acordeón nativo de Bricks con `.cc-seo-faq`, cuyo tratamiento es **un filete inferior y nada más** —sin tarjeta, sin relleno, sin radio—: .cc-seo-faq > .brxe-block { border-bottom: 1px solid rgba(255,255,255,.12) } html[data-theme="light"] … { border-bottom-color: rgba(32,30,44,.16) } Esos dos valores son exactamente `--cc-rule-on-dark` en cada tema, así que acá se usa el token y no los literales. El `+` pierde su círculo verde relleno —que era la mitad del «se ve distinto»— y queda como glifo de acento. */ body.cc-geo .cc-faq-item { background: transparent; border: 0; border-bottom: 1px solid var(--cc-rule-on-dark); border-radius: 0; } body.cc-geo .cc-faq-item:first-child { border-top: 1px solid var(--cc-rule-on-dark); } body.cc-geo .cc-faq-q { padding-inline: 4px; } body.cc-geo .cc-faq-sign { background: transparent; width: auto; height: auto; border-radius: 0; font-size: 22px; color: var(--cc-fg-accent); } body.cc-geo .cc-faq-item.is-open .cc-faq-sign { background: transparent; color: var(--cc-fg-accent); } body.cc-geo .cc-faq-a { padding-inline: 4px; } /* (3) «Esa cápsula es muy de IA» — la píldora con borde verde y punto latiendo del hero. Y tiene razón: es la firma visual de un hero generado. La portada, que es la pieza de referencia, **no usa píldora**: su antetítulo es texto en versalitas con interletraje. Así que la cápsula se disuelve en el antetítulo que ya existe en esta misma página (`.cc-eyebrow`), y el punto latiendo se va con ella — era el otro tic del mismo estilo. */ body.cc-geo .cc-badge { padding: 0; border: 0; border-radius: 0; background: transparent; gap: 0; color: var(--cc-fg-accent); font-weight: 600; font-size: 13px; letter-spacing: .14em; text-transform: uppercase; } body.cc-geo .cc-badge-dot { display: none; } /* (4) «En modo blanco hay detalles que no se ven y se ve muy plano todo». Medido, y son dos causas distintas: · Los PANELES se pintaban con relleno (`--cc-bg-band`), que en claro es un gris plano #EEEEF1: en oscuro un relleno da volumen, en claro da una mancha. Pasan a fondo transparente con filete, o sea la estructura la dibuja la línea y no el bloque. · Los DIVISORES de la rejilla de pasos y de las tarjetas usaban `--cc-hairline-on-dark`, que en claro vale 0.14 de alfa y desaparece. Pasan a `--cc-rule-on-dark` (0.16), que es el token de REGLAS y no el de filetes de tarjeta — la diferencia entre los dos existe justo para esto. */ body.cc-geo :is(.cc-panel, .cc-card, .cc-step) { background: transparent; border-color: var(--cc-rule-on-dark); } body.cc-geo .cc-steps { background: var(--cc-rule-on-dark); border-color: var(--cc-rule-on-dark); } body.cc-geo .cc-step { background: var(--cc-bg); } body.cc-geo .cc-tab { border-color: var(--cc-rule-on-dark); } /* ⚠️ Y el relieve que en oscuro daba el relleno hay que devolverlo por otro lado, o el arreglo de arriba deja el claro correcto y el oscuro más pobre que antes: en oscuro los paneles y tarjetas recuperan una superficie muy leve, que sobre el suelo #0A0A0F sí se percibe y sobre papel blanco no existiría. */ html:not([data-theme="light"]) body.cc-geo :is(.cc-panel, .cc-card) { background: color-mix(in srgb, var(--cc-white) 3%, transparent); } /* -------------------------------------------------------------------------- /geo-aeo/ — el acordeón, igualado A LA REFERENCIA valor por valor (2026-08-31) -------------------------------------------------------------------------- Segunda pasada. La primera copió el filete de `.cc-seo-faq` y Ricardo dijo, con razón, «sigue distinto que el Agencia-seo». En vez de seguir a ojo se DIFERENCIARON las propiedades calculadas de los dos acordeones renderizados, y las que no coincidían eran siete —no una—: propiedad agencia-seo (referencia) geo-aeo (antes) ancho 1180 px 824 px borde del item 0 arriba / 1 abajo 1 arriba / 1 abajo hueco entre items 0 (normal) 12 px tamaño de pregunta 20 px 17 px relleno del título 0 (va en el wrapper) 22px 4px indicador chevron ::after 10px glifo «+» de 22 px etiqueta H3 SPAN Las seis primeras se igualan acá. **La séptima no**: la pregunta es un `` dentro de un `

No se encontró nada.