` (clase `elementor-edit-area`), no en un `

` real — ese `

` solo aparece cuando la plantilla se imprime en su ubicación real dentro de una página (Home, ficha de producto, etc.). Como todo este archivo parte de `header.elementor-location-header` (selector de TIPO de etiqueta), nada podía coincidir con un `

`, por más que la clase estuviera bien. Fix: `:is(header,div).elementor-location-header` en los 126 selectores del archivo — misma especificidad exacta que antes (`:is()` toma la del argumento más específico, y `header`/`div` son ambos selectores de tipo), no se reordena nada frente a estilos.css. Así el CSS real se ve igual editando desde la plantilla Header directamente que en el sitio publicado. ============================================================================= */ /* ============================================================================= 1. ENVOLTORIO: sticky y onda ============================================================================= */ :is(header,div).elementor-location-header:has(.lij-header-bar) { position: sticky; top: 0; z-index: 100; background-color: var(--lij-red); } /* --- 1.1 Desbloqueo del sticky ------------------------------------------- OBSTÁCULO REAL VERIFICADO: el tema fija `overflow-x: hidden` en html y en body, y lo hace en los dos rangos, así que aplica siempre: estilos.css:4342-4347 @media (min-width: 768px) estilos.css:3160-3166 @media (max-width: 767px), con !important `overflow-x: hidden` convierte al elemento en contenedor de scroll, y eso anula `position: sticky` en sus descendientes. La corrección es cambiar `hidden` por `clip`: recorta el desbordamiento horizontal igual, que es para lo que esas reglas están ahí, pero NO crea contenedor de scroll. Si un navegador no soporta `clip`, ignora la declaración y queda el `hidden` de antes: el header no se fija, nada rompe. */ html:has(.lij-header-bar), body:has(.lij-header-bar) { overflow-x: clip !important; } /* La onda cuelga del envoltorio, no de una fila concreta. Altura y posición tomadas del prototipo: Menu.css `.menu__wave` (41.771px, bottom -41.77px). */ :is(header,div).elementor-location-header:has(.lij-header-bar)::after { content: ''; position: absolute; left: 0; right: 0; bottom: calc(var(--lij-wave-h) * -1 + 1px); height: var(--lij-wave-h); background-image: url('/wp-content/uploads/2026/09/header/lij-header-header-wave.svg'); background-size: 100% 100%; background-repeat: no-repeat; pointer-events: none; z-index: 1; } /* --- 1.3 "Tucked": el header se esconde al bajar, deja solo la onda ------- Implementa Menu.tsx/.css de v2 (2026-09-23, ver js/lij-header.js para la lógica de scroll — mismo umbral de 8px, misma excepción "cerca del tope" y "algo abierto"). Mismo criterio de accesibilidad que v2: si hay foco de teclado dentro, no se esconde (`:has(:focus-visible)`). CORREGIDO 2026-09-23 (2 intentos, el primero insuficiente — ver historial en `docs/SESSION_LOG.md` esa fecha): el transform se aplica al ENVOLTORIO exterior (mismo elemento que ya es `position: sticky` y lleva la onda como `::after`, §1), NO a `.lij-header-bar` — replicando la arquitectura real de v2, donde fondo, contenido Y onda son el MISMO elemento (`.menu`) y por eso se van juntos al trasladarse. El primer intento trasladaba solo `.lij-header-bar` (la barra interior), dejando el envoltorio fijo "para que la onda no se moviera" — pero eso es exactamente lo que v2 NO hace: en v2 la onda se desplaza junto con el resto y término aterrizando arriba del todo porque cuelga por fuera de la caja (`bottom: -41.77px`) una distancia casi igual a la propia altura del header, así que el `translateY(-100%)` la deja justo a la vista mientras todo lo demás sale de cuadro. Con el envoltorio fijo, la onda de WordPress se quedaba ~84px más abajo de lo debido (pegada al borde inferior de una caja que seguía ahí, sticky, sin moverse), dejando un hueco arriba por el que se veía lo que hubiera detrás (en la home, el rojo de "Colecciones destacadas") en vez de la nada — parecía "una barra vacía" aunque su fondo ya se hubiera puesto transparente. Trasladar el envoltorio entero resuelve las dos cosas a la vez: la onda se mueve con él y termina en la posición correcta (arriba del todo), y ya no hace falta ningún ajuste de `background-color` aparte (el fondo se va con el resto, como en v2). */ :is(header,div).elementor-location-header:has(.lij-header-bar) { /* 300ms, igual que Menu.css `.menu` (`transition: transform 0.3s ease`) — estaba en 200ms, más rápido de lo debido. */ transition: transform 300ms ease; } :is(header,div).elementor-location-header:has(.lij-header-bar.lij-header--tucked):not(:has(:focus-visible)) { transform: translateY(-100%); } @media (prefers-reduced-motion: reduce) { :is(header,div).elementor-location-header:has(.lij-header-bar) { transition: none; } } /* El megamenú y el foco tienen que poder salir del header. */ :is(header,div).elementor-location-header:has(.lij-header-bar), :is(header,div).elementor-location-header .lij-header-bar, :is(header,div).elementor-location-header .lij-header-bar > .e-con-inner { overflow: visible; } /* --- 1.2 Corrección de solape de la onda en páginas sin sección propia ---- MISMO PROBLEMA ya documentado y corregido en Home, Ficha de producto (lij-product.css `.ficha-producto`), Colecciones (lij-collections.css) y Resultados de búsqueda/Novedades: la onda cuelga POR DEBAJO de la caja del header (ver arriba, §1) y se superpone a lo que venga justo despues. Si esa primera sección no reserva ese espacio con su propio `padding-top`, la onda roja tapa literalmente el título — verificado con Playwright: en Carrito y en Acceso/Registro el H1 quedaba a solo 0-8px del borde del header, con la onda (42px) cortándolo a la mitad. Estas 7 páginas reales (construidas enteramente en Elementor, sin Theme Builder de por medio) tenían ese mismo hueco sin corregir. Se aplica el mismo criterio que en todos los casos anteriores: `padding-top`, nunca `margin-top` (un margin dejaría un hueco gris del body en vez de pegar el fondo de la sección al header — ver lij-product.css y WAVES_SHAPES.md). Selector: la clase que Elementor ya genera para cada contenedor (`elementor-element-`), sin tocar `_elementor_data` ni la BD. */ .page-id-85 .elementor-element-3c05d35d, /* Crear cuenta de cliente */ .page-id-106 .elementor-element-4f4abae8, /* Condiciones de uso */ .page-id-109 .elementor-element-9ffe3c5, /* Política de cookies */ .page-id-112 .elementor-element-7f1c5ef0, /* Condiciones de compra */ .page-id-115 .elementor-element-2a1fcf0e, /* Acceso/Registro de clientes (también sirve de checkout sin sesión) */ .page-id-119 .elementor-element-5485dc7b, /* Carrito de la compra */ .page-id-122 .elementor-element-f0f6638 { /* Política de privacidad */ padding-top: var(--lij-wave-h) !important; } @media (max-width: 767px) { /* Hasta el 2026-10-07 la onda bajaba a 24px en este rango y aquí se repetía ese valor. Ahora mide 42px en todos los anchos (v3); el valor se mantiene literal porque estos contenedores son hermanos del header, no descendientes, y no heredan su variable. */ .page-id-85 .elementor-element-3c05d35d, .page-id-106 .elementor-element-4f4abae8, .page-id-109 .elementor-element-9ffe3c5, .page-id-112 .elementor-element-7f1c5ef0, .page-id-115 .elementor-element-2a1fcf0e, .page-id-119 .elementor-element-5485dc7b, .page-id-122 .elementor-element-f0f6638 { padding-top: 42px !important; /* la onda mide 42 también aquí (v3) */ } } /* ============================================================================= 2. LA FILA ----------------------------------------------------------------------------- Geometría del prototipo (Menu.css): .menu padding 24px 32px 4px .menu__logo 56px de alto, 16px de separación a su derecha .menu__sections pildoras + lupa JUNTAS, gap 8, padding-right 32 .menu__nav-items min-width 1px, overflow-x auto <- se comprime .menu__search 383px, flex-shrink 0 <- no se comprime .menu__social gap 8 La clave del comportamiento: las píldoras y la lupa van pegadas (8px) y separadas de las redes por 32px. Cuando el buscador se despliega, es la fila de píldoras la que cede el ancho, porque tiene `min-width: 0` y desborda con scroll, mientras que el buscador no encoge. Ese es el efecto de "el menú se desplaza a la izquierda" al abrir la lupa: no es que el buscador se dibuje ENCIMA del menú (son hermanos en la misma fila flex, nunca se superponen), es que el menú literalmente pasa a medir menos. Equivalencia en el DOM de WordPress: .logotipo (contenedor) · widget del menú · .buscador · .opciones EL ANCHO DEL BUSCADOR SE FIJA EN EL CONTENEDOR (.buscador), NO EN EL FORMULARIO DE DENTRO. Esto es un cambio de arquitectura respecto a una versión anterior que ponía `min-width` en el `

