/* =====================================================================
   MATH UNIVERSE — WIDGET « DEMANDE D'APPEL »  (إتصل بي)
   =====================================================================

   Chaque valeur reproduit le style RELEVÉ du formulaire d'origine — dans
   le widget 7c447a70 et dans le kit Elementor 1690, pas à l'œil :

     champs  : fond #F8F8F8, texte #414141, rayon 25px, padding 12px 20px,
               aucune bordure, Tajawal 15px / 1.7 ;
     bouton  : fond #FF9616, texte #FFFFFF, rayon 25px, padding 16px 28px,
               Tajawal 19px (15 mobile) 700 / 1.2,
               ombre 0 0 10px rgba(0,0,0,.5), écart icône 18px ;
     messages: succès #63F868, erreur #FD7777, Tajawal 600 — couleurs
               claires, pensées pour la bande violette qui porte le
               formulaire.

   Le survol du bouton reprend le vocabulaire des boutons Messenger /
   WhatsApp (reflet balayé + levée) mais GARDE l'orange : demande
   explicite. L'ancien survol violet du kit est abandonné.

   PIÈGE n°6 DU SITE : le kit Elementor repeint tous les <button> via
   `.elementor-kit-1690 button` à (0,1,1). Tous les sélecteurs du bouton
   sont à (0,2,0) minimum — ils gagnent sans `!important`.
   ===================================================================== */

.mu-appel {
    --mu-appel-orange: #FF9616;
    --mu-appel-champ-fond: #F8F8F8;
    --mu-appel-champ-texte: #414141;
    --mu-appel-ok: #63F868;
    --mu-appel-erreur: #FD7777;
    --mu-appel-police: 'Tajawal', 'Poppins', system-ui, -apple-system, 'Segoe UI', sans-serif;
    --mu-appel-elan: cubic-bezier(.22, 1, .36, 1);

    box-sizing: border-box;
    width: 100%;

    /* ------------------------------------------------------------------
       MARGES LATÉRALES INTERNES.

       Le formulaire est posé dans une section Elementor qui, dans le pied
       de page, ne fournit aucun rembourrage horizontal : les champs
       touchaient les bords de la bande violette. Le rembourrage est porté
       ICI plutôt que dans les réglages Elementor de la section, pour deux
       raisons : il suit le widget partout où on le pose, et il ne peut pas
       être perdu en dupliquant la section ou en réimportant un modèle.

       `padding` et non `margin` : avec `width: 100%` et `border-box`, le
       rembourrage se prend À L'INTÉRIEUR de la largeur. Une marge, elle,
       s'ajouterait à 100 % et ferait déborder le formulaire de sa colonne.

       clamp() plutôt qu'une valeur fixe : 18px sur téléphone, où chaque
       pixel de largeur compte, jusqu'à 40px sur grand écran.
       ------------------------------------------------------------------ */
    padding-inline: clamp(18px, 3vw, 40px);

    /* Le formulaire occupe toute la largeur qu'on lui donne et se centre
       si on lui en donne moins — le jour où il est posé dans une colonne
       plus large que lui, il ne dérivera pas d'un côté. */
    max-width: 100%;
    margin-inline: auto;
}

/* ---------------------------------------------------------------------
   MARGE GAUCHE ET MARGE DROITE STRICTEMENT ÉGALES.

   Constaté : la marge de gauche était visiblement plus large que celle
   de droite. La cause n'était PAS dans le formulaire — l'inspecteur
   confirme `padding: 0px 40px`, donc symétrique — mais dans un ANCÊTRE.

   Deux ancêtres peuvent décaler le widget, et un seul est à notre portée
   depuis le CSS :

     1. `.elementor-widget-container`, la boîte qu'Elementor pose autour
        de CHAQUE widget. On la neutralise ici : c'est notre widget, ses
        gouttières doivent venir du formulaire lui-même et de nulle part
        ailleurs. Ce sélecteur ne vise que `mu_appel`, aucun autre widget
        de la page n'est touché.

     2. La COLONNE ou la SECTION qui contient le widget, si elle porte une
        marge asymétrique. Celle-là, le CSS ne peut pas l'atteindre — une
        règle ne remonte jamais vers un ancêtre. Elle se corrige dans
        Elementor : sélectionner la colonne, onglet Avancé, section Marge,
        et remettre les valeurs gauche et droite à égalité.

   La reconnaissance initiale avait justement relevé, sur la colonne du
   formulaire d'origine, un `margin left: 50px` sur ordinateur et 0 sur
   mobile — exactement le genre de réglage qui produit ce décalage.
   --------------------------------------------------------------------- */
.elementor-widget-mu_appel > .elementor-widget-container {
    padding-inline: 0;
    margin-inline: 0;
}

