/*
 * Il contorno di un campo di input dice DOVE si scrive: e' informazione, non decorazione, e
 * WCAG 2.1 AA 1.4.11 (Non-text Contrast) gli chiede almeno 3:1 sul proprio fondale.
 * Nell'applicazione non ci arrivava nessuno dei due bordi che un campo puo' avere.
 *
 * DA DOVE VIENE LA SEGNALAZIONE (DGWGEOWORK-9655, Muenchen).
 * «I campi non mostrano piu' il bordo, e' difficile individuare il campo d'input.» Il "piu'" ha
 * una data: l'installazione e' stata pubblicata il 09/09/2026 con l'epica di accessibilita'
 * DGWGEOWORK-9107, e dentro c'era DGWGEOWORK-9111, che ha messo il gate `$touched` sullo stato
 * di errore dei questionari. Prima, aprendo un questionario, ogni campo obbligatorio e vuoto era
 * cerchiato di rosso (`div.form-control.has-error` -> box-shadow a 7,26:1): sul loro questionario
 * «Art der Nutzung» sono 28 campi su 65. Da quella pubblicazione l'anello compare solo dopo che
 * il campo e' stato toccato -- che e' corretto, un campo mai toccato non e' in errore -- e sotto
 * e' rimasto il bordo di Bootstrap a 1,61:1, cioe' quasi niente.
 * 9111 non ha creato il difetto: ha tolto la stampella che lo copriva.
 *
 * MISURATO (formula di contrasto WCAG, su `getComputedStyle` dell'elemento vero nell'app in
 * esecuzione -- non letto dai fogli):
 *
 *   colore                            su #fff   su #f5f5f5   su #eee
 *   -------------------------------   -------   ----------   -------
 *   #ccc  (Bootstrap .form-control)      1,61        1,47      1,38   <- fallisce su tutti
 *   #ccc  (skin tinymce-5, editor)       1,61        1,47      1,38   <- idem
 *   #949494                              3,03        2,78      2,61   <- passa solo su bianco
 *   #767676 (questo file)                4,54        4,17      3,91
 *
 * PERCHE' #767676 E NON IL 3:1 ESATTO.
 * Un grigio scelto per stare appena sopra 3:1 su bianco (`#949494`) torna sotto soglia appena il
 * campo finisce su un pannello grigio, e i pannelli dell'applicazione sono `#f5f5f5`/`#eee`: il
 * rimedio dipenderebbe da dove sta il campo. `#767676` tiene in tutti e tre i casi.
 * FIN DOVE TIENE, detto esplicitamente: sopra 3:1 fino a un fondale di circa **#d4d4d4**
 * (3,06:1). Un tema che porta il pannello nella fascia media DEVE ridichiarare la variabile: il
 * foglio non se ne accorge da solo (vedi «cosa questo file non protegge»).
 *
 * PERCHE' SOLO IL COLORE.
 * Larghezza e stile restano quelli di prima, per Bootstrap come per la skin: cambia il minimo
 * necessario. Nessun bordo viene aggiunto -- viene reso visibile quello che c'era gia'.
 *
 * LE DUE REGOLE, E PERCHE' HANNO SPECIFICITA' DIVERSA.
 * - `.form-control` (0,1,0) e' volutamente nuda e vince per ORDINE DI SORGENTE, come fa
 *   `textContrast.css`: in `app.min.css` la voce `Common/Styles` sta dopo
 *   `libs/bootstrap/css/bootstrap.css`, e nel layout frontend `common.min.css` e' l'ultimo dei
 *   tre `@Styles.Render`. Restando a (0,1,0) qualunque regola piu' specifica continua a vincere,
 *   ed e' quello che vogliamo: `.has-error .form-control` resta rosso, il tema di un cliente
 *   resta suo.
 * - `.tox.tox-tinymce` (0,2,0) NON puo' affidarsi all'ordine. La skin di TinyMCE non sta nel
 *   bundle: la carica TinyMCE a runtime da `baseUrl` (e resta servita per URL apposta -- vedi
 *   `ADR-015-vendor-asset-publish-exclusion-hardening.md`, allow-list `skin/langs`), quindi il
 *   suo `<link>` entra nel documento DOPO i nostri fogli -- misurato: indice 117 su 124 fogli
 *   caricati. Una regola nuda perderebbe. L'elemento porta entrambe le classi
 *   (`class="tox tox-tinymce"`, verificato), quindi (0,2,0) vince per specificita' comunque.
 *   Provato iniettando questo foglio come PRIMO figlio di <head>, la posizione peggiore: vince.
 *
 * PERCHE' L'EDITOR NON BASTA E SERVIVA ANCHE `.form-control`.
 * Nella textarea del questionario il bordo dell'editor e' l'UNICO confine, perche' il wrapper
 * azzera il proprio con uno stile inline per non raddoppiarlo (`reviewAnswer.html`, blocco TextArea).
 * Ma quella e' UN campo: sul questionario da cui nasce la segnalazione e' 1 su 65, e gli altri
 * 64 sono input normali col bordo di Bootstrap. Correggere il solo editor avrebbe lasciato il
 * problema segnalato dov'era.
 *
 * PERCHE' NON SI TOCCA LA SKIN.
 * I file vendor vanno tenuti bit-identici all'upstream, altrimenti la correzione si perde al
 * primo aggiornamento della libreria e i diff diventano illeggibili. Vedi
 * `ADR-015-vendor-asset-publish-exclusion-hardening.md` (ancora `stato: proposto`; cinque ADR
 * condividono l'id `ADR-015`, per questo si cita il nome del file).
 *
 * PERCHE' STA IN Common/Styles.
 * E' la sola cartella pescata sia da `common.min.css` sia da `app.min.css` -- il perche' per
 * esteso e' in testa a `focusVisible.css` e `textContrast.css`, e non si ricopia qui.
 *
 * A COSA SERVE LA VARIABILE.
 * A dare ai temi cliente un punto solo da toccare, per tutti i campi insieme. Il CSS del tenant
 * NON e' il file in `CustomersCSS/` (quello puo' essere una copia vecchia): e' un oggetto
 * per-tenant nel database, servito da `TenantCustomizationController.GetCustomCss` e appeso al
 * <head> a runtime da `App/common/services/appSession.js:24-26`, quindi dopo il bundle. Un
 * cliente ridichiara `--gw-field-border-color` sul proprio `:root` e queste regole lo seguono
 * (verificato). Niente `!important`, cosi' un tema puo' comunque sovrascrivere per selettore.
 *
 * COSA QUESTO FILE NON TOCCA, DELIBERATAMENTE.
 * - Lo STATO DI ERRORE, che e' gia' marcato e non va raddoppiato: `Scripts/BIG/css/big.css` mette
 *   `box-shadow: 0 0 0 1px var(--gw-field-error-color)` su `div.form-control.has-error`
 *   (DGWGEOWORK-9110) -- misurato 7,26:1 -- e il box-shadow NON e' annullato dallo stile inline
 *   `border:transparent` del wrapper. Aggiungere qui un rosso darebbe due anelli di tinta diversa.
 * - `div.questionBorder` (`big.css:1031`), il riquadro attorno alla domanda: `2px solid #D4D4D4`
 *   = 1,48:1, stesso ordine di problema. Sta fuori perche' e' un contenitore di RAGGRUPPAMENTO e
 *   non il confine di un campo, e scurirlo cambia a vista ogni questionario che lo usa (31 volte
 *   nel solo template 105 di Muenchen): e' una scelta d'aspetto che vuole l'occhio di chi la
 *   riceve.
 * - I separatori INTERNI della skin (`.tox-statusbar`, bordo inferiore della barra strumenti):
 *   separano parti dell'editor, non dicono dove finisce il campo.
 * - L'editor INLINE (`.tox-tinymce-inline`), che per la skin non ha bordo affatto: qui si tocca
 *   il solo colore, quindi la' non compare niente (verificato).
 *
 * COSA QUESTO FILE NON PROTEGGE.
 * Niente impedisce alla regressione di tornare in automatico: la verifica «bordo dei campi» di
 * `.claude/scripts/a11y/browser-checks.js` e' uno strumento da CONSOLE, non gira in
 * `Tools/CICD/run_tests.ps1` ne' in pipeline. Debito dichiarato su DGWGEOWORK-9655.
 *
 * Il residuo §2.6 di DGWGEOWORK-9114 si restringe ma non si chiude: restano fuori il pulsante
 * Continue, il banner rosso e le icone della mappa.
 */

