/* ==========================================================================
   correcciones.css — hoja de estilos propia del sitio
   ==========================================================================

   POR QUE EXISTE

   El CSS antiguo vive en media/estilos/css/style.css, y media/ esta en el
   .gitignore: lo que se edita ahi no queda versionado ni se despliega con el
   repositorio. Este archivo esta FUERA de media/, asi que si se versiona y
   viaja con el resto del sitio.

   COMO FUNCIONA

   Se carga en ultimo lugar, despues de todas las demas hojas, y usa !important
   en las declaraciones que tienen que ganarle al CSS antiguo. No se toca ni una
   linea de style.css: lo viejo se queda como esta y aqui se corrige encima.

   Al añadir algo nuevo, dejar escrito el POR QUE y la medida que lo justifica.

   ========================================================================== */


/* --------------------------------------------------------------------------
   1. Margenes de los envoltorios de banners
   --------------------------------------------------------------------------

   Los cinco envoltorios de banners llevaban en style.css margenes superiores
   negativos grandes y margenes inferiores enormes, ajustados a mano para un
   layout anterior. Medido en el navegador a 1024px de ancho:

     .bannercoricoendura     0 / 290px   ->  305px de hueco vacio debajo
     .bannercorico           0 / 290px   ->  305px de hueco vacio debajo
     .bannericonevera      -20 / 490px   ->  505px de hueco vacio debajo
     .bannernev           -420 / 0       ->  tapaba un div.col-lg-6
     .bannercor           -200 / 0       ->  ver la nota de abajo

   Ademas .bannercorico y .bannercoricoendura tenian su margin-top redefinido
   en cinco media queries de style.css (-110px entre 1199 y 1470 y entre 1199 y
   1900, 0px entre 992 y 1729 y entre 768 y 991, -50px por debajo de 767), asi
   que el valor efectivo cambiaba con el ancho de la pantalla y el mismo banner
   se veia distinto en cada monitor.

   NO hace falta repetir el valor dentro de esos rangos: la regla de abajo no
   lleva media query, va con !important y esta hoja se carga en ultimo lugar,
   asi que le gana a las cinco. Verificado midiendo margin-top en el navegador a
   375, 800, 1100, 1300, 1500, 1800 y 1950px: sale 0px en todos, sin huecos ni
   solapes, en las seis combinaciones de clases que se usan en el sitio.

   Nota sobre .bannercor: su -200px parecia correcto en aislado, porque no
   dejaba hueco ni solapaba. Lo compensaba el margin-bottom de 290px del
   .bannercorico que lo precede. Al corregir ese, .bannercor quedaba solapando
   200px el slider de iconos, y 101 de sus 102 paginas llevan ambos elementos.
   De ahi que tambien se ajuste.                                              */

.bannercor,
.bannercorico,
.bannercoricoendura,
.bannernev,
.bannericonevera {
   margin-top: 0 !important;
   margin-bottom: 0 !important;
}

.footer__copyright__text p {
   color: #666666;
}

/* Aqui hubo un bloque @media que repetia margin-top: 120px para .bannercorico y
   .bannercoricoendura por encima de cierto ancho. Se quito: el valor definitivo
   es 0 en todos los anchos, y la regla de arriba ya lo garantiza sin necesidad
   de media queries. Si en el futuro hiciera falta un valor distinto por ancho,
   medir primero: los margenes de style.css estan pensados para un layout que ya
   no existe y cualquier valor heredado de ahi es sospechoso. */