.mu-appel *,
.mu-appel *::before,
.mu-appel *::after { box-sizing: border-box; }

/* ---------------------------------------------------------------------
   Champ leurre : hors cadre par la POSITION, jamais display:none — les
   robots récents lisent la feuille de style et ignorent les champs
   masqués ainsi ; un champ hors cadre reste « présent » pour eux.
   --------------------------------------------------------------------- */
.mu-appel .mu-appel__leurre {
    /* left PHYSIQUE et non inset-inline-start : le formulaire est en
       dir="rtl", où « inline-start » vaut DROITE — le leurre était donc
       poussé hors de l'écran par la droite, créant un défilement
       horizontal sur toute la page. */
    position: absolute;
    left: -9999px;
    width: 1px;
    height: 1px;
    overflow: hidden;
}

/* ---------------------------------------------------------------------
   La grille : nom, téléphone, bouton sur UNE ligne. Le formulaire est en
   dir="rtl", le flex suit la direction : le nom part de la droite sans
   toucher au DOM ni à l'ordre de tabulation.
   --------------------------------------------------------------------- */
.mu-appel .mu-appel__grille {
    display: flex;
    flex-wrap: wrap;
    gap: 10px;
    align-items: stretch;
}

/* ---------------------------------------------------------------------
   LES DEUX CHAMPS DOIVENT S'ANCRER À DROITE — DE FAÇON EXPLICITE.

   Le premier correctif ne touchait que le champ téléphone, en partant du
   principe que le champ nom s'alignait déjà correctement tout seul via
   `dir="auto"`. C'était vrai dans une page de test isolée, mais faux dans
   l'éditeur Elementor réel : `dir="auto"` ne fait qu'INFLUENCER la valeur
   PAR DÉFAUT de `text-align` côté navigateur — une valeur de la plus
   basse priorité possible, que n'importe quelle règle du site peut battre
   sans même viser ce champ. Sans déclaration explicite ici, le champ nom
   restait à la merci du premier concurrent venu.

   La réparation robuste : `text-align: right` explicite, pour les DEUX
   champs, sans dépendre d'une valeur implicite.
   --------------------------------------------------------------------- */
.mu-appel .mu-appel__champ {
    flex: 1 1 180px;
    min-width: 0;
    background: var(--mu-appel-champ-fond);
    color: var(--mu-appel-champ-texte);
    border: 0;
    border-radius: 25px;
    padding: 12px 20px;
    font-family: var(--mu-appel-police);
    font-size: 15px;
    line-height: 1.7;
    transition: box-shadow .25s ease;
}

/* ---------------------------------------------------------------------
   L'ALIGNEMENT EST ISOLÉ DANS SA PROPRE RÈGLE, À SPÉCIFICITÉ RENFORCÉE.

   Un `text-align: right` posé sur la règle ci-dessus, à (0,2,0), a été
   constaté BATTU dans l'éditeur Elementor réel — alors qu'il gagnait dans
   une page de test isolée. La cause, déjà rencontrée sur CE MÊME site
   lors du travail sur les e-mails WooCommerce : le kit Elementor génère,
   pour tout champ de formulaire, un sélecteur du type
   `.elementor-kit-{ID} input:not([type="button"]):not([type="submit"])`
   — spécificité (0,3,1), qui bat n'importe quelle règle à (0,2,0), même
   sans viser `text-align` en particulier.

   On s'appuie donc sur `#mu-appel`, l'identifiant RÉEL du formulaire
   (déjà présent dans le balisage, pas ajouté pour l'occasion) : un seul
   sélecteur d'ID passe la spécificité en tier (1,…), qui bat par
   construction tout concurrent sans ID — sans `!important`, et avec une
   marge large plutôt qu'une victoire tangente.

   Règle appliquée aux DEUX champs : le premier correctif n'avait touché
   que le téléphone, alors que le champ nom perdait exactement le même
   combat, silencieusement, faute d'une déclaration explicite à opposer. */
.mu-appel.mu-appel.mu-appel .mu-appel__champ {
    text-align: right;
}

/* ---------------------------------------------------------------------
   Le téléphone reçoit EN PLUS une direction figée — lui seul.

   PIÈGE DÉJÀ DOCUMENTÉ SUR CE PROJET : un numéro tapé avec des espaces
   (« 27 950 555 ») dans un champ en `direction: rtl` s'afficherait à
   l'ENVERS — les espaces sont neutres et se résolvent RTL dans un
   contexte RTL, exactement comme le piège des e-mails déjà rencontré ici
   (« 27 950 555 » → « 555 950 27 »). `direction: ltr` évite ce piège :
   les chiffres restent lisibles dans l'ordre où ils sont tapés, et le
   `text-align: right` ci-dessus ancre la boîte à droite malgré cette
   direction — les deux propriétés sont indépendantes.

   Même renfort de spécificité, et pour la même raison : le kit peut tout
   aussi bien imposer sa propre `direction` sur ce sélecteur générique.

   LE CHAMP NOM, LUI, N'EST PAS FIGÉ EN DIRECTION. Un nom peut être arabe
   ou latin ; `dir="auto"` doit rester libre de choisir au cas par cas —
   seule sa BOÎTE est fixée à droite, pas le sens de son contenu. */
