/* ══════════════════════════════════════════════════════════════════
   COP · TABS Y CHIPS — UN COMPONENTE DE CADA UNO (Franco, 05/08/2026)
   ------------------------------------------------------------------
   El canon lo eligió Franco: **las tabs y los chips de Champions Clash**
   (`modos-competitivos.html`). No se rediseñó nada — se extrajo lo que
   ya estaba aprobado y se le agregaron las dos cosas que le faltaban:
   el estado DESHABILITADO y el ancho completo.

   ⚠ LA REGLA DE CUÁNDO VA CADA UNO (Franco, 05/08):
       · SUBRAYADO (`.cop-tabs`) cuando cambia la SECCIÓN — te lleva a
         otro contenido: Equipo / Jugadores / Clasificatorio.
       · CHIPS (`.cop-chips`) cuando FILTRÁS una lista que ya está en
         pantalla: ligas, mercados, rareza.
   Sin esa regla vuelven las 21 variantes: cada pantalla eligiendo sola.

   ⚠ ESTE ARCHIVO AGREGA, NO REESCRIBE. `.cop-tab` y `.cop-chip` son
   nombres que no existían en ninguna página, así que enlazarlo no puede
   cambiar nada hasta que se toque el marcado a mano. **Las clases
   viejas se conservan en el marcado** (`class="m-tab cop-tab"`) porque
   17 de las 22 barras tienen JavaScript colgado de ellas
   (`querySelectorAll('.m-tab')`, `closest('.cat-chip')`): renombrarlas
   las rompería EN SILENCIO — la página carga, no hay error en consola,
   y simplemente deja de cambiar de pestaña. Es la misma decisión que
   salvó el registro de íconos (§9quater).

   ⚠ EL COLOR SALE DE UNA SOLA VARIABLE, `--cop-acento`. Por defecto es
   el celeste de la marca; `[data-comp]` la pisa por competencia, que es
   como ya funcionaba en Champions Clash. Agregar una competencia nueva
   es una línea, no repasar veinte reglas.
   ══════════════════════════════════════════════════════════════════ */