/* --------------------------------------------------------------------------
   2. El mega menu se cerraba al bajar el raton hacia el
   --------------------------------------------------------------------------

   El desplegable se abre con '.menu > li:hover .dropdown', asi que depende de
   que el puntero no salga nunca del li. Pero entre el enlace y el desplegable
   hay una banda muerta, medida en el navegador:

     borde inferior del enlace     108.8px
     borde inferior del header     118.8px   <- 10px de su padding-bottom
     borde superior del desplegable 128.8px  <- otros 10px de aire

   Son 20px en los que 'document.elementFromPoint' devuelve HEADER o BODY, o sea
   nada que pertenezca al li: al cruzarlos se pierde el :hover y el menu se
   cierra antes de llegar. Medido a 993, 1024, 1200, 1366, 1440, 1600 y 1920px:
   son 20px exactos en todos, porque el padding del header no cambia.

   La solucion es un puente invisible que cubre esa banda. Tiene que ser algo
   que pertenezca al li, porque el :hover que hay que mantener vivo es el del li.

   OJO, EL PUENTE COLGABA DEL .dropdown Y HUBO QUE MOVERLO. Hasta el 30 de julio
   de 2026 era '.menu > li > .dropdown::before' con 'bottom: 100%', o sea una
   caja pegada por FUERA del borde superior del desplegable. Al darle al
   desplegable 'overflow-y: auto' (apartado 9) eso dejo de funcionar: un
   contenedor de scroll recorta a sus descendientes posicionados, y el ::before
   esta fuera de su caja, asi que desaparecia y volvia el problema original.
   Medido con elementFromPoint sobre la banda, 27 puntos: 27 cubiertos con el
   puente viejo y overflow visible, 0 con el puente viejo y overflow auto.

   Ahora cuelga del propio li ('.menu > li:hover::after'), que esta fuera del
   contenedor de scroll y por tanto no se puede recortar. Como el li es
   'position: static' (ver apartado 7), su bloque contenedor es el header, asi
   que 'left/right: 0' hace que el puente ocupe el ancho completo del header.
   Es mas ancho que el puente viejo, que solo ocupaba el del desplegable, y eso
   viene bien: cubre tambien el movimiento en diagonal hacia una columna
   lateral, que es el habitual. La contrapartida es que mientras el puntero esta
   sobre un item del menu hay una banda invisible de 20px cruzando la pantalla
   por debajo de la cabecera; solo existe durante el hover.

   Va en ':hover' y no en el li a secas a proposito: si estuviera siempre, esa
   banda taparia de forma permanente los 20px de pagina que hay bajo la
   cabecera. El puente viejo no tenia el problema porque el .dropdown esta en
   display: none mientras no hay hover.

   'bottom: -10px' con 'height: 20px' lo deja abarcando desde el borde inferior
   de los enlaces (10px por encima del borde del header, que es su
   padding-bottom) hasta 10px por debajo del header. Referido al borde inferior
   del header y no a medidas absolutas, asi que sirve igual en las paginas donde
   el header mide 76px en vez de 74. Verificado con elementFromPoint:
   27 de 27 puntos cubiertos con el desplegable pegado al header y 57 de 57 en
   la posicion de reposo, que es la banda mas ancha de la transicion.

   Una mejora de rebote: el puente viejo tapaba los ultimos 10px de los enlaces
   del menu ("Aliados" incluido, que es el unico enlace real de los seis) y el
   nuevo arranca justo donde los enlaces acaban, asi que ya no los pisa.

   height es 20px porque 20 es el hueco EN REPOSO, que es el caso peor. Ojo con
   esto, que se entendio mal la primera vez: el .dropdown lleva
   'transform: translate(-50%, 10px)' en reposo y la regla de :hover lo pasa a
   'translate(-50%, 0)', o sea que al hacer hover SUBE 10px y se pega al borde
   inferior del header. Entonces:

     en reposo   ->  hueco de 20px  (desplegable en 128.8)
     con hover   ->  hueco de 10px  (desplegable en 118.8, a ras del header)

   Los 20px garantizan que no queda ni un pixel sin cubrir en NINGUN momento de
   la transicion de 0.3s, en la que el desplegable desliza de +10px a 0 y el
   hueco pasa de 20 a 10. Con un puente de 10px habria un instante inicial con
   10px al aire y el menu se cerraria si el raton baja rapido.

   Solo escritorio. Por debajo de 993px el desplegable es position: static y lo
   abre el JS al tocar, asi que ahi no hay hueco que salvar ni conviene meter
   una banda invisible.                                                       */

@media (min-width: 993px) {
   .menu>li:hover::after {
      content: "";
      position: absolute;
      left: 0;
      right: 0;
      bottom: -10px;
      height: 20px;
   }
}