.mu-appel.mu-appel.mu-appel .mu-appel__champ[type="tel"] {
    direction: ltr;
}

.mu-appel .mu-appel__champ::placeholder {
    color: #9a9a9a;
    opacity: 1;
}

/* Le thème pose `a:focus { outline: none }` et le kit repeint les focus :
   l'anneau est redit ici, orange sur violet comme sur blanc. */
.mu-appel .mu-appel__champ:focus {
    outline: none;
    box-shadow: 0 0 0 3px rgba(255, 150, 22, .55);
}

.mu-appel .mu-appel__champ.est-invalide {
    box-shadow: inset 0 0 0 2px var(--mu-appel-erreur);
}

/* ---------------------------------------------------------------------
   Le bouton إتصل بي
   --------------------------------------------------------------------- */
.mu-appel .mu-appel__bouton {
    position: relative;
    isolation: isolate;        /* le reflet reste sous le libellé  */
    overflow: hidden;          /* et borné par la pilule           */
    flex: 1 1 160px;
    display: inline-flex;
    align-items: center;
    justify-content: center;
    gap: 18px;                 /* button_icon_indent du widget d'origine */
    border: 0;
    border-radius: 25px;
    padding: 16px 28px;
    background: var(--mu-appel-orange);
    background-image: none;
    color: #fff;
    font-family: var(--mu-appel-police);
    font-size: 19px;
    font-weight: 700;
    line-height: 1.2;
    cursor: pointer;
    box-shadow: 0 0 10px 0 rgba(0, 0, 0, .5);
    transition: transform .45s var(--mu-appel-elan),
                box-shadow .45s var(--mu-appel-elan);
}

/* Reflet balayé — même geste que les boutons Messenger / WhatsApp, pour
   que le site garde un seul vocabulaire d'animation. */
.mu-appel .mu-appel__bouton::before {
    content: "";
    position: absolute;
    inset: 0;
    z-index: -1;
    border-radius: inherit;
    background: linear-gradient(115deg,
        rgba(255, 255, 255, 0) 38%,
        rgba(255, 255, 255, .30) 50%,
        rgba(255, 255, 255, 0) 62%);
    transform: translateX(-130%);
    pointer-events: none;
}

.mu-appel .mu-appel__bouton:hover::before,
.mu-appel .mu-appel__bouton:focus-visible::before {
    animation: mu-appel-reflet .9s ease;
}

@keyframes mu-appel-reflet {
    to { transform: translateX(130%); }
}

/* ---------------------------------------------------------------------
   L'ORANGE DOIT SURVIVRE À TOUS LES ÉTATS — Y COMPRIS `:focus`.

   DÉFAUT CONSTATÉ : après un clic sur le bouton, celui-ci virait au ROUGE
   et n'en revenait qu'en cliquant ailleurs. Cause trouvée dans la source
   d'Elementor, `core/kits/documents/tabs/theme-style-buttons.php:46-54` :
   le Theme Style range `{{WRAPPER}} button:focus` (ligne 48) dans le MÊME
   groupe de sélecteurs que `:hover`, et lui applique la couleur de survol
   du kit — ici #961040, le rouge observé.

   Je n'avais couvert que `:hover` et `:focus-visible`. Or un clic à la
   souris pose `:focus` mais PAS `:focus-visible` (réservé au clavier) :
   aucune de mes règles ne s'appliquait, et `.elementor-kit-1690
   button:focus` à (0,2,1) l'emportait sur ma règle de base à (0,2,0).
   D'où le rouge, et sa persistance jusqu'à la perte du focus.

   LA COULEUR ET LE MOUVEMENT SONT SÉPARÉS, volontairement :
   `:focus` ne doit que défendre l'orange — un bouton qui resterait
   soulevé après un clic donnerait l'impression d'être encore survolé.
   La levée reste réservée à `:hover` et `:focus-visible`.

   Ancrage sur `#mu-appel` : même raison que pour les champs, il faut
   passer au-dessus du (0,2,1) du kit avec une marge confortable.
   --------------------------------------------------------------------- */
.mu-appel.mu-appel.mu-appel .mu-appel__bouton,
.mu-appel.mu-appel.mu-appel .mu-appel__bouton:hover,
.mu-appel.mu-appel.mu-appel .mu-appel__bouton:focus,
.mu-appel.mu-appel.mu-appel .mu-appel__bouton:focus-visible,
.mu-appel.mu-appel.mu-appel .mu-appel__bouton:active {
    background-color: var(--mu-appel-orange);
    background-image: none;
    color: #fff;
    border-color: transparent;
}

