/* ══════════════════════════════════════════════════════════════════════════
   ios.css · PIEZA CANÓNICA DE LA SUITE — arreglos de iPhone/iPad
   Origen: ilya-haccp/public/ios.css (funciona en producción desde el 29-jul).
   Elevado a compartido el 2026-08-15: 15 de 15 módulos fallaban los mismos
   dos controles (G7 táctil, G8 zoom al enfocar).

   ── QUÉ RESUELVE ────────────────────────────────────────────────────────
   1) EL ZOOM AL TOCAR UN CAMPO. Safari en iOS amplía solo cuando enfocas un
      input con letra < 16px, y deja la página descolocada. El arreglo NO es
      bloquear el zoom con `maximum-scale=1` —eso se lo quita a quien lo
      necesita para leer— sino subir la letra a 16px en pantallas pequeñas.
      En escritorio no se toca nada.

   2) ÁREA DE TOQUE. Un campo de 16px con poco alto sigue siendo difícil de
      acertar con el dedo. 44px es el mínimo de Apple HIG y de WCAG 2.5.5.

   ── CÓMO SE USA ─────────────────────────────────────────────────────────
   Copiar a `public/ios.css` del módulo y enlazarlo DESPUÉS de la hoja
   principal (para que gane por orden, no por `!important` gratuito):
       <link rel="stylesheet" href="ios.css">
   En TODAS las páginas del módulo, no solo en el index. Es el fallo que ya
   nos costó tres veces: el arreglo llega al index y no a las secundarias.

   ⚠️ Y comprobar que la página lleva `viewport-fit=cover` en su meta viewport,
   o las reglas de safe-area que ya tenga escritas no harán nada.
   ══════════════════════════════════════════════════════════════════════════ */

/* ───────────────────────── PARTE 1 · SEGURA, PEGAR TAL CUAL ─────────────────
   Probada en producción en HACCP. Toca el tamaño de letra y el alto mínimo de
   los campos, y SOLO EN PANTALLA por debajo de 860px.

   🔴 8-oct-2026 · AÑADIDO `screen` — ANTES ESTA REGLA SE APLICABA AL IMPRIMIR.
   Lo levantó 🍽️ Zest con un PDF de Lukas inservible, y el comentario que había
   aquí —el que prometía que no tocaba la maquetación— ERA FALSO desde el 20-sep.
   (Se DESCRIBE y no se cita: citarla deja la frase viva para cualquier `grep`.)

   QUÉ PASABA: `@media (max-width: 860px)` sin tipo de medio vale para `all`, o
   sea TAMBIÉN para `print`. Y el navegador evalúa ese ancho contra la hoja
   VERTICAL (~733px) antes de aplicar un `size: A4 landscape`, así que se cumplía
   incluso imprimiendo apaisado desde un Mac. Cualquier página con campos dentro
   de una tabla impresa los sacaba a 16px y con 44px de alto mínimo.

   📏 REPRODUCIDO POR LA MADRE CON CONTROL NEGATIVO (tabla de 40 filas a 9px,
      A4 apaisada, Chrome headless → PDF, midiendo los operadores `Tf`):
        con este fichero SIN arreglar   16,00 pt x280  +  9,00 pt x21   3 páginas
        sin ios.css        (control)     9,00 pt x294                   2 páginas
        con `screen`       (arreglo)     9,00 pt x294                   2 páginas
      La huella es la ASIMETRÍA: los campos a 16 y las cabeceras a 9 en el mismo
      documento. Si fuera una escala serían proporcionales. (Zest la midió igual
      en el PDF real de Lukas: `16,00 pt` 3.381 veces contra `9,00 pt` 353.)

   🪤 Y POR QUÉ UN ARREGLO LOCAL NO BASTA — medido, no razonado:
      este bloque lleva TAMBIÉN `min-height: 44px`. Una regla local que solo
      devuelva la LETRA a su tamaño deja el alto mínimo puesto:
        arreglo local solo con la letra      9,00 pt ✅   pero 3 páginas 🔴
        arreglo local + `min-height: 0`      9,00 pt ✅        2 páginas ✅
      O sea: el texto sale bien, **el registro sigue ocupando un 50% más de
      hojas, y parece arreglado**. Si por lo que sea no puedes actualizar este
      fichero, tu regla de `@media print` tiene que tocar LAS DOS cosas.

   🪤 ESPECIFICIDAD, si arreglas en local: `ios.css` se enlaza DESPUÉS del
      `<style>` de la página y lleva `!important`, así que un
      `input{font-size:9px!important}` a secas PIERDE POR ORDEN — y el que lo
      escriba verá su regla en el fichero y la dará por buena. Hace falta el ID
      del contenedor para ganar. (Lo midió 🍽️ Zest enfrentando las dos.)
      ⚠️ Y la prueba hay que hacerla EN MODO IMPRESIÓN: fuera de él la regla
      nueva ni compite, y sale un falso verde. */