`, cuatro capas más adentro (widget → .elementor-widget-container → .elementor-shortcode → .widget_product_search → form), confiando en que el ancho subiera por esa cadena. MEDIDO en el navegador: no siempre llegaba al valor pedido (383px solicitados, 261px reales), porque cada capa intermedia puede recortar antes de que el valor llegue arriba. Fijar `flex-basis` directamente en el contenedor no depende de esa cadena: es la propiedad que decide el ancho del ítem flex, medida y confirmada como la única palanca que responde de forma fiable contra el sistema de anchos por variable de Elementor (ver `wp-content/uploads/lij-referencia/prueba-ancho.html`, once estrategias probadas). El `` de dentro simplemente se estira al 100% de lo que el contenedor le da (sección 6). ============================================================================= */ :is(header,div).elementor-location-header .lij-header-bar, :is(header,div).elementor-location-header .lij-header-bar > .e-con-inner { position: relative; z-index: 2; display: flex; flex-direction: row; flex-wrap: nowrap; align-items: center; gap: var(--lij-space-xxs); } /* Elementor trae su propio `min-height` para este contenedor (64px en escritorio, pero 90px/60px en sus breakpoints de tablet/mobile_extra — VERIFICADO en `wp-content/uploads/elementor/css/post-62.css`, incluso recién regenerado desde Herramientas > Regenerar CSS: no es caché vieja, es un valor real del panel). Si la ventana cae en alguno de esos rangos intermedios, ese min-height gana porque nuestra fila no lo tocaba, y la altura deja de ser 84px. Se anula aquí, sin importar el breakpoint. */ :is(header,div).elementor-location-header .lij-header-bar { min-height: auto !important; } /* ALTO DE LA FILA: 84px (56 del logo + 24 arriba + 4 abajo), medido en el maestro visual (nodo Figma 105:185 "menu"). HISTORIA: hasta la Fase 4f, el header vivía en modo "boxed" y Elementor envolvía sus hijos en un `.e-con-inner` real (no hipotético, verificado en el HTML servido) — el padding vertical iba SOLO ahí, porque declararlo también en `.lij-header-bar` lo duplicaba (24+4 arriba y otra vez 24+4 adentro = 112px de alto en vez de 84px). Fase 4g (2026-09-08): el header pasó a `content_width: full` (ver `redesign/FASE-4-HEADER.md` §17) y Elementor deja de renderizar `.e-con-inner` por completo en ese modo — confirmado en el DOM. La regla de arriba dejó de aplicarse (padding volvía a 0, la fila subía a 120px). El padding vertical y el horizontal se configuraron en el propio panel de Elementor, control "Padding" del contenedor del header (24/32/4/32px, top/right/bottom/left) — nativamente, sin CSS. PARCIALMENTE EFECTIVO — el vertical sí, el horizontal no. Verificado con el navegador real: la variable que genera Elementor (`--padding-left: 32px`, incluso `--padding-inline-start: 32px` ya resuelta) es correcta, pero el `padding-left`/`padding-inline-start` REALMENTE aplicado seguía midiendo 24px. El vertical (`padding-top`/`padding-bottom`) sí toma su variable sin problema. No se pudo aislar qué regla exacta gana esa pelea solo por horizontal — se probó listar las reglas CSS que matchean el contenedor vía `document.styleSheets` y ninguna candidata clara apareció con el valor 24px literal; probablemente un mecanismo interno de Elementor para contenedores full-width que no expone su fuente con claridad. Con el mismo criterio que el resto de este archivo (Elementor primero; CSS solo cuando el panel no alcanza), el horizontal se fuerza aquí. El vertical se deja fuera de este archivo a propósito: ya funciona nativamente, forzarlo también sería redundante. */ :is(header,div).elementor-location-header .lij-header-bar { padding-left: var(--lij-space-l) !important; padding-right: var(--lij-space-l) !important; } /* El logo no encoge y deja 16px a su derecha, como en el prototipo: 8 de relleno más los 8 de hueco de la barra (antes 16 + 8, y la tira de pestañas desbordada empezaba 8px más a la derecha que en v3). */ :is(header,div).elementor-location-header .lij-header-bar .logotipo { width: auto; max-width: none; flex: 0 0 auto; padding-right: var(--lij-space-xxs); } /* El widget del menú es el único que cede ancho de verdad. `flex-shrink: 1` más `min-width: 0` es lo que permite que baje por debajo del ancho de su contenido; sin `min-width: 0` un ítem flex nunca encoge más allá del ancho mínimo de su contenido (aquí, la anchura que ocuparía el texto más largo, "Licencias digitales", sin envolver), y el buscador no tendría sitio. `flex-grow: 1` es lo que hace que el menú absorba cualquier hueco sobrante cuando el buscador está colapsado (38px): ocupa toda la fila disponible, dejando las píldoras+lupa pegadas a las redes en vez de "flotando" en el centro. BUG REAL VERIFICADO (Fase 4g, 2026-09-08): esta regla apuntaba a `.e-con-inner > .elementor-widget-shortcode`. Al pasar el header a `content_width: full`, `.e-con-inner` deja de existir y la regla dejó de aplicarse — el widget del menú volvió a su `flex: 0 1 auto` por defecto de Elementor (no crece), y un `flex_justify_content: space-between` que ya traía el contenedor (antes inerte, porque el flex-grow del menú se comía todo el espacio libre y no le dejaba nada que repartir) quedó expuesto: repartía el hueco entre los 7 hijos del header en vez de concentrarlo a la izquierda del menú. Efecto visible: 226px de hueco entre la lupa y las redes en vez de los ~40px del maestro visual. Corregido apuntando al DOM actual (hijo directo de `.lij-header-bar`, sin `.e-con-inner` de por medio); se conserva también el selector viejo por si el header alguna vez vuelve a modo "boxed". */ :is(header,div).elementor-location-header .lij-header-bar > .e-con-inner > .elementor-widget-shortcode, :is(header,div).elementor-location-header .lij-header-bar > .elementor-widget-shortcode { flex: 1 1 0% !important; min-width: 0 !important; } /* BUG REAL VERIFICADO (Fase 4i, 2026-09-08): con el widget del menú ya creciendo correctamente (regla de arriba), Francisco reportó que las píldoras se veían pegadas a la IZQUIERDA en vez de a la derecha, junto al buscador — un defecto distinto al de la regla de arriba, no una regresión de ese fix. Causa: Elementor envuelve el shortcode en una capa intermedia, `.elementor-shortcode`, que trae `display: inline-block` por defecto — se ajusta al ancho de SU CONTENIDO (963px, lo que ocupan las píldoras) en vez de llenar los 1505px que su padre `.elementor-widget-container` (ese sí `display: block`, correctamente al 100%) le da. El `margin-left: auto` del primer

(sección 4) alinea las píldoras a la derecha DENTRO del `