/* --------------------------------------------------------------------------
   3. El menu movil salia estrujado y sin textos legibles
   --------------------------------------------------------------------------

   Dos declaraciones del <style> incrustado se colaban en la vista movil:

   a) 'nav.new-nav { margin-right: 320px }', la regla de escritorio, que la
      media query movil nunca resetea. Esta en las 319 paginas. Con 320px de
      margen el nav se queda sin sitio; medido con el menu abierto:

        viewport 375px  ->  nav de   0px de ancho
        viewport 538px  ->  nav de 102px de ancho

      Con el nav a 0-102px el texto de los enlaces se parte letra a letra en
      vertical: "Aire de ventana" pasaba a medir 293px de alto, el desplegable
      entero 3285px, y no se leia nada. De ahi tambien el abrir y cerrar
      extranos: slideToggle animaba esos 3285px en 300ms.

   b) 'header.new-header > nav.new-nav { position: static }', que se anadio a
      las 20 paginas legacy migradas porque su CSS pone 'header > *' en relative
      y eso anclaba el mega menu al nav en vez de al header. Tiene especificidad
      0,2,2 y pisa el 'position: absolute' de la media query movil (0,1,1), asi
      que en esas 20 el menu movil no era un panel bajo la cabecera sino un item
      mas del flex del header.

   El arreglo va con la misma especificidad que la regla (b) y cargado despues,
   asi que gana sin !important. No hace falta redeclarar top, left ni width: las
   paginas ya los traen en su propia media query, y en cuanto el nav vuelve a ser
   absolute con el margen a 0 vuelven a surtir efecto.

   Solo movil. En escritorio el nav sigue static en esas 20 paginas, que es lo
   que mantiene el mega menu anclado al header.

   Medido con el arreglo a 375, 538 y 992px, en una pagina legacy y en una
   normal: nav en left 0 y con el ancho exacto del body en los seis casos,
   desplegable de 492px, enlaces de 41px de alto, ninguno fuera del viewport y
   sin scroll horizontal.

   NOTA: aqui habia tambien un 'margin-right: 0'. Se quito porque el apartado 7
   ya lo pone a 0 en todos los anchos, no solo en movil. El causante (a) esta
   descrito alli.                                                              */

@media (max-width: 992px) {
   header.new-header>nav.new-nav {
      position: absolute;
   }
}


/* --------------------------------------------------------------------------
   4. En movil el desplegable se iba media pantalla a la izquierda
   --------------------------------------------------------------------------

   El mega menu de escritorio se centra bajo la cabecera con dos declaraciones
   del <style> incrustado:

     .dropdown              { transform: translate(-50%, 10px); }   0,1,0
     .menu > li:hover .dropdown { transform: translate(-50%, 0); }  0,2,1

   La media query movil intenta anularlo con '.dropdown { transform: none }',
   pero eso es especificidad 0,1,0 y la regla de :hover es 0,2,1. Las media
   queries NO suman especificidad, asi que la de hover gana tambien en movil: en
   cuanto el puntero toca un item del menu, el desplegable se desplaza -50% de su
   propio ancho. Medido con el menu abierto:

     viewport 375px  ->  translate(-172.5px)  ->  borde izquierdo en -172px
     viewport 538px  ->  translate(-254px)    ->  borde izquierdo en -254px

   Con eso los 12 enlaces del desplegable quedan fuera de la pantalla por la
   izquierda. No se ve como scroll horizontal porque el body lleva
   overflow-x: hidden, asi que parecia que el submenu simplemente no tenia
   contenido.

   La misma regla de hover fuerza 'display: grid', que por lo mismo tambien gana
   sobre el 'display: none' de la media query movil. Efecto: en vista movil el
   desplegable se abre solo con pasar el raton por encima, sin tocarlo, y eso se
   pelea con el estado que maneja el JS (que abre y cierra por clic escribiendo
   display en el style inline). Se anula igualmente. El JS sigue funcionando
   porque su display inline gana a esta regla.

   Ojo al tocar esto: las dos declaraciones de arriba son GLOBALES y en
   escritorio son justo lo que centra el mega menu y lo que lo abre al pasar el
   raton. Por eso este bloque va dentro de @media (max-width: 992px) y con el
   mismo selector, para ganar por orden de carga sin !important y sin rozar el
   escritorio.

   Verificado reproduciendo el :hover con una clase de identica especificidad
   (una clase cuenta igual que una pseudoclase): sin esto, 12 enlaces fuera del
   viewport a 375 y a 538px; con esto, transform none, el desplegable en left 0 y
   0 enlaces fuera.                                                            */