@media screen and (max-width: 860px) {
  input:not([type="checkbox"]):not([type="radio"]):not([type="range"]):not([type="file"]),
  select,
  textarea {
    font-size: 16px !important;
    /* iOS ignora el line-height heredado en los campos y los deja bajos */
    line-height: 1.35;
  }

  input:not([type="checkbox"]):not([type="radio"]):not([type="range"]):not([type="file"]),
  select {
    min-height: 44px;
  }
}

/* ───────────────────────── PARTE 2 · BOTONES — LEER ANTES ──────────────────
   🔴 NO se pega a ciegas. Una regla general de `min-height:44px` sobre TODOS
   los botones descuadra las barras densas (toolbars de fila, chips, iconos
   dentro de una celda de tabla). En la suite hay varias.

   Por eso aquí van DOS opciones. Elige por pantalla, no por módulo:

   OPCIÓN A · el botón puede crecer (lo normal en formularios y diálogos):
   añade la clase `.tap` al botón y listo.

   OPCIÓN B · el botón NO puede crecer sin romper la fila (iconos de acción
   en tablas, chips): usa `.tap-area`, que agranda la ZONA TOCABLE sin tocar
   el tamaño visible. Requiere que el botón admita `position:relative`.

   En ambos casos: solo se aplica en pantallas táctiles (`pointer: coarse`),
   así que el ratón en escritorio no se ve afectado. */

/* 🔴 8-oct-2026 (2ª pasada) · AÑADIDO `screen` TAMBIÉN AQUÍ.
   Lo levantó 🧾 Facturación como consumidor: el arreglo de la mañana puso el tipo de medio en
   UN bloque y este se quedó sin él — y lleva `min-height`, que es justo la mitad que se olvida.

   📏 MEDIDO antes de tocarlo, con control positivo (60 botones `.tap`, A4, a PDF):
     sin ios.css ..................................... 1 página
     con el bloque tal cual (`pointer: coarse`) ...... 1 página   ← no muerde
     🔬 CONTROL: la MISMA regla con `(min-width:1px)`
        —siempre cierta y sin tipo de medio— ......... 3 páginas  ← el banco SÍ distingue
   👉 Así que un bloque sin tipo de medio **sí** se aplica al imprimir; éste no mordía porque
      `pointer: coarse` es FALSO al imprimir. El defecto era ESTRUCTURAL y LATENTE, no vivo.
   ⚠️ Límite declarado: medido en Chromium headless. `pointer` en medio `print` depende del motor,
      así que en WebKit no está medido — y por eso se pone `screen` en vez de confiar en la condición.
*/
@media screen and (pointer: coarse) {
  /* OPCIÓN A — el control crece hasta 44×44 */
  .tap {
    min-height: 44px;
    min-width: 44px;
  }

  /* 🪤 OJO CON EL ANCHO FIJO — lo midió 💒 Weddings el 6-sep-2026.
     Probó `width:44px` en una fila de botones pequeños y **salió PEOR**: cada zona
     tocable **pisaba la del vecino**, y el dedo caía en el botón de al lado. Medido:
     32×60 efectivos, **más estrecho que los 34 px de partida**. Con `calc(100% + 5px)`
     cada botón ocupa su propio hueco sin robarle al siguiente: **40×68**.
     👉 **Un 44 a ciegas puede empeorar la fila que pretende arreglar.** En filas densas,
     amplía RELATIVO al botón (`calc(100% + hueco)`), no a un absoluto.
     Y compruébalo con `elementFromPoint`, que dice a QUIÉN llega el dedo — no con el
     tamaño de la caja, que no lo dice. */

  /* OPCIÓN B — el control se ve igual, pero se toca en 44×44 */
  .tap-area {
    position: relative;
  }
  .tap-area::after {
    content: "";
    position: absolute;
    top: 50%;
    left: 50%;
    width: 44px;
    height: 44px;
    transform: translate(-50%, -50%);
    /* no pinta nada: solo amplía el objetivo del dedo */
  }

  /* Dos controles contiguos de 44px pegados se pulsan mal. Un respiro. */
  .tap + .tap,
  .tap-area + .tap-area {
    margin-left: 6px;
  }
}