/* La levée, elle, reste un signal de SURVOL et de navigation clavier. */
.mu-appel.mu-appel.mu-appel .mu-appel__bouton:hover,
.mu-appel.mu-appel.mu-appel .mu-appel__bouton:focus-visible {
    transform: translateY(-4px);
    box-shadow: 0 16px 34px rgba(255, 150, 22, .38),
                0 4px 12px rgba(0, 0, 0, .28);
}

.mu-appel.mu-appel.mu-appel .mu-appel__bouton:active {
    transform: translateY(-1px);
    box-shadow: 0 8px 18px rgba(255, 150, 22, .30);
}

/* Le focus SOURIS ne montre aucun anneau (il serait parasite), le focus
   CLAVIER en montre un — c'est tout l'intérêt de `:focus-visible`. */
.mu-appel.mu-appel.mu-appel .mu-appel__bouton:focus {
    outline: none;
}

.mu-appel.mu-appel.mu-appel .mu-appel__bouton:focus-visible {
    outline: 3px solid #fff;
    outline-offset: 3px;
}

/* Pendant l'envoi : le script pose la classe, le double clic est déjà
   neutralisé par `disabled`, ceci le montre. */
.mu-appel .mu-appel__bouton.est-occupe {
    opacity: .65;
    cursor: wait;
    transform: none;
}

.mu-appel .mu-appel__ico { display: block; }

/* ---------------------------------------------------------------------
   Messages
   --------------------------------------------------------------------- */
.mu-appel .mu-appel__message {
    margin: 10px 2px 0;
    min-height: 1.4em;         /* la zone existe toujours : pas de saut */
    font-family: var(--mu-appel-police);
    font-size: 15px;
    font-weight: 600;
    line-height: 1.6;
}

.mu-appel .mu-appel__message--ok { color: var(--mu-appel-ok); }
.mu-appel .mu-appel__message--erreur { color: var(--mu-appel-erreur); }

/* ---------------------------------------------------------------------
   Adaptations
   --------------------------------------------------------------------- */
@media (max-width: 640px) {

    .mu-appel .mu-appel__grille {
        flex-direction: column;
        align-items: stretch;
    }

    /* ------------------------------------------------------------------
       LE `flex-basis` CHANGE D'AXE — ET C'EST CE QUI CASSAIT LE MOBILE.

       Sur ordinateur, `flex: 1 1 180px` sur les champs et `1 1 160px` sur
       le bouton fixe une LARGEUR de base : les trois éléments se partagent
       la ligne. Correct.

       Mais `flex-basis` porte toujours sur l'AXE PRINCIPAL. En passant la
       grille en `flex-direction: column`, cet axe devient la VERTICALE :
       les mêmes 180px et 160px deviennent des HAUTEURS de base, que
       `flex-grow: 1` fait encore gonfler. D'où les trois pavés géants
       constatés sur téléphone — le rembourrage, la police et le rayon
       étaient pourtant justes.

       On rend donc leur hauteur naturelle aux éléments : `flex: 0 0 auto`
       les dimensionne par leur contenu et leur rembourrage, comme des
       blocs ordinaires. La largeur, elle, est déjà assurée par
       `align-items: stretch` sur la grille.
       ------------------------------------------------------------------ */
    .mu-appel.mu-appel.mu-appel .mu-appel__champ,
    .mu-appel.mu-appel.mu-appel .mu-appel__bouton {
        flex: 0 0 auto;
        width: 100%;
    }

    /* `height: auto` en renfort : le thème pose `input { height: 40px }`
       (histudy/style.css, spécificité 0,0,1) et un widget d'un autre
       greffon pourrait poser mieux. On affirme la hauteur naturelle plutôt
       que de la supposer acquise. */
    .mu-appel.mu-appel.mu-appel .mu-appel__champ {
        height: auto;
    }

    .mu-appel.mu-appel.mu-appel .mu-appel__bouton {
        font-size: 15px;       /* button_typography_font_size_mobile du widget */
    }
}

/* ---------------------------------------------------------------------
   Mouvement réduit
   --------------------------------------------------------------------- */
@media (prefers-reduced-motion: reduce) {

    .mu-appel .mu-appel__bouton { transition: none; }

    .mu-appel .mu-appel__bouton::before,
    .mu-appel .mu-appel__bouton:hover::before,
    .mu-appel .mu-appel__bouton:focus-visible::before { animation: none; }

    .mu-appel .mu-appel__bouton:hover,
    .mu-appel .mu-appel__bouton:focus-visible { transform: none; }
}