/* * theme-fixes.css — ajustes propios del tema hijo Walking Planets. * NO es walking-planets.css (entregable del diseñador, se mantiene íntegro). * Aquí van solo parches puntuales para bugs de integración WordPress/Elementor * que el CSS del diseño no puede prever, bien comentados y con la causa raíz. */ /* * RETIRADO (2026-08-19, @devops): el fix temporal del footer (rejilla inline * `style="display:grid;grid-template-columns:1.4fr 1fr 1fr 1fr"` sin breakpoint * móvil) se quitó porque @build-spec sustituyó ese inline por una clase real * (`.wp-footer__grid`) con su propio colapso a 860px. Verificado antes de * retirar: `grep -c 'grid-template-columns' ` = 0, y revalidado * sin scroll horizontal en 390/768/1024/1440/2560 en las 5 páginas. Si * reapareciera scroll horizontal por este motivo, diagnosticar de nuevo con * `node diagnose-hscroll.js "390,768,1024,1440,2560"` (en * private/tools/qa/) — no reponer esta regla a ciegas, puede ser otro * elemento u otro widget en plena reescritura de estilos inline → clases. */ /* * Red de seguridad global: overflow-x:clip en . * * REGLA CRÍTICA DEL PROYECTO: overflow-x:CLIP, NUNCA hidden. `hidden` crea un * contenedor de scroll y rompe TODOS los position:sticky (columna de reserva del * tour, aside del blog, índice legal) — ya pasó una vez, ver CLAUDE.md del handoff §7. * Esta regla es DOCTRINA del proyecto, no depende de ningún widget: se queda * aunque ahora sea redundante (verificado 2026-08-19: la clase `wp-page` que * @team-lead añadió al ya trae `overflow-x:clip` por su cuenta vía * walking-planets.css). Duplicar `clip` no hace daño; quitarlo si algún día * deja de ser redundante sí lo haría — se deja tal cual. */ body { overflow-x: clip; } /* * P0-1 (QA 2026-08-19): la cabecera sticky no se pegaba en NINGUNA de las 7 páginas * (>=860px) — verificado con scroll real: `top` decrecía 1:1 con el scroll, nunca * quedaba fijo. Causa: `position:sticky` vivía en `.wp-header` (walking-planets.css:91), * cuyo padre DOM es `.elementor-widget-container` — una caja que mide EXACTAMENTE lo * mismo que `.wp-header` (ambas ~85px, sin "recorrido" para que el sticky se desplace: * un elemento sticky solo puede moverse dentro de la altura de SU PADRE DOM inmediato). * `.elementor-location-header` (el

que envuelve TODO el template de Theme * Builder, hijo directo de ) sí tiene recorrido de sobra, porque su padre es * (toda la página). Gotcha ya documentado en el knowledge del fleet * (hestiacp-aprendizajes.md §Elementor/Theme Builder, 2026-08-12): el sticky de una * cabecera de Theme Builder va en `.elementor-location-header`, nunca en un envoltorio * interior. `.wp-header` conserva su propio `position:sticky` (walking-planets.css, sin * tocar): al no tener recorrido dentro de su propio padre no hace nada por su cuenta, * solo viaja pegado dentro de `.elementor-location-header`, que es quien de verdad se * fija. Verificado con scroll real (Playwright, 3 páginas x 1440/768): `top` se queda * en 0 en vez de decrecer con el scroll. */ header.elementor-location-header { position: sticky; top: 0; z-index: 60; } /* * P0-2 (QA 2026-08-19), Tour (columna de reserva) y Travel Guide (aside de venta): * el QA diagnosticó "doble .wp-sticky anidado" en Tour, pero la causa raíz es más * profunda y afecta también a Guide (que solo tiene UN .wp-sticky, y tampoco pegaba). * `.wp-tour-grid`/`.wp-article-grid` son grids reales de 2 columnas * (grid-template-columns con 2 valores, walking-planets.css:216 / * walking-planets-extras.css:60), pero Elementor envuelve SIEMPRE los hijos de un * Container en un único `.e-con-inner` — así que ese wrapper (UN solo hijo) ocupa * entera la primera columna del grid, y dentro de él, contenido + columna sticky * quedan apilados EN VERTICAL en vez de en las 2 columnas (verificado con * getBoundingClientRect: el ancho del `.e-con-inner` coincide exacto con el primer * valor de grid-template-columns, y la 2ª columna queda vacía). Con todo apilado en * una sola columna angosta, ninguno de los dos elementos sticky tiene recorrido real * — venga o no duplicada la clase `wp-sticky` en el contenedor de Elementor. * No se toca `_elementor_data` (fuera de alcance de este fix): se "desenvuelve" el * wrapper de Elementor con `display:contents` — técnica CSS estándar para que sus * hijos (contenido + sticky) pasen a ser los ítems DIRECTOS del grid. Con eso caen * cada uno en su columna. Verificado con scroll real (Playwright, muestreo fino cada * 200px: el plateau en Tour/Guide vive en una ventana estrecha del scroll total, un * muestreo grueso por porcentaje de página lo salta por completo y parece "no pega"). * * SEGUNDA CAUSA en Tour, descubierta al verificar (no la vio el QA): una vez * desenvuelto el `.e-con-inner`, la columna sticky (`.elementor-element-868ca79`, que * en Tour ES DIRECTAMENTE el ítem del grid) seguía sin recorrido — porque el propio * `align-items:start` de `.wp-tour-grid` (walking-planets.css:216) NUNCA estaba * ganando: `.e-con-boxed.e-flex{align-items:normal}` (Elementor `frontend.min.css`, * 2 clases, especificidad 0,2,0) le gana (comprobado iterando `document.styleSheets` * en el navegador real). Con `align-items:normal` (=stretch en grid), la columna * ESTIRA su propia caja para igualar la altura de la fila -> vuelve a medir lo mismo * que su propio contenedor, cero recorrido otra vez. Se sube la especificidad * repitiendo las clases reales del elemento (3 clases, 0,3,0) SOLO para * `.wp-tour-grid` — NO para `.wp-article-grid` (ver nota siguiente, Guide necesita * justo lo contrario). * * OJO — Guide necesita `align-items:normal` (el que YA gana ahí, sin tocar nada): * en Guide el sticky (`.wp-article-aside`) NO es el ítem del grid — está 2 niveles * por debajo (item del grid -> `.elementor-widget-container` -> `