:root{ --cop-acento: var(--primary, #0c95eb); --cop-acento-rgb: 12,149,235; }

/* el color lo define la competencia, no el tipo de control (§8octies) */
/* ══════════════════════════════════════════════════════════════════
   ⚠⚠ LA TABLA COMPLETA, Y ES LA ÚNICA (31/08/2026)
   ------------------------------------------------------------------
   Franco: *«quiero que entiendas a lo que voy en mantener coherencia en
   las páginas de picks y competencia: si estoy en una competencia que es
   con tarjetas celestes, los picks, las tabs, los botones, todo tiene
   que ser con ese diseño… en esta de grupos podrías usar solo el color
   violeta como en division league»*.

   ⚠⚠ EL PROBLEMA NO ERA EL VIOLETA: ERAN TRES TABLAS. El color de la
   competencia estaba escrito en tres lugares —esta hoja, el `<style>` de
   `lineup.html` y el de `duelo.html`— y sólo `cop-tarjeta-pick.js` sabía
   qué es `grupo`. Por eso el duelo grupal dibujaba las TARJETAS en
   violeta y las tabs, los botones y los bordes en celeste: no había una
   decisión equivocada, había tres decisiones que no se hablaban.
   Ahora las tres salen de acá, y las dos páginas derivan de esta
   variable en vez de repetir la lista.

   ⚠ ESTÁN TODAS LAS QUE CONOCE `cop-tarjeta-pick.js`, con sus alias
   (`division` igual que `rivals`, `grupos` igual que `grupo`). Una
   competencia que falte no da error: cae en el celeste del `:root`, que
   es exactamente cómo se veía este defecto.
   ══════════════════════════════════════════════════════════════════ */
/* ⚠⚠ TODO CELESTE MENOS DIVISIÓN LEAGUE Y MODO CARRERA (Franco,
   03/09/2026): *«todos los botones y diseños que tengan colores de
   competencias anteriores —el verde de amistosos, etc.— cambialos por
   celeste; las páginas de lineup y los botones de las competencias
   tienen que ser como los de Champions Clash; en grupos de amigos
   también va todo en celeste»*. Antes cada competencia traía su color
   histórico (amistosos verde, torneos azul, equipos/spin/sala dorado,
   draft gris, futbol11 rojo) y grupos iba en violeta. Ahora la única
   familia con color propio es DIVISIÓN LEAGUE —y su alias `rivals`—
   junto con MODO CARRERA, en violeta. Todo lo demás deriva del celeste
   de la marca.
   ⚠ GRUPOS PASÓ DE VIOLETA A CELESTE: la decisión del 30/08 («en grupos
   usá el violeta como en división») queda revertida por pedido expreso.
   ⚠ SE LISTAN TODAS EXPLÍCITAS y no se dejan caer al celeste del `:root`:
   el día que cambie el default, doce competencias no se despintan sin
   que nadie relacione las dos cosas. */
[data-comp="rivals"],
[data-comp="division"],
[data-comp="carrera"]  { --cop-acento: var(--purple, #9d2bff); --cop-acento-rgb: 157,43,255; }
[data-comp="champions"],
[data-comp="amistosos"],
[data-comp="torneos"],
[data-comp="equipos"],
[data-comp="spin"],
[data-comp="sala"],
[data-comp="draft"],
[data-comp="draft-doble"],
[data-comp="draftdoble"],
[data-comp="futbol11"],
[data-comp="grupo"],
[data-comp="grupos"]  { --cop-acento: var(--primary, #0c95eb); --cop-acento-rgb: 12,149,235; }

/* ⚠ MISMA IDEA, OTRO EJE (tanda 2, 05/08/2026). `ligas.html` no cambia
   de competencia sino de LIGA, y la liga Pro ya tenía su subrayado
   violeta resuelto con una regla propia
   (`body[data-liga="pro"] .lgt-btn::after{background:var(--purple)}`).
   Se traduce al mismo mecanismo en vez de dejarle una regla suelta a la
   página: el contexto pisa la variable, el componente no se entera. */
[data-liga="pro"]     { --cop-acento: var(--purple, #9d2bff); --cop-acento-rgb: 157,43,255; }


/* ══ TABS DE SUBRAYADO ═══════════════════════════════════════════════
   Cambian la sección de la pantalla. */
.cop-tabs{
  display:flex;
  gap:var(--gap-sm, .5rem);
  border-bottom:1px solid var(--card-border);

  /* ⚠ ANCHO COMPLETO, DE BORDE A BORDE (Franco, 05/08/2026).
     La barra tiene que llegar al borde FÍSICO de la pantalla: con
     márgenes a los costados se lee como una web, y la app tiene que
     leerse como una app. Es la misma idea que ya regía para los
     carruseles (§CARRUSELES A BORDE DE PANTALLA), ahora también acá.

     La técnica no necesita saber cuánto padding tiene el contenedor de
     cada página —que varía -- : `50% - 50vw` mide exactamente lo que
     sobra de cada lado y lo cancela. Un margen negativo fijo obligaría
     a un número distinto por pantalla, que es justo lo que hoy hace que
     haya 13 alturas y ningún criterio. */
  width:100vw;
  margin-left:calc(50% - 50vw);
  margin-right:calc(50% - 50vw);

  /* ⚠⚠ EL `box-sizing` NO ES PROLIJIDAD: SIN ÉL LA BARRA SE VA DE LA
     PANTALLA (Franco, 22/08/2026, noche: *«la tab de partidos historial
     y recompensas no está centrada y se ve mal, tenés que ponerla
     simétricamente bien»*).
     Abajo el riel se devuelve 16 px de padding de cada lado. Si la
     página no trae el `*{box-sizing:border-box}` —`clash-draft` no lo
     traía, y no tenía por qué: es una regla de cada pantalla— esos
     32 px se SUMAN a los 100vw: el riel mide 422 en una pantalla de
     390. Con `overflow-x:hidden` en el body no aparece barra de scroll;
     simplemente «Recompensas» queda tapada contra el borde derecho y la
     barra se lee corrida hacia la izquierda —16 px de aire de un lado y
     ninguno del otro—. Ninguna medición de «¿llenan el riel?» lo
     marcaba: adentro del riel el reparto era perfecto.
     Lo arregla el componente y no cada página, que es para lo que
     existe el componente. */
  box-sizing:border-box;

  /* ⚠ EL RIEL LLEGA AL BORDE, LAS PESTAÑAS NO (Franco, 05/08/2026).
     Son dos cosas distintas y hay que separarlas: la LÍNEA GRIS es el
     riel sobre el que se mueven las pestañas y tiene que cruzar la
     pantalla entera; el SUBRAYADO ILUMINADO marca en qué pestaña estás
     y por lo tanto tiene que medir lo que mide esa pestaña.
     Estirando las pestañas a un tercio de la pantalla cada una, el
     subrayado celeste medía 138px para la palabra "Logros": dejaba de
     señalar la pestaña y pasaba a ser una franja de color.
     Por eso el padding se devuelve acá: el riel sigue en 100vw y las
     pestañas arrancan alineadas con el contenido de la página. */
  padding-left:16px;padding-right:16px;

  /* con ancho natural pueden no entrar todas (en vivo tiene cinco):
     que se deslicen, en vez de apretarse hasta no leerse */
  overflow-x:auto;
  /* ⚠⚠ 100% ESTÁTICAS EN VERTICAL (Franco, 05/09/2026): *«todas las tabs
     de la página tienen que ser estáticas, ya que ahora si agarro una y
     la subo o bajo se puede mover internamente dentro de ese espacio que
     tienen»*.
     La causa es `overflow-x:auto`: al declarar overflow en UN eje, el
     navegador pone el otro en `auto` también, y en el teléfono eso
     habilita arrastrar la tira hacia arriba y abajo dentro de su caja —
     unos pocos píxeles, suficientes para que se vea flojo.
     Las tres líneas juntas lo cierran:
       · `overflow-y:hidden`      no hay eje vertical que arrastrar
       · `overscroll-behavior`    el rebote no se propaga ni entra
       · `touch-action:pan-x`     el dedo sólo mueve en horizontal, y de
                                  paso el gesto vertical pasa a la página
                                  en vez de quedarse trabado en la tira */
  /* ⚠⚠ ACÁ SE PROBÓ `overflow-y:clip` Y NO SIRVE — queda escrito para
     que nadie lo vuelva a intentar. La especificación dice que si un eje
     es `clip` y el otro NO lo es, el `clip` computa a `hidden`; como este
     riel necesita `overflow-x:auto` para deslizarse, el `clip` se
     degradaba en silencio y el CSS mentía sobre lo que hacía.
     ⚠ LO QUE SÍ RESUELVE EL PEDIDO DE FRANCO es `touch-action:pan-x`:
     le dice al navegador que en este elemento el dedo SÓLO mueve en
     horizontal. Un arrastre vertical no lo toca —se lo lleva la página,
     que es lo correcto— y ahí termina el «se puede mover internamente».
     Queda 1 px de sobra medido (el subrayado de la pestaña activa vive
     en `bottom:-1px` para tapar la línea del riel), pero es alcanzable
     sólo por JavaScript, no por el dedo. */
  overflow-y:hidden;
  overscroll-behavior-x:contain;
  overscroll-behavior-y:none;
  touch-action:pan-x;

  scrollbar-width:none;-webkit-overflow-scrolling:touch;
  scroll-padding-left:16px;scroll-padding-right:16px;
}
.cop-tabs::-webkit-scrollbar{ display:none }

.cop-tab{
  /* ⚠ ancho NATURAL, el de su texto: el subrayado mide lo que mide la
     pestaña. No `flex:1 1 0` — ver la nota del contenedor. */
  flex:0 0 auto;
  display:inline-flex;align-items:center;justify-content:center;
  background:transparent;border:none;border-radius:0;
  padding:var(--gap-lg, 1rem) var(--gap-lg, 1rem);
  position:relative;
  font-family:'Inter',sans-serif;font-weight:700;font-size:var(--fs-sm, .8rem);letter-spacing:.3px;
  color:var(--text-dim);
  white-space:nowrap;
  cursor:pointer;
  transition:color .2s,opacity .2s;
}

/* ⚠ EL MODIFICADOR DE ANCHO COMPLETO (Franco preguntó, 05/08/2026):
   «¿va a ser mucho lío que algunas páginas tengan las tabs ocupando todo
   el ancho y otras solo una parte?». **No: es esta clase y nada más.**
   `.cop-tabs.cop-tabs--full` reparte el riel en partes iguales; sin ella
   cada pestaña mide su texto, que es el comportamiento por defecto.
   Se elige POR PANTALLA agregando una palabra al contenedor, y ninguna
   otra barra se entera. Eso es exactamente para lo que sirve tener un
   componente en vez de veinte copias.

   ⚠⚠ LA REGLA CAMBIÓ, Y LA CAMBIÓ FRANCO (22/08/2026): *"los botones de
   las tabs deben SIEMPRE ocupar todo el ancho de la página… lo mismo en
   las otras tabs que haya a lo largo de la plataforma, es importante
   entender eso para dar mejor imagen visual"*.
   Queda derogado el "dos sí, tres o más no" del 05/08: **ahora el ancho
   completo es el DEFECTO de la plataforma** y la barra angosta es la
   excepción que hay que justificar. Cinco meses de barras a mitad de
   pantalla se leían como una web con la barra arriba a la izquierda; a
   ancho completo se leen como una app. Es la misma familia de decisión
   que el riel a 100vw: la app ocupa la pantalla.
   El "franja de color" del 05/08 venía de estirar TRES palabras cortas
   en un riel de escritorio; en móvil, que es donde se usa, la pestaña
   queda apenas más ancha que su palabra y el subrayado sigue leyéndose
   como subrayado (medido: "Información" 80px de texto en una celda de
   ~89px con cuatro pestañas a 390px).

   ⚠ EL `min-width:max-content` NO ES ADORNO. Con `flex:1 1 0` puro las
   celdas se reparten en partes IGUALES aunque no entren: `en-vivo` tiene
   cinco pestañas ("Alineaciones", "Estadísticas"…) y a 390px cada una
   recibiría 71px para una palabra de 90px — el texto se saldría de su
   celda y se pisaría con la de al lado (`white-space:nowrap` no ajusta,
   desborda). Con el piso en `max-content` la pestaña nunca baja de su
   palabra: si la suma no entra, el riel vuelve a deslizarse —que ya es
   su comportamiento (`overflow-x:auto`)— en vez de romperse. */
.cop-tabs--full .cop-tab{ flex:1 1 0; min-width:max-content }

/* el subrayado crece desde el centro hacia los dos lados */
.cop-tab::after{
  content:"";position:absolute;left:50%;right:50%;bottom:-1px;
  height:3px;border-radius:3px;
  background:var(--cop-acento);
  transition:left .25s,right .25s;
}

.cop-tab:hover:not(:disabled):not(.disabled){ color:#fff }
.cop-tab.active{ color:#fff }
.cop-tab.active::after{ left:0;right:0 }

/* ⚠ EL DESHABILITADO NO EXISTÍA Y HABÍA QUE INVENTARLO IGUAL: el
   `Resultado 🔒` del duelo ya lo necesitaba y se resolvía a mano en esa
   pantalla. Se usa el mismo tratamiento que el resto de la app
   (`.rl-btn:disabled`, `.mc-btn:disabled`): opacidad, sin hover y sin
   subrayado. Se apaga, no se esconde — el jugador tiene que ver que la
   sección existe y entender que todavía no está disponible. */
.cop-tab:disabled,
.cop-tab.disabled{
  opacity:.4;cursor:not-allowed;color:var(--text-dim);
}
.cop-tab:disabled::after,
.cop-tab.disabled::after{ display:none }


/* ══ CHIPS ═══════════════════════════════════════════════════════════
   Filtran una lista que ya está en pantalla.
   ⚠ Es EXACTAMENTE el "botón del sistema" que el proyecto definió el
   01/08 (var(--s2, #161b25) · borde 1.5px · Inter 600 · radio 14px). Unificar a
   este chip no es un diseño nuevo: es que la app obedezca su regla. */
/* ⚠⚠ LA TRAMPA DE `hidden`, OCTAVA APARICIÓN (08/09/2026). `[hidden]`
   del navegador es `display:none` con especificidad 0-1-0 — la misma que
   una clase—, así que en empate gana la que se declara después. Estas dos
   familias declaran `display`, y sin su propia regla el atributo NO las
   esconde: en Fútbol 11 las chips de división se quedaban dibujadas en la
   pestaña «Salón de la Fama», donde filtrar por división no dice nada.
   ⚠ VA EN EL COMPONENTE Y NO EN LA PÁGINA: la próxima pantalla que
   esconda unas chips se encontraría con el mismo defecto y lo arreglaría
   otra vez, con otro parche. La regla del sistema es que todo componente
   que declare `display` declare también su `[hidden]`. */
.cop-tabs[hidden],
.cop-chips[hidden]{ display:none }

.cop-chips{
  display:flex;gap:.7rem;
  overflow-x:auto;
  /* ⚠⚠ 100% ESTÁTICAS EN VERTICAL (Franco, 05/09/2026): *«todas las tabs
     de la página tienen que ser estáticas, ya que ahora si agarro una y
     la subo o bajo se puede mover internamente dentro de ese espacio que
     tienen»*.
     La causa es `overflow-x:auto`: al declarar overflow en UN eje, el
     navegador pone el otro en `auto` también, y en el teléfono eso
     habilita arrastrar la tira hacia arriba y abajo dentro de su caja —
     unos pocos píxeles, suficientes para que se vea flojo.
     Las tres líneas juntas lo cierran:
       · `overflow-y:hidden`      no hay eje vertical que arrastrar
       · `overscroll-behavior`    el rebote no se propaga ni entra
       · `touch-action:pan-x`     el dedo sólo mueve en horizontal, y de
                                  paso el gesto vertical pasa a la página
                                  en vez de quedarse trabado en la tira */
  /* ⚠⚠ ACÁ SE PROBÓ `overflow-y:clip` Y NO SIRVE — queda escrito para
     que nadie lo vuelva a intentar. La especificación dice que si un eje
     es `clip` y el otro NO lo es, el `clip` computa a `hidden`; como este
     riel necesita `overflow-x:auto` para deslizarse, el `clip` se
     degradaba en silencio y el CSS mentía sobre lo que hacía.
     ⚠ LO QUE SÍ RESUELVE EL PEDIDO DE FRANCO es `touch-action:pan-x`:
     le dice al navegador que en este elemento el dedo SÓLO mueve en
     horizontal. Un arrastre vertical no lo toca —se lo lleva la página,
     que es lo correcto— y ahí termina el «se puede mover internamente».
     Queda 1 px de sobra medido (el subrayado de la pestaña activa vive
     en `bottom:-1px` para tapar la línea del riel), pero es alcanzable
     sólo por JavaScript, no por el dedo. */
  overflow-y:hidden;
  overscroll-behavior-x:contain;
  overscroll-behavior-y:none;
  touch-action:pan-x;

  padding-bottom:var(--gap-sm, .5rem);
  scrollbar-width:none;-webkit-overflow-scrolling:touch;

  /* ⚠ A BORDE DE PANTALLA, pero devolviendo el margen como padding: la
     PRIMERA chip queda alineada con los títulos de la página —nada se
     corre de lugar— y la tira igual llega al borde físico, que es lo
     que le dice al jugador "seguí deslizando".
     El `scroll-padding` va junto con el padding: sin él, el imán del
     scroll pega la primera chip al borde y se come el margen que
     acabamos de devolver (bug encontrado midiendo, 01/08). */
  width:100vw;
  margin-left:calc(50% - 50vw);
  margin-right:calc(50% - 50vw);
  /* ⚠ POR LO MISMO QUE EL RIEL DE TABS (ver la nota de arriba): 100vw
     más 32 px de padding, en una página sin el reset de `box-sizing`,
     da una tira 32 px más ancha que la pantalla y la última chip queda
     tapada contra el borde. */
  box-sizing:border-box;
  padding-left:16px;padding-right:16px;
  scroll-padding-left:16px;scroll-padding-right:16px;
}
.cop-chips::-webkit-scrollbar{ display:none }

/* EL CUERPO DEL CHIP SE MUDO A `cop-boton.css` (Franco, 05/09/2026):
   *«las chips son chips, pero tienen que tener el mismo diseno de los
   botones, asi que los botones o chips de picks en lineup, en cuotas de
   los partidos etc tienen que tener el mismo diseno que los botones en
   tamano chico»*.
   O sea: el chip conserva su COMPORTAMIENTO —selecciona, tiene estado
   activo, no ejecuta— pero comparte el CUERPO del boton chico. Por eso
   el cuerpo vive con el boton y aca solo queda lo que es propio del
   chip: el icono y el estado activo. */
.cop-chip{ flex:0 0 auto }
.cop-chip .cop-chip-ico{ display:inline-flex;align-items:center }
.cop-chip .cop-chip-ico svg{ width:18px;height:18px }

/* ⚠ EL `:not(.active)` NO ES ADORNO — LO ENCONTRÓ EL CLICK DE PRUEBA (tanda 3).
   El canon (`.cat-chip:hover`) y su `.active` tenían la MISMA especificidad y
   ganaba el segundo por orden. Acá el hover llevaba `:not(:disabled)
   :not(.disabled)`, que lo sube a 0-4-0 y le gana a `.active` (0-2-0): con el
   puntero encima, la chip seleccionada PERDÍA su fondo celeste y volvía al
   gris. En móvil no se ve —no hay hover— así que era exactamente el tipo de
   cosa que viaja sin que nadie la note. */
/* ⚠⚠ SÓLO CON PUNTERO DE VERDAD (Franco, 27/08/2026): *«eliminá el efecto
   de hover de las chips que cuando se las toca para scrollear y no para
   seleccionar se pintan todas de gris, no quiero eso»*.
   En un teléfono no hay `hover`: el navegador lo simula al APOYAR el dedo,
   y como el riel de chips se desliza con el dedo, cada arrastre dejaba
   pintada de gris la chip por la que pasó. `hover:hover` + `pointer:fine`
   es la pregunta correcta —«¿hay un mouse?»— así que en escritorio el
   efecto sigue y en el teléfono no existe. */
/* el hover del chip lo pone ahora `cop-boton.css`, con la misma regla
   de puntero de verdad que el boton */

/* el seleccionado y el apagado tambien viven ahora en `cop-boton.css` */


/* ══ PANTALLAS CHICAS ════════════════════════════════════════════════
   Los mismos valores que ya tenía Champions Clash. */
@media(max-width:760px){
  .cop-tab { font-size:var(--fs-sm, .8rem);padding:var(--gap-md, .7rem) .7rem }
  .cop-chip .cop-chip-ico{ font-size:var(--fs-lg, 1.15rem) }
}

/* ⚠ EN ESCRITORIO HAY RAIL LATERAL. A pantalla completa la barra se
   metería debajo del rail, así que ahí ocupa su columna y no la
   ventana. El producto es una app: el ancho completo manda en móvil,
   que es donde se usa. */
@media(min-width:761px){
  .cop-tabs,
  .cop-chips{ width:auto;margin-left:0;margin-right:0 }
  .cop-tabs,
  .cop-chips{ padding-left:0;padding-right:0;scroll-padding-left:0;scroll-padding-right:0 }
}


/* ══ RITMO: DE LA BARRA AL CONTENIDO ══════════════════════════════════
   ⚠⚠ PEDIDO EXPLÍCITO DE FRANCO (12/08/2026): *"es muy importante marcar
   la misma distancia siempre a lo largo de toda la plataforma, no quiero
   decirlo más, empezá a usar estándares fijos"*.

   Medido el 12/08 sobre las 11 barras visibles, a 390x844:
     tienda 0 · misiones 0 · hitos 0 · en-vivo 0 · estadisticas 11 ·
     lineup 14 · ligas 16 · ranking 18 · torneo-juego 19 · duelo 19 ·
     login 35
   Once barras, OCHO distancias, cuatro PEGADAS. Ninguna la decidió nadie.

   A partir de acá es UNA sola y vive acá, no en cada página. Si mañana
   hay que moverla, se mueve un número y bajan las doce.

   ⚠ El fallback de 1rem no es decorativo: hoy solo 4 de las 12 páginas
     enlazan cop-ui-base.css, que es donde vive --gap-tabs. Sin fallback,
     en las otras 8 la variable no resuelve y el margen se cae a 0 — que
     es exactamente el bug que veníamos a arreglar.

   ⚠ La barra NO es sticky en ninguna de las 12 (verificado contra el DOM
     renderizado, no deducido del marcado). Por eso el margen es seguro:
     con una barra pegajosa el contenido pasaría por debajo del hueco. */
.cop-tabs{ margin-bottom:var(--gap-tabs, 1rem) }