/**
 * Onify Theme - Safe areas : les 4 tokens des zones systeme du device
 * ============================================================================
 * LE CONTEXTE
 * L'app native (Capacitor, `com.onify.app`) charge app.onify.fr dans une
 * WKWebView PLEIN ECRAN, et `partials/head-page-meta.php` declare
 * `viewport-fit=cover`. C'est le contrat WebKit : la webview cesse d'inserer le
 * contenu elle-meme, et c'est la PAGE qui reserve les zones systeme (status bar
 * / Dynamic Island en haut, home indicator en bas, encoche sur les cotes en
 * paysage) en lisant `env(safe-area-inset-*)`.
 *
 * CE FICHIER NE FAIT QUE NOMMER CES 4 VALEURS. Il n'applique AUCUN padding.
 *
 * OU LA RESERVE EST REELLEMENT POSEE (3 proprietaires, un par famille de pages)
 *   1. `theme/components/module-identity.css` - pages "module shell" (factures,
 *      devis, achats, glass, stock, modules, fournisseurs...). `.module-identity`
 *      est le premier bloc a l'ecran, donc c'est lui qui porte l'inset.
 *      Reconduit par les 3 surcharges qui reecrivent son `padding` en shorthand :
 *      `crm/spa/responsive.css` (x2) et `ao/ao-module.css`. Toute nouvelle
 *      surcharge du shorthand DOIT reconduire `var(--safe-top)`.
 *   2. `theme/layout/page-canvas.css` - pages a wrap classique et `/accueil`
 *      (`body[data-page="accueil"] .wrap`), qui n'a pas de `.module-identity`
 *      mais son propre `.head`. C'etait la famille oubliee.
 *   3. `theme/layout/page-canvas.css` aussi, pour `body > .main-content` : les
 *      3 vues (crm/leads, crm/settings, dashboard client) qui ont leur propre
 *      coque et font leur mise en page en <style> inline.
 * Ces proprietaires se REPARTISSENT les pages, ils ne se superposent jamais :
 * verifie page par page le 14/08/2026 (le seul cas mixte, `pages/modules.php`,
 * a son `.pc-content` neutralise par module-shell.css).
 *
 * Resultat mesure a <=639.98px dans l'app (inset haut = 59px sur 15 Pro Max) :
 * 75px de haut sur les pages module / CRM / AO, 79px sur /accueil et les wraps
 * classiques. Ecart de 4px, invisible - c'etait l'objectif.
 *
 * POURQUOI PAS UNE RESERVE GLOBALE SUR LA COQUE (.pc-container)
 * C'est ce qui avait ete tente le 14/08 et il faut ne pas y revenir : la reserve
 * de coque s'AJOUTE a celle que chaque en-tete pose deja -> double espace. La
 * page factures est passee de 75px a 134px de vide en haut, pendant que
 * `/accueil` (sans `.module-identity`) restait a 79px. Le decalage entre pages
 * etait pire que le bug d'origine.
 *
 * REGLE : ne pas ajouter d'inset ailleurs sans verifier lequel des 2
 * proprietaires ci-dessus couvre deja la page. Les elements `position: fixed`
 * sont l'exception legitime : ils sortent du flux, donc la reserve d'en-tete ne
 * les atteint pas et ils portent la leur (mobile-safe-area.css pour Bootstrap,
 * menu-list.css pour la barre mobile, modales maison, editeur, mode Terrain).
 *
 * HORS APP NATIVE : `env()` vaut 0px, tout ce qui utilise ces tokens est un
 * no-op exact sur desktop et sur navigateur mobile en portrait.
 */

:root {
  --safe-top:    env(safe-area-inset-top, 0px);
  --safe-right:  env(safe-area-inset-right, 0px);
  --safe-bottom: env(safe-area-inset-bottom, 0px);
  --safe-left:   env(safe-area-inset-left, 0px);

  /* CINQUIEME VALEUR : ce que prend la barre de navigation mobile.
     ------------------------------------------------------------------------
     En bas il y a DEUX obstacles, pas un. La barre de gestes du systeme, deja
     nommee ci-dessus, et `.mobile-bottom-bar` (menu-list.css), qui est notre
     propre navigation : `position: fixed; bottom: 0; z-index: 1000`, haute de
     `64px + env(safe-area-inset-bottom)`, affichee sous 1024 px.

     Un element flottant pose a moins de 98 px du bas est donc soit invisible
     derriere elle (z-index < 1000), soit dessine PAR-DESSUS ses boutons
     (z-index > 1000). Releve du 07/09/2026 : 53 elements dans ce cas, dont une
     vingtaine de systemes de toast. Sur ces ecrans, l'utilisateur n'a jamais vu
     ni une confirmation ni une erreur.

     Ce token vaut 0 partout ou la barre n'est pas rendue - au-dessus de 1024 px,
     et sur les pages qui ne l'incluent pas, comme l'editeur. Le `:has()` est ce
     qui rend cette distinction possible sans lister les pages une par une ; s'il
     n'etait pas supporte, le token resterait a 0 et le comportement serait
     exactement celui d'aujourd'hui. Aucune regression possible.

     Ce token repond a une seule question : COMBIEN DE PIXELS SONT PRIS EN BAS ?
     Sans la barre, c'est la zone de gestes seule ; avec elle, c'est la barre,
     qui contient deja cette zone. Un element flottant n'a donc jamais a savoir
     sur quelle page il se trouve.

       0 px   sur ordinateur
      34 px   sur telephone, page sans barre de navigation (l'editeur)
      98 px   sur telephone, page avec barre (le reste de l'app)

     Usage : `bottom: calc(var(--safe-dock) + 24px)` au lieu de `bottom: 24px`.
     Ne PAS y ajouter `--safe-bottom` : il est deja compris dans les trois cas. */
  --safe-dock: env(safe-area-inset-bottom, 0px);
}

@media (max-width: 1024px) {
  body:has(.mobile-bottom-bar) {
    --safe-dock: calc(64px + env(safe-area-inset-bottom, 0px));
  }
}