@media (max-width: 992px) {
   .menu>li:hover .dropdown {
      transform: none;
      display: none;
   }
}


/* --------------------------------------------------------------------------
   5. El grosor del menu se heredaba, y en la portada salia distinto
   --------------------------------------------------------------------------

   La regla '.menu > li > a' trae 'font-weight: var(--main-menu-font-weight)'
   COMENTADA en las 319 paginas (en 38 estaba viva y salian en negrita; se
   comento en el commit 107ed29). Al no declararse, el grosor se HEREDA, o sea
   que cada pagina acaba con el que le toque segun su propio body:

     318 paginas   ->  400
     index.html    ->  300

   Los 300 de la portada vienen de su <style>, que declara
   'body { font-family: Roboto; font-weight: 300 }' a proposito: es la fuente
   Light de su contenido, y ahi cuelgan tambien sus .card y .titulo-pequeno. Por
   eso NO se toca el body: cambiarlo alteraria todo el texto de la portada. Lo
   que se hace es declarar el grosor en los enlaces del menu, que es lo unico que
   se queria igualar.

   Declararlo aqui en vez de descomentar la variable en cada pagina tiene dos
   ventajas: es un archivo en vez de 319, y deja el menu con un grosor propio en
   lugar de a merced del body de cada pagina, asi que una pagina futura con otro
   body no vuelve a desviarse. La variable --main-menu-font-weight (que vale 700)
   queda sin usar a proposito.

   Verificado: 400 en la portada y en las demas, y el menu mide lo mismo en
   todas.                                                                     */

.menu>li>a {
   font-weight: 400;
}


/* --------------------------------------------------------------------------
   6. El margin-right: 320px del nav aplastaba el logo
   --------------------------------------------------------------------------

   El <style> incrustado de las 320 paginas que llevan la cabecera nueva trae:

     nav.new-nav { margin-right: 320px; }   <- con el comentario "Eliminado:
                                               esto podria causar problemas de
                                               layout" al lado, o sea que ya se
                                               habia detectado y nunca se quito

   El header es un flex con justify-content: space-between y tres hijos: .logo,
   el boton de hamburguesa (display: none en escritorio) y el nav. Esos 320px de
   margen reservan a la derecha un hueco que no usa nadie, y el que paga es el
   logo, que es el unico item que puede encoger. Medido en el navegador (ancho de
   ventana, con su barra de scroll):

     ancho    logo ANTES   logo DESPUES
      993px       0px         137px
     1024px       0px         137px
     1100px      53px         137px
     1200px     125px         137px
     1278px     137px         137px

   O sea que entre 993 y 1024 el logo desaparecia por completo, y hasta 1200 se
   veia recortado. 137px es su ancho natural.

   La cura es poner el margen a 0 y dejar que el space-between reparta: el logo
   se queda pegado al borde izquierdo y el nav al derecho, a la distancia que
   marca el padding del header. Medido despues a 993, 1000, 1024, 1100, 1200,
   1278, 1440 y 1920px, en una pagina legacy migrada (balanzas), un listado
   (aire-ventana, neveras), una plantilla (plantilla25kbtu), una de
   especificaciones y la portada: logo de 137px y nav a 40px exactos del borde
   derecho en los ocho anchos, sin scroll horizontal. El caso mas justo es 993px,
   donde quedan 34px de aire entre el logo y el primer enlace del menu.

   No se toca flex-shrink del logo a proposito: si algun dia el menu creciera y
   no cupiera, que encoja el logo es mejor degradacion que un menu desbordado.

   Se arregla aqui y no en los 320 archivos porque el selector es identico al
   suyo y esta hoja carga despues, asi que gana por orden sin !important. Ojo:
   index06-08.html (respaldo) y media/nueva/menusolo.html NO enlazan esta hoja y
   se quedan con sus 320px; las dos estan gitignoreadas y ninguna es una pagina
   viva.

   ESTO ES LO QUE PERMITIO UNIFICAR EL BREAKPOINT. Aqui habia un apartado 6 que
   repetia los apartados 3 y 4 acotados con 'body.breakdance', porque la portada
   pasaba a hamburguesa en 1278px y las otras 318 en 992, y los arreglos escritos
   para 992 dejaban sin cubrir la banda 993-1278 de la portada. La portada usaba
   1278 justamente porque con el logo aplastado el menu de escritorio no se podia
   mostrar antes. Con el margen a 0 ya cabe, asi que index.html se bajo a 992
   (media query y matchMedia del JS) y la excepcion sobra: las 319 paginas usan
   ahora el mismo corte y los apartados 3 y 4 las cubren a todas.             */

nav.new-nav {
   margin-right: 0;
}


/* --------------------------------------------------------------------------
   7. El desplegable no se alineaba con la categoria que lo abre
   --------------------------------------------------------------------------

   Se veia sobre todo en Soporte: una banda blanca de 1200px de ancho con
   "Informacion / Mis Garantias" apretados en la esquina izquierda, a 1200px de
   distancia del enlace que la habia abierto. Son dos causas distintas.

   (a) NO SE ANCLA AL ITEM, SE ANCLA AL HEADER. El <style> de las paginas pone
       '.menu > li { position: static }' y '.dropdown { left: 50%; transform:
       translateX(-50%) }', asi que el contenedor del desplegable es el header y
       sale centrado en la pantalla pulses la categoria que pulses. Eso se hizo a
       proposito, porque anclarlo al li con un min-width: 850px fijo lo sacaba de
       la pantalla (a 1024px "Linea Blanca" se salia 337px por la izquierda).

   (b) SIEMPRE TRES COLUMNAS. 'grid-template-columns: repeat(3, minmax(180px,
       1fr))' crea tres pistas iguales aunque el desplegable tenga una sola
       .column, que es el caso de Soporte. Su unica columna ocupa el primer
       tercio y los otros dos quedan en blanco.

   LA CURA

   (b) se arregla con 'grid-auto-flow: column' y pistas 'max-content': se crea
   una pista por .column, ni una mas, y cada una mide lo que mide su contenido.
   Asi el ancho del panel lo decide el contenido en vez de un 1200px fijo.
   Medido con las pistas a max-content:

     Linea Blanca 741px   Linea Menor 730px   Empotrables 787px
     Electronica  790px   Soporte     154px

   (a) se arregla alineando el BORDE DERECHO del panel con el borde derecho de
   su enlace. Tiene que ser el derecho y no el izquierdo: el menu va pegado a la
   derecha del header, asi que la distancia de cada enlace al borde derecho es
   pequena y cada panel es MAS ancho que ese hueco. Alinear por la izquierda
   sacaria de la pantalla a los cinco, incluido "Linea Blanca" (727px de hueco
   para un panel de 741). Por la derecha caben todos.

   Como el nav va pegado a la derecha con el padding de 40px del header, la
   distancia de cada enlace al borde derecho del header ES CONSTANTE, no depende
   del ancho de la ventana. Por eso basta un 'right' fijo por categoria, sin
   JavaScript. Medidas, del borde derecho del padding del header al borde derecho
   de cada enlace:

     1 Linea Blanca  614px      4 Electronica  201px
     2 Linea Menor   474px      5 Aliados      (no tiene desplegable)
     3 Empotrables   332px      6 Soporte        0px

   El desplegable se sigue anclando al header, no al li: el li se queda static y
   asi no vuelve el problema que motivo (a). El 'right' se mide contra la caja de
   padding del header, que es justo lo que necesitamos.

   EL CLAMP, QUE ES LO QUE EVITA QUE SE SALGA

   En pantallas estrechas no hay sitio a la izquierda para alinear del todo: a
   993px el header mide 913px por dentro y el panel de Linea Blanca necesita
   614 + 741 = 1355. Por eso el 'right' va dentro de un clamp() cuyo tope
   superior es 'calc(100% - <ancho del panel>)': cuando no cabe, el panel se
   desliza hacia la derecha hasta quedar a ras del borde izquierdo del header, en
   vez de salirse. El contenido NO se estruja en ningun momento.

   Los anchos del clamp van redondeados hacia arriba sobre lo medido. El redondeo
   sobra siempre por el lado bueno: si el panel real fuera mas ancho de lo
   medido, el tope solo deja un poco mas de aire a la izquierda.

   A partir de que ancho queda alineado exacto cada uno:

     Soporte      siempre        Empotrables   1182px
     Electronica  1142px         Linea Menor   1854px
                                 Linea Blanca  1474px

   Por debajo de eso el panel queda pegado al borde izquierdo del header, que es
   mas o menos donde cae hoy el centrado, o sea que no se pierde nada.

   'nth-child' es posicional y por tanto fragil, pero el menu es el mismo bloque
   de 6 items en todas las paginas y cambiarlo ya es de por si un barrido masivo.

   OJO, ESTAS MEDIDAS CADUCAN. El 30 de julio de 2026 entraron 16 subcategorias
   nuevas y una columna mas en Linea Menor, y los cinco topes se quedaron cortos:
   varios paneles se salieron por la izquierda, Linea Menor hasta 281px. Los
   anchos naturales pasaron a ser 786 / 1051 / 787 / 801 / 154, o sea que Linea
   Menor casi se dobla al pasar de 3 a 4 columnas. Cada vez que se anada, se
   quite o se renombre algo del menu HAY QUE VOLVER A MEDIR y actualizar los
   numeros de abajo: el sintoma es un desplegable que se sale de la pantalla.

   Y HAY QUE MEDIR EN VARIAS FAMILIAS DE PAGINA, NO SOLO EN LA PORTADA. Los
   paneles NO miden lo mismo en todas, porque el <style> incrustado no es
   identico (ver la nota de cabecera-unificada). Medido el 30-07-2026 a 993px en
   cuatro familias:

                        portada   listados   especificaciones
     Linea Blanca         786       786          786
     Linea Menor         1051      1051         1051
     Empotrables          787       787          787
     Electronica          801       875          865
     Soporte              154       162          158

   Los topes de arriba se habian medido solo en la portada, y por eso Electronica
   llevaba 820 cuando en los listados necesita 875: a 993px de ventana su panel
   quedaba con el borde izquierdo en -55px, o sea 55px de menu fuera de la
   pantalla. Los numeros de abajo son del CASO PEOR de las cuatro familias.

   Y HAY QUE DEJAR SITIO A LA BARRA DE SCROLL. Desde el apartado 9 el panel puede
   scrollear, y la barra de scroll de Chrome en Windows anade 15px al ancho de la
   caja (medido: Linea Blanca pasa de 786 a 801 cuando scrollea). Los topes
   incluyen ese margen, asi el numero vale igual scrollee o no.

   Linea Menor ya no cabe entera en el escritorio estrecho: necesita 1051px y a
   993px de ventana el header solo tiene 898 por dentro. Ahi el clamp devuelve su
   minimo, el panel se pega al borde derecho y el ancho lo recorta 'max-width'.
   Se ve apretado pero completo y dentro de la pantalla, que es la degradacion
   buena. Si algun dia molesta, la salida es partir la columna Cocina en dos.

   Solo escritorio: por debajo de 993px el desplegable es 'position: static' y lo
   abre el JS al tocar, ahi no hay nada que alinear.                           */