` que en el shortcode envuelve tanto el `` como el `.search-overlay`, el primer ancestro común de los dos. */ :is(header,div).elementor-location-header .lij-header-bar .buscador .widget_product_search { position: relative; } /* --- 2.1 BUG REAL VERIFICADO (2026-09-08, primera vez con render real vía Playwright en este entorno): el widget de Elementor que envuelve el shortcode (`elementor-element-133f47cb`) tiene, en el panel, la MISMA clase custom `buscador` que su contenedor padre (`elementor-element-7f11abbe`, sección 2). Las dos capas son descendientes de `.lij-header-bar`, así que la regla de arriba, `.lij-header-bar .buscador { flex: 0 0 383px !important; width: auto !important; }`, no distingue entre ellas y cae TAMBIÉN sobre el widget interno, con más fuerza que el `width: 100%` (sin !important) que le tocaba por el bloque de arriba. Consecuencia medida en el navegador: el widget interno queda fijo en 383px SIEMPRE, porque el JS de colapso (sección 6.2) solo añade `.lij-search--collapsed` al contenedor exterior (es el primer `.buscador` en el DOM, es a él al que apunta `document.querySelector`), nunca a este widget. El contenedor exterior sí se encoge a 38px, pero su único hijo, congelado en 383px con `overflow: visible` en el contenedor, se sale de esa caja y queda centrado sobre el punto de 38px: el botón visible de la lupa terminaba renderizado ~172px a la derecha de donde debía, encima del icono de YouTube. Esto es la causa del defecto que Francisco reportó ("el buscador aparece a la derecha de las redes"), no reproducible antes solo leyendo DOM/CSS (ver FASE-4-HEADER.md §10.1 y NEXT_ACTIONS.md). Fix: el widget interno (identificable porque, a diferencia del contenedor, sí tiene la clase `elementor-widget-shortcode`) se fuerza siempre a llenar el 100% de lo que el contenedor le da, en vez de pedir su propio ancho. Así el colapso/apertura, que ya funciona en el contenedor, se refleja también en este nivel. No se toca el panel de Elementor (evita una escritura en BD): es un ajuste de CSS puro. */ :is(header,div).elementor-location-header .lij-header-bar .buscador.elementor-widget-shortcode { flex: 1 1 auto !important; width: 100% !important; max-width: none !important; } /* Las redes, separadas 40px del bloque de menú + lupa, igual al maestro visual (nodo Figma 105:185: "sections" con pr-32 + el gap-8 de "tabs" entre "sections" y "social" = 40). Aquí no hay ese anidado de "sections" dentro de "tabs": todo cuelga plano de la misma fila con `gap: 8px` (sección 2), así que el resto (32px) se suma aquí con `margin-left`. `!important`: este contenedor viene de una estructura de 3 columnas anterior (`structure:"30"` en el panel) y todavía carga un `width:28%` real desde Elementor (verificado en `post-62.css` recién regenerado, no es caché vieja). Sin `!important` aquí, ese 28% puede ganarle a nuestro `flex:0 0 auto` en algunos casos y encajonar las redes/el buscador de forma inesperada. */ :is(header,div).elementor-location-header .lij-header-bar .opciones { flex: 0 0 auto !important; width: auto !important; max-width: none; display: flex; align-items: center; gap: var(--lij-space-xxs); margin-left: var(--lij-space-l); padding: 0; } /* ============================================================================= 3. LOGO ============================================================================= */ /* RESUELTO 2026-09-23: el logo real del sitio (Personalizar > Identidad del sitio > Logo, `custom_logo`) ya apunta al adjunto correcto (`lij-header-logo-content.svg`, id 48550, subido en la Fase 4 y ya en la Biblioteca de Medios) — antes apuntaba a `grupo-sm-logo.svg` (marca corporativa genérica, no la "SM Libros" del maestro visual) y este archivo compensaba la diferencia con un hack de `content:` sobre el . Causa real de que el logo correcto nunca se hubiera fijado en el Personalizador: el adjunto 48550 tenía `post_mime_type` vacío (en vez de `image/svg+xml`) y `_wp_attachment_metadata` incompleto — WordPress no podía resolverlo como imagen (`has_custom_logo()` devolvía `false`), así que el logo se parcheaba solo por CSS. Corregido `post_mime_type`/metadata del adjunto (mismo mecanismo que usa el plugin `svg-support` ya activo) y actualizado `custom_logo` al adjunto correcto — ver `docs/DECISIONS.md` 2026-09-23. Solo queda el tamaño real del logo dentro del header, ya no la sustitución de imagen: así un cambio futuro de logo desde el Personalizador/Elementor sí se refleja aquí, en vez de quedar oculto por este `content:`. */ :is(header,div).elementor-location-header .lij-header-bar .elementor-widget-theme-site-logo img { height: 56px; width: auto; max-width: none; } /* BUG REAL VERIFICADO (Fase 4i, 2026-09-08): el widget trae, desde antes del rediseño, un margen propio de `2em 1em 2em 0em` (`_margin` en el panel de Elementor — 32px arriba y abajo, pensado para un header mucho más alto que el actual). El `content:` de arriba cambia la imagen que se PINTA, pero no toca ese margen: 56px del logo + 32+32px de margen = 120px de alto para este widget. Con la fila a altura fija (84px, como estaba en modo "boxed") ese sobrante no se notaba, absorbido por el `overflow: visible` de la sección 1. Al pasar a `content_width: full` (Fase 4g) la fila dejó de tener una altura fija — pasa a medir lo que su hijo más alto pida — y esos 120px del logo empujaron toda la fila a 148px. Se neutraliza el margen aquí, dentro del contexto del header, sin tocar el widget para el resto del sitio (si el logo se usa en otra plantilla). */ :is(header,div).elementor-location-header .lij-header-bar .elementor-widget-theme-site-logo .elementor-widget-container { margin: 0 !important; } /* ============================================================================= 4. NAVEGACIÓN — las píldoras ============================================================================= */ /* Marcado real de [menu_principal]: