@zevra/ui 0.36.0 → 0.38.0

package/src/feedback.css

@@ -709,12 +709,37 @@
     min-width: 0;
   }
 
-  /* Même garde-fou que le menu et le popover : plafonnée à l'écran, la
-   * bulle ne pousse jamais la page en défilement horizontal. Le centrage
-   * sur une cible collée au bord peut encore la décaler : limite connue,
-   * une variante d'ancrage latéral s'arbitrera si le cas se présente. */
+  /* ⚠️ LA BULLE CESSE DE FLOTTER : elle se pose en bas de l'écran, pleine
+   * largeur. Le centrage sur une cible proche du bord droit la poussait
+   * hors de l'écran. Mesuré sur le tableau de bord de mcp-factory à 375px :
+   * document large de 416, défilement horizontal sur toute la page. Ce
+   * n'était pas la largeur qui débordait mais la POSITION, et le plafond en
+   * `100vw` n'y pouvait donc rien.
+   *
+   * Ancrée à l'écran, la bulle ne peut plus déborder quelle que soit la
+   * place de sa cible, et c'est le seul endroit où elle reste lisible sur
+   * 320px sans se replier en cinq lignes au-dessus d'un bouton.
+   *
+   * Écarté : la variante d'ancrage latéral que le commentaire précédent
+   * envisageait. Elle aurait obligé chaque app à choisir le bon côté pour
+   * chaque bulle (quarante et une sur ce seul tableau de bord) et à le
+   * refaire à chaque déplacement d'un bouton.
+   *
+   * `inset` remet `top` et `left` à `auto` : sans quoi le `left: 50%` et le
+   * `bottom: calc(100% + 6px)` de la règle de base subsisteraient. */
   .zv-tooltip {
-    max-width: calc(100vw - 40px);
+    position: fixed;
+    inset: auto 16px 16px;
+    transform: none;
+    translate: none;
+    width: auto;
+    max-width: none;
+  }
+
+  /* La variante « sous la cible » n'a plus de sens une fois la bulle posée
+   * en bas : elle rouvrirait le `top` que l'ancrage vient de neutraliser. */
+  .zv-tooltip--bas {
+    top: auto;
   }
 
   /* ⚠️ NON RELEVÉ : aucune variante `lg:` sur le padding de l'écran vide.

package/src/layout.css

@@ -825,9 +825,24 @@
   }
 
   /* Les liens de navigation desktop n'ont pas d'équivalent mobile au
-   * relevé : Mobile.html les remplace par un menu burger. Ils ne sont pas
-   * masqués d'office, cela casserait les pages sans burger, mais
-   * .zv-only-desktop est là pour le faire en une classe. */
+   * relevé : Mobile.html les remplace par un menu burger. Ils disparaissent
+   * donc EXACTEMENT là où un burger les remplace, ni avant ni ailleurs.
+   *
+   * ⚠️ LE `:has()` PORTE TOUT LE RAISONNEMENT. Masquer d'office casserait
+   * une barre sans burger : ses liens s'évanouiraient sans rien pour les
+   * remplacer, et c'est la raison pour laquelle la règle n'existait pas.
+   * Conditionner au burger lève l'objection sans rien sacrifier, et rend
+   * enfin vraie la phrase écrite plus haut : « le burger n'existe que là où
+   * les liens disparaissent ». C'était l'intention ; ce n'était pas le code.
+   *
+   * Ce que ça remplace : `zv-only-desktop` posé à la main sur `NavLinks`.
+   * QUATRE consommateurs sur cinq collaient cette classe, le cinquième
+   * passait par `zv-nav--riche` ; memoire avait même écrit le commentaire
+   * qui l'explique. Une rustine que tout le monde recopie est un défaut du
+   * paquet, pas un usage. */
+  .zv-nav:has(.zv-nav__burger) .zv-nav__links {
+    display: none;
+  }
 
   .zv-steps__rail,
   .zv-steps__progress {