@media (min-width: 993px) {
   .dropdown {
      /* una pista por columna, del ancho de su contenido, en vez de tres fijas */
      grid-template-columns: none;
      grid-auto-flow: column;
      grid-auto-columns: max-content;

      /* el ancho lo decide el contenido, no un 1200px fijo */
      width: max-content;
      max-width: 100%;

      /* se posiciona por la derecha; el translateX(-50%) del centrado sobra */
      left: auto;
      transform: translateY(10px);
   }

   .menu>li:hover .dropdown {
      transform: translateY(0);
   }

   /* OJO CON LA REFERENCIA DEL 'right'. El bloque contenedor de un absolute es
      la CAJA DE PADDING de su ancestro posicionado, o sea el header ENTERO,
      bordes del viewport incluidos, no su interior. Asi que 'right: 0' deja el
      panel a ras del borde de la pantalla, 40px mas a la derecha del ultimo
      enlace, no alineado con el. Las medidas de abajo son del borde derecho del
      VIEWPORT al borde derecho de cada enlace, que es 40px mas que la distancia
      al interior del header. La primera version de este apartado uso la
      referencia equivocada y los cinco paneles quedaron 40px corridos; no se
      notaba a simple vista, pero estaba mal.

      Y '100%' vale tambien el ancho completo del header, no su interior, cosa
      que importa para el tope del clamp.

      Medido el 30-07-2026 en cuatro familias de pagina: anchos naturales del
      caso peor 786 / 1051 / 787 / 875 / 162. El tope va redondeado hacia arriba
      y con 15px de mas para la barra de scroll del apartado 9. */

   .menu>li:nth-child(1)>.dropdown {
      /* Linea Blanca, 3 col, natural 786 (+15 de barra = 801) */
      right: clamp(0px, 654px, calc(100% - 820px));
   }

   .menu>li:nth-child(2)>.dropdown {
      /* Linea Menor,  4 col, natural 1051 */
      right: clamp(0px, 514px, calc(100% - 1340px));
      /* 1340 = con Cocina a 2 columnas (1308) + 15 de barra */
   }

   .menu>li:nth-child(3)>.dropdown {
      /* Empotrables,  3 col, natural 787 */
      right: clamp(0px, 372px, calc(100% - 810px));
   }

   .menu>li:nth-child(4)>.dropdown {
      /* Electronica,  3 col, natural 875 en los listados (801 en la portada) */
      right: clamp(0px, 242px, calc(100% - 900px));
   }

   .menu>li:nth-child(6)>.dropdown {
      /* Soporte,      1 col, natural 162 */
      right: clamp(0px, 40px, calc(100% - 200px));
   }
}


