/* ==========================================================================
   SUNYA - Form di terze parti: WPForms

   PERCHE' STA NEL PARENT (deciso 2026-08-20)

   Il difetto non ha niente di specifico a un brand: qualunque sito Sunya
   in modalita' Scura con WPForms ha le stesse etichette illeggibili. Qui
   non si sceglie nessun colore — si mappano i token del tema sulle
   variabili del plugin. E' derivazione, cioe' il mestiere del parent; il
   brand resta nel child, che ridefinendo i propri --sunya-color-* muove
   anche i form senza toccare questo file.

   Precedente in casa: WooCommerce e' un plugin di terzi e il parent lo
   copre da sempre.

   IL DIFETTO, MISURATO (lab, modalita' Scura, carta #0a0a0a)

     .wpforms-field-label          18.00  — lo copriva il child
     .wpforms-field-label-inline    1.05  — radio e checkbox, INVISIBILI
     .wpforms-field-sublabel        1.03  — INVISIBILI
     campo di testo                 8.52  — leggibile, ma bianco in un
                                            tema scuro

   Le due voci a 1.0x sono le etichette di radio, checkbox e consenso
   GDPR: il testo che dice all'utente cosa sta accettando.
   (Ratio calcolati componendo l'alpha sul fondo: il plugin usa
   rgba(0,0,0,.85), e misurarlo come nero pieno darebbe numeri falsi.)

   PERCHE' MAPPARE LE VARIABILI E NON RINCORRERE I SELETTORI

   Il child roxzone ci aveva provato per selettori, e le sue regole sui
   campi PERDEVANO in silenzio: `.wpforms-container input[type="text"]`
   pesa (0,2,1), il plugin dichiara `div.wpforms-container-full
   input[type="text"]` a (0,2,2). Il child credeva di aver scurito i
   campi; erano bianchi.

   Verificato dove WPForms dichiara le sue variabili:

     :root inline                        tutti i COLORI
     #wpforms-<id>.wpforms-block-<uuid>  solo DIMENSIONI, zero colori

   Una dichiarazione su .wpforms-container e' sull'ELEMENTO e batte
   l'ereditarieta' da :root senza competere per specificita'. Nessun
   !important, e nessuna rincorsa.

   E se un domani l'utente imposta i colori nel builder del form, quelli
   finiscono nel blocco per-form a (1,1,0) e battono questo file: la
   scelta esplicita dell'utente vince sul default del tema. E' la lezione
   della v1.6.8 — una regola del tema non deve annullare l'impostazione
   di chi la usa — e qui viene gratis.
   ========================================================================== */

.wpforms-container {
    /* Etichette: l'inchiostro del corpo del testo. Le sublabel usano
       l'inchiostro secondario, gia' derivato dal PHP come miscela fra
       testo e carta (v1.2.9) — resta piu' tenue in entrambe le
       modalita' senza bisogno di un secondo valore di brand. */
    --wpforms-label-color: var(--sunya-color-text);
    --wpforms-label-sublabel-color: var(--sunya-color-text-light);

    /* Campi: stessa carta della pagina — scelta esplicita, stile
       "outlined": e' il BORDO a dire dove sta il controllo, non un
       riempimento. Vale identica nelle due modalita' e il campo resta
       coerente con la superficie su cui e' posato.

       Il bordo percio' deve reggere da solo: --sunya-color-field-border
       (v1.8.8) e' derivato al 40% invece del 15% di --sunya-color-border,
       che era nato per separare sezioni. Misurato prima: 1.31 su carta
       scura, sotto il 3:1 che WCAG 1.4.11 chiede al confine di un
       componente. Il fallback resta il vecchio token, per un child che
       giri ancora su un parent senza la derivazione. */
    --wpforms-field-text-color: var(--sunya-color-text);
    --wpforms-field-background-color: var(--sunya-color-bg);
    --wpforms-field-border-color: var(--sunya-color-field-border, var(--sunya-color-border));

    /* Tendina aperta: stessa carta dei campi, altrimenti in Scuro il
       menu resta un rettangolo bianco sopra il form. */
    --wpforms-field-menu-color: var(--sunya-color-bg);

    /* Pulsante di invio: accent pieno con l'inchiostro che il PHP ha
       gia' scelto leggibile su quell'accent (on-accent, v1.7.0). Il
       default del plugin e' un blu fisso #066aab, che ignora il brand. */
    --wpforms-button-background-color: var(--sunya-color-accent);
    --wpforms-button-text-color: var(--sunya-color-on-accent);
    --wpforms-button-border-color: var(--sunya-color-accent);
}

/* Il placeholder non ha una variabile nel plugin: unico punto in cui
   serve un selettore. Inchiostro secondario, come le sublabel. */
.wpforms-container input::placeholder,
.wpforms-container textarea::placeholder {
    color: var(--sunya-color-text-light);
    opacity: 1;
}

/* Messa a fuoco da tastiera (v1.8.8).

   In uno stile outlined il bordo E' il controllo: senza uno stato di
   focus marcato, chi naviga con Tab perde il segno esattamente dove
   servirebbe di piu'. `outline` e non `border`, cosi' il layout non si
   sposta di un pixel a ogni tabulazione.

   accent-ink e non accent: e' l'inchiostro gia' calibrato sulla carta
   corrente (v1.7.5), quindi regge in entrambe le modalita' — l'accent
   nudo su carta chiara puo' scendere a 1.23 sui brand luminosi.

   Selettore a (0,3,1) come per il pulsante di invio: il plugin dichiara
   i propri stati a (0,2,2) e una regola piu' leggera perderebbe. */
.wpforms-container .wpforms-form input:focus-visible,
.wpforms-container .wpforms-form textarea:focus-visible,
.wpforms-container .wpforms-form select:focus-visible {
    outline: 2px solid var(--sunya-color-accent-ink, var(--sunya-color-accent));
    outline-offset: 2px;
}

/* NON si tocca --wpforms-label-error-color (#d63637).
   Un rosso di errore e' una scelta di brand, non una derivazione: il
   parent non ha un token per il colore di errore, e inventarne uno qui
   sarebbe esattamente il tipo di decisione che la separazione di
   competenze tiene fuori dal parent. Misurato su #0a0a0a da' circa 4.0,
   sufficiente per gli avvisi brevi a cui e' destinato; un child che
   voglia il proprio rosso ridefinisce la variabile nel suo :root. */