:root {
    --gw-field-border-color: #767676;
}

/* Campi standard: nuda a (0,1,0), vince per ordine di sorgente su Bootstrap. */
.form-control {
    border-color: var(--gw-field-border-color);
}

/* Editor di testo ricco: (0,2,0), perche' la skin di TinyMCE entra DOPO i nostri fogli. */
.tox.tox-tinymce {
    border-color: var(--gw-field-border-color);
}

/*
 * Stato di errore sull'editor.
 *
 * NON e' il doppione che una review aveva giustamente bocciato in una versione precedente: li'
 * avevo messo un rosso LETTERALE e DIVERSO (#e73d4a) accanto all'anello del wrapper (#a4262c),
 * cioe' due tinte a 1px di distanza. Qui il colore e' lo STESSO, dalla stessa variabile: il
 * risultato e' un bordo rosso unico, non due.
 *
 * Perche' serve. Il wrapper della textarea marca l'errore con un `box-shadow: 0 0 0 1px
 * var(--gw-field-error-color)` (`big.css`, DGWGEOWORK-9110), che cade FUORI dal riquadro; il
 * wrapper ha `padding: 0`, quindi quell'anello finisce appiccicato al bordo dell'editor. Finche'
 * il bordo dell'editor era `#ccc` il rosso spiccava; ora che e' `#767676` le due righe da 1px si
 * annullano a vista e l'errore "sparisce dietro" l'editor - riferito da chi lo usa e verificato
 * a schermo. Colorando anche il bordo dell'editor le due righe diventano un unico bordo rosso da
 * 2px, che si legge come errore da qualunque distanza.
 *
 * Il fallback `#a4262c` non e' un colore nuovo: e' lo stesso valore che `big.css` da' alla
 * variabile, e serve perche' quella variabile e' dichiarata nel `:root` di `big.css`, che entra
 * SOLO in `app.min.css`. Questo foglio sta anche in `common.min.css` (login, pagine frontend):
 * la' `var(--gw-field-error-color)` sarebbe indefinita, e una dichiarazione con variabile
 * indefinita non ricade sul valore precedente - diventa invalida e il colore viene ereditato dal
 * padre. E' la stessa trappola documentata in testa a `textContrast.css`.
 *
 * Specificita' (0,3,0): batte la regola qui sopra e la skin.
 */
.has-error .tox.tox-tinymce {
    border-color: var(--gw-field-error-color, #a4262c);
}