/* --------------------------------------------------------------------------
   8. La columna Cocina se hizo demasiado larga
   --------------------------------------------------------------------------

   Con las cinco subcategorias nuevas, Cocina paso a 11 entradas y estiraba el
   desplegable de Linea Menor a lo alto. Se parte su LISTA en dos columnas, no
   la columna en el marcado: asi el <h4> sigue siendo uno solo encima de las dos
   mitades, no hay que tocar las 386 paginas y el cambio se deshace borrando
   este apartado. 'break-inside' impide que un enlace se parta al saltar.

   POR QUE VA A PARTIR DE 1360px Y NO SIEMPRE. Partir en dos columnas baja el
   alto pero SUBE el ancho: el panel pasa de 1051 a 1308px. Medido, aplicandolo
   en todos los anchos:

     1440px  ->  se salia 238px por la izquierda
     1280px  ->  se salia 195px
      993px  ->  el panel se recorta a 978 y 5 enlaces quedaban FUERA de la
                 pantalla, o sea inalcanzables

   Eso ultimo es peor que la columna larga, porque con 'column-count' la lista
   ya no puede encogerse y el contenido se desborda en vez de comprimirse. Por
   debajo de 1360px, entonces, Cocina se queda en una sola columna: es mas alta,
   pero cabe entera. El corte solo entra donde hay sitio de verdad.

   Verificado a 993, 1100, 1280, 1360, 1440 y 1920px: ningun panel fuera de la
   pantalla y ningun enlace fuera del viewport en ningun ancho.               */

@media (min-width: 1360px) {
   .menu>li:nth-child(2)>.dropdown>.column:first-child>ul {
      column-count: 2;
      column-gap: 26px;
   }

   .menu>li:nth-child(2)>.dropdown>.column:first-child>ul>li {
      break-inside: avoid;
   }
}

