/*
 * Feuille de PREMIER PAINT. Elle est chargee par <link> dans index.html, donc
 * avant le moindre octet de JavaScript : c'est la seule CSS du projet qui
 * s'applique pendant que l'application se telecharge et se monte.
 *
 * ---------------------------------------------------------------------------
 * POURQUOI DES COULEURS ECRITES EN DUR ICI, ALORS QUE C'EST UN DEFAUT AILLEURS
 * ---------------------------------------------------------------------------
 * Elles sont recopiees de common/theme/palette.js -- `LIGHT.canvas` (#f2f4f8)
 * et `DARK.canvas` (#0B1220). C'est une DUPLICATION ASSUMEE et non un oubli :
 * la palette est un module JavaScript, et il n'y a pas de JavaScript au moment
 * ou ces regles s'appliquent. Si ces deux valeurs changent dans palette.js,
 * elles doivent changer ici aussi -- d'ou ce paragraphe, qui est le seul lien
 * entre les deux fichiers.
 *
 * LE LIEN A DEJA SERVI DEUX FOIS, ce qui est l'argument le plus solide pour le
 * garder. D'abord `LIGHT.canvas` est passee du gris-bleu froid #F1F5F9 au gris
 * chaud #F3F2F2 avec l'adoption de l'echelle v3. Puis la table des 50 paires de
 * MAJ-2 l'a ramenee en gris-bleu, a #f2f4f8. Les deux fois, c'est ce paragraphe
 * qui a fait trouver cette ligne -- sans lui le premier paint serait reste sur
 * l'ancienne teinte pendant que l'application se monte sur la nouvelle, un
 * decalage visible exactement une fois par chargement, donc tres facile a ne
 * jamais diagnostiquer.
 *
 * ---------------------------------------------------------------------------
 * LE DEFAUT CORRIGE : UN FLASH DE THEME INVERSE
 * ---------------------------------------------------------------------------
 * L'amont ecrivait `body { background: black }` sous `prefers-color-scheme:
 * dark`. Deux problemes, dont le second est le vrai.
 *
 * D'abord `black` n'est pas une couleur de cette interface : le fond de coquille
 * du mode nuit est #0B1220. Le noir pur produisait donc une marche visible la ou
 * le corps depasse -- au rebond de defilement sous macOS et iOS, notamment.
 *
 * Surtout, LA PREFERENCE DE L'OS N'EST PAS LE THEME DE L'APPLICATION. Un client
 * qui force le mode clair pour toute sa flotte, sur un poste dont l'OS est en
 * mode sombre, voyait un ecran NOIR pendant le chargement, puis une interface
 * claire. Et symetriquement -- cas plus desagreable -- un reglage en mode sombre
 * sur un OS clair donnait un plein ecran BLANC avant de basculer.
 *
 * ---------------------------------------------------------------------------
 * CE QUI A CHANGE AVEC LE MODE SOMBRE PAR DEFAUT
 * ---------------------------------------------------------------------------
 * Le declencheur n'est plus `prefers-color-scheme` mais l'attribut
 * `data-theme` de <html>, pose par le petit script synchrone d'index.html a
 * partir du choix memorise. Le flash decrit ci-dessus est donc SUPPRIME et non
 * plus seulement adouci : la valeur est lue dans `localStorage`, qui est
 * disponible avant le premier paint, alors que l'ancien reglage serveur
 * n'arrivait qu'avec la reponse de l'API.
 *
 * LE SOMBRE EST LA REGLE DE BASE, LE CLAIR L'EXCEPTION SOUS SELECTEUR. Ce sens
 * est voulu : si le script ne s'execute pas -- JavaScript coupe, ou une erreur
 * avant la pose de l'attribut --, aucun selecteur ne s'applique et il reste la
 * base, c'est-a-dire le mode par defaut de l'application
 * (`themeModes.DEFAULT_MODE`). Mettre le clair en base aurait fait de la panne
 * un ecran blanc, soit l'inverse du defaut demande.
 *
 * `var(--t-bg, ...)` ET un litteral : les deux sont necessaires et ne servent
 * pas au meme moment. La `var()` est posee par `applyThemeMode` et prend la
 * main des que le module JavaScript est charge -- c'est elle qui fait suivre le
 * fond de page lors d'une bascule en cours de session, sans toucher a cette
 * feuille. Le litteral est le repli pour l'instant qui precede, le seul endroit
 * ou les deux couleurs de `MODES` sont encore recopiees a la main.
 */

html,
body {
  height: 100%;
}

body {
  margin: 0;
  padding: 0;
  background: var(--t-bg, #0b1220); /* MODES.dark.bg = DARK.canvas */
}

html[data-theme='light'] body {
  background: var(--t-bg, #f2f4f8); /* MODES.light.bg = LIGHT.canvas */
}

.root {
  display: flex;
  flex-direction: column;
  height: 100%;
}

@media print {
  * {
    height: auto !important;
    overflow: visible !important;
  }
}

/*
 * HALO PULSANT DU VEHICULE SELECTIONNE EN MOUVEMENT. Demande par l'etape 3 du
 * paquet « ecran flotte », qui la place dans `src/index.css`.
 *
 * ELLE EST ICI ET NON DANS `src/index.css`, ET C'EST UNE ADAPTATION DE CHEMIN
 * (autorisation 4 du LISEZ-MOI) : ce fork n'a pas de `src/index.css`. Sa seule
 * feuille globale est celle-ci, chargee par <link> dans index.html. Creer un
 * second fichier CSS pour trois lignes ajouterait une feuille a importer depuis
 * src/index.jsx, donc un point d'entree de plus a connaitre.
 *
 * POURQUOI L'ANIMATION NE PEUT PAS VIVRE DANS LE COMPOSANT : le marqueur est
 * construit par MapVehicleMarkers en HTML brut (`element.innerHTML`) et confie a
 * `maplibregl.Marker`. Il n'est donc PAS rendu par React : ni `sx`, ni emotion,
 * ni aucune classe generee par le theme ne l'atteint. Une `@keyframes` doit
 * exister dans une feuille de style globale pour qu'un `animation: vpulse ...`
 * ecrit en style inline trouve son nom. C'est la raison de cette exception, et
 * elle vaut aussi pour `@keyframes ll` du chargeur dans index.html.
 */
@keyframes vpulse {
  from {
    transform: scale(1);
    opacity: 0.45;
  }
  to {
    transform: scale(2.2);
    opacity: 0;
  }
}