/* ── CÓMO SE COMPRUEBA QUE FUNCIONÓ ─────────────────────────────────────────
   🪤 LA VERSIÓN ANTERIOR DE ESTE FRAGMENTO MENTÍA, y lo cazó 🗂️ Panel el 6-sep:
   medía `getBoundingClientRect()` del ELEMENTO, así que marcaba como fallo
   justo lo que arregla `.tap-area` —cuyo objetivo vive en un `::after` y NO
   entra en esa caja—. O sea: **cuanto mejor aplicabas la OPCIÓN B, más fallos
   te inventaba**. Un instrumento que castiga el arreglo correcto.

   ⚠️ Y ANTES DE MEDIR NADA, comprueba que tu visor es el que crees:

     [innerWidth, document.documentElement.clientWidth]   // y los DOS > 0

   Si no coinciden, el emulador está descuadrado y **cualquier ancho que midas
   es falso** (Panel vio 493 contra 402). Se mide contra `clientWidth`.

   🔴 ESTA COMPROBACIÓN FALLABA EN LAS DOS DIRECCIONES — corregido el 18-sep-2026,
      lo levantó 🗓️ Planning usándola:

        innerWidth 0   · clientWidth 0     →  decía SANO   🔴 y TODO lo medido es falso
        innerWidth 394 · clientWidth 375   →  decía ROTO   🔴 y son los 19px de la BARRA

      O sea: **pasaba en verde justo cuando nada vale, y en rojo en el caso más
      común.** El `> 0` cierra la primera mitad. La segunda no se cierra con una
      constante mejor:

   🔑 NO PREGUNTES POR EL ANCHO. PREGUNTA SI SE DESPLAZA (de 🗓️ Planning):

        const x = scrollX; scrollTo(50, scrollY);
        const desplaza = scrollX !== x; scrollTo(x, scrollY);

      **Un ancho no dice si desborda; que se pueda desplazar, sí.** Y con su control
      positivo: un `div` de 3000px SÍ tiene que hacerla desplazable — si no, es el
      detector el que no funciona. Planning midió sus cinco pantallas así: ninguna
      se desplaza, después de que los anchos dieran seis falsos rojos.

   Y entonces, a 375px:

     [...document.querySelectorAll('button,.chipbtn,input,select,a[role=button]')]
       .filter(e => { const r = e.getBoundingClientRect(); return r.width > 0 && r.height > 0; })
       .map(e => {
         const r = e.getBoundingClientRect();
         return { q: e.id || e.className || e.tagName,
                  w: Math.round(r.width), h: Math.round(r.height),
                  yaArreglado: e.classList.contains('tap') || e.classList.contains('tap-area') };
       })
       .filter(x => (x.h < 44 || x.w < 44) && !x.yaArreglado)

   📏 **Di SIEMPRE el total, no solo los que fallan.** «0 fallos» de 3 controles
   cuando la pantalla tiene 43 no es un aprobado: es que no habías entrado.

   🔴 Y estas DOS cosas no las ve ningún guion — se prueban con el dedo:
   · un `input[type=range]` se arrastra, no se toca: 44px no le aplica.
   · un checkbox de 13px NO es un fallo si su `<label>` mide 44 de alto y al
     pulsarla cambia. **Compruébalo pulsando**, no leyendo el CSS.

   Y enfocar un campo en un iPhone real: si la página no da un salto, está bien.
   ────────────────────────────────────────────────────────────────────────── */