/* --------------------------------------------------------------------------
   9. Los desplegables largos se salian por abajo de la pantalla
   --------------------------------------------------------------------------

   En escritorios de poca altura el panel no cabe de arriba abajo y el final se
   queda fuera de la pantalla, sin forma de llegar a el: el desplegable esta
   dentro de un header sticky, asi que scrollear la pagina no lo acerca, lo
   arrastra consigo. Medido a 1280x720 en un listado, con la ventana sin
   scrollear:

     borde inferior del header        119px
     borde superior del panel         129px
     alto de Linea Blanca             643px  ->  termina en 772, se sale 52px
     alto de Linea Menor              856px  ->  termina en 985, se sale 265px
     alto de Electronica              430px  ->  cabe
     Empotrables y Soporte        146 y 112  ->  caben

   O sea que el que noto el usuario (Linea Blanca) no era el peor: Linea Menor
   se salia cinco veces mas. En las paginas de especificaciones los paneles son
   unos 20px mas altos todavia (663 y 876).

   LA CURA: un alto maximo y scroll propio. Solo aparece barra cuando hace falta,
   asi que en pantallas altas no cambia nada.

   DE DONDE SALE EL calc

     100vh   la altura de la pantalla
     100%    el ALTO DEL HEADER. El panel es absolute y su bloque contenedor es
             el header (ver apartado 7), asi que un porcentaje en max-height se
             resuelve contra el. Se usa el porcentaje en vez de un 74px fijo
             porque el header no mide lo mismo en todas las paginas: 74px en los
             listados y en la portada, 76px en las de especificaciones.
     80px    el aire que hay que descontar, ver abajo.

   Los 80px son el caso peor, que es la pagina SIN SCROLLEAR:

     46px   la .top-bar de las redes, que va ENCIMA del header y empuja el panel
            hacia abajo mientras no se ha scrolleado (45px en los listados, 46 en
            especificaciones; la portada no la tiene). Al scrollear desaparece y
            el header se pega al top: 0, o sea que a partir de ahi sobran estos
            46px y el panel podria ser mas alto. No hay forma de saberlo desde
            CSS, asi que se descuenta siempre; el precio es que en la portada y
            con la pagina scrolleada quedan unos 65px de alto sin aprovechar.
     10px   el translateY(10px) del reposo, que es la posicion mas baja del panel
            durante la transicion de 0.3s.
     24px   margen para que el panel no muera pegado al borde de la pantalla.

   Verificado a 1280x720: Linea Blanca y Linea Menor pasan a 571px de alto con
   scroll interno, terminando 20px por encima del borde inferior; los otros tres
   no scrollean y no cambian de alto.

   DOS COSAS QUE ESTO ROMPIO Y HAY QUE TENER PRESENTES

   1. El puente de hover del apartado 2 colgaba por fuera del panel y un
      contenedor de scroll recorta a sus descendientes posicionados, asi que
      desaparecio y el menu volvia a cerrarse al bajar el raton. Esta reescrito
      alli; si algun dia se quita este apartado, el puente sigue funcionando
      igual. Es el motivo de que este cambio toque dos apartados y no uno.

   2. Los topes del clamp del apartado 7 tuvieron que subir 15px, que es lo que
      la barra de scroll anade al ancho de la caja.

   La regla va sobre '.menu > li > .dropdown' y no sobre '.dropdown' a secas
   porque hay 20 paginas legacy sin mega menu donde '.dropdown' son los submenus
   del plugin SlickNav del menu movil. En esas el mega menu no existe.

   Solo escritorio, como los apartados 2 y 7. Por debajo de 993px el desplegable
   es 'position: static', lo abre el JS al tocar y crece hacia abajo dentro del
   panel del menu movil, que scrollea con la pagina: ahi no hay nada que
   limitar.                                                                    */

@media (min-width: 993px) {
   .menu>li>.dropdown {
      max-height: calc(100vh - 100% - 80px);
      overflow-y: auto;

      /* que al llegar al final del panel la rueda no siga arrastrando la pagina
         por debajo, que con el header sticky da la sensacion de que el menu se
         mueve solo */
      overscroll-behavior: contain;
   }
}


/*ARREGLAR PORTADA RESPONSIVE*/

@media (max-width: 768px) {
   ul.slides {
      height: 60vh;
   }

   .slide-image img {
      width: 100%;
      height: 100%;
      object-fit: cover;
   }
}