/*
 * Il grigio del testo secondario non e' una scelta grafica nostra: e' il default di Bootstrap 3.
 *
 * Audit TxDOT §2.6 (DGWGEOWORK-9114) -- WCAG 2.1 AA, 1.4.3 Contrast (Minimum): il testo deve
 * stare ad almeno 4,5:1 sul proprio fondale. `.text-muted` sta sotto quella soglia gia' su
 * bianco, e sotto di parecchio quando finisce su un fondale grigio.
 *
 * MISURATO (formula di contrasto WCAG; da riverificare col Colour Contrast Analyser come
 * chiede il criterio di accettazione del ticket):
 *
 *   colore                   su #fff   su #f5f5f5   su #eee
 *   ----------------------   -------   ----------   -------
 *   #333    (body)             12,63       11,59      10,89
 *   #777    (.text-muted)       4,48        4,11        3,86   <- sotto 4,5 gia' su bianco
 *   #999    (placeholder)       2,85        2,61        2,46   <- fallisce ovunque
 *   #595959 (nuovo muted)       7,00        6,42        6,04
 *   #6b6b6b (nuovo placeh.)     5,33        4,89        4,59
 *
 * `#777` viene da `libs/bootstrap/css/bootstrap.css:1258`, `#999` da :2326-2332. Bootstrap 3
 * e' del 2013: quei due valori precedono l'adozione seria di WCAG 2.1 AA e non sono mai stati
 * scelti da nessuno qui dentro.
 *
 * PERCHE' #595959 E NON UN GRIGIO QUALSIASI.
 * Il testo muted deve restare distinguibile dal testo normale, altrimenti la classe non
 * comunica piu' niente. Il body e' `#333` a 12,63:1, il nuovo muted sta a 7,00:1: la gerarchia
 * visiva regge -- si legge ancora come "secondario" -- ma passa AA con margine anche sui
 * pannelli grigi, dove `#777` non passava affatto. Non e' un ridisegno: e' lo stesso grigio
 * spostato dove doveva stare.
 *
 * PERCHE' STA IN Common/Styles.
 * Stessa ragione di `focusVisible.css`, spiegata per esteso in testa a quel file: e' la sola
 * cartella pescata da entrambi i lati -- `common.min.css` per le pagine servite dal layout
 * frontend (home pre-login, login, registrazione tenant, pagine di errore) e, via la voce
 * `Common/Styles` di `bundles.json`, anche `app.min.css` per applicazione e menuless. Sotto
 * `App/` il correttivo non arriverebbe alla pagina di login, che e' quella che vede piu' gente.
 *
 * PERCHE' LA VARIABILE E' DICHIARATA QUI E NON NEL :root DI big.css.
 * Il blocco `:root` "Global css variables definition" di `Scripts/BIG/css/big.css` e' la sede
 * abituale delle variabili globali, ma `big.css` entra SOLO in `app.min.css`: sulle pagine
 * frontend non c'e'. Una variabile dichiarata la' e usata qui sarebbe indefinita proprio dove
 * serve -- e `color: var(--indefinita)` non ricade sul valore precedente: la dichiarazione
 * diventa invalida al momento del calcolo e il colore viene ereditato dal padre, che e' il
 * contrario di quello che vogliamo. Variabile e regole che la usano viaggiano nello stesso file.
 *
 * A COSA SERVE LA VARIABILE.
 * A dare ai temi cliente un punto solo da toccare. Il CSS del tenant viene appeso al <head> a
 * runtime (`App/common/services/appSession.js:25`), quindi arriva sempre dopo il bundle: un
 * cliente che ha bisogno di un muted diverso ridichiara `--text-muted-color` sul proprio
 * `:root` e tutte le regole di questo file lo seguono, `!important` compreso. E' il rimedio al
 * modo in cui il contrasto e' stato corretto finora -- una riga diversa nel foglio di ogni
 * cliente (`VTrans.css:171`, `Stuttgart.css:153`, `ComuneDiComo.css:211`, e fino a ieri
 * `Munich.css`), quattro risposte diverse allo stesso difetto e il difetto di base intatto per
 * tutti gli altri. Quelle quattro righe, ora, sono da rimuovere.
 *
 * SPECIFICITA' E !important.
 * La regola generale e' volutamente nuda, (0,1,0) come quella di Bootstrap: vince per ordine di
 * sorgente. In `app.min.css` la voce `Common/Styles` sta dopo `libs/bootstrap/css/bootstrap.css`;
 * nel layout frontend `common.min.css` e' l'ultimo dei tre `@Styles.Render`
 * (`Views/Layout/_Layout.cshtml:47-50`). Niente `!important`, cosi' un tema cliente puo' ancora
 * sovrascrivere per selettore e non solo per variabile.
 * L'unica eccezione e' bootstrap-select, dove `metronic/assets/global/css/plugins-md.css:353`
 * dichiara `#999 !important` con specificita' (0,3,0): fra due `!important` non vince chi arriva
 * dopo ma chi ha piu' specificita', quindi la si pareggia. Resta innocuo perche' il valore
 * arriva comunque dalla variabile.
 *
 * COSA QUESTO FILE NON TOCCA, DELIBERATAMENTE.
 * `Scripts/BIG/css/big.css:566` porta a `#333` il contenuto delle celle ui-grid marcate
 * `.text-muted`: e' una scelta esplicita, ha specificita' maggiore (0,3,0) e un soggetto
 * diverso (`.ui-grid-cell-contents`), quindi continua a vincere. Va bene: quel testo e' gia'
 * conforme.
 *
 * FUORI SCOPE.
 * §2.6 non e' solo il testo secondario: restano il pulsante Continue, il pulsante Save, il
 * banner rosso di errore e soprattutto le icone della mappa a certi livelli di zoom, che hanno
 * la soglia diversa (1.4.11 Non-text Contrast, 3:1) e non si chiudono con del CSS. Il ticket
 * resta DGWGEOWORK-9114 anche dopo questo file.
 */

:root {
    --text-body-color: #333;
    --text-muted-color: #595959;
    --input-placeholder-color: #6b6b6b;
}

.text-muted {
    color: var(--text-muted-color);
}

/* Unica regola con !important, e solo per pareggiare plugins-md.css:353 -- vedi SPECIFICITA'. */
.bootstrap-select.btn-group .dropdown-menu .text-muted {
    color: var(--text-muted-color) !important;
}

/*
 * Placeholder dei campi.
 * I selettori vendor stanno in regole SEPARATE e mai in una lista con la virgola: un browser
 * che non riconosce uno dei selettori di una lista scarta l'INTERA regola, quindi accorparli
 * farebbe perdere anche il selettore standard. Bootstrap dichiara solo i tre vendor e non
 * `::placeholder`: quello lo aggiungiamo qui.
 * `opacity: 1` perche' Firefox applica al placeholder un'opacita' ridotta di default, che
 * abbasserebbe il contrasto appena calcolato.
 */
.form-control::placeholder {
    color: var(--input-placeholder-color);
    opacity: 1;
}

.form-control::-webkit-input-placeholder {
    color: var(--input-placeholder-color);
}

.form-control::-moz-placeholder {
    color: var(--input-placeholder-color);
    opacity: 1;
}

.form-control:-ms-input-placeholder {
    color: var(--input-placeholder-color);
}

/*
 * Motivi per cui un pulsante di avanzamento della pratica non porta ancora avanti (DGWGEOWORK-9979):
 * l'elenco sotto CONTINUE nella modale di modifica e sotto la barra delle azioni sopra la mappa.
 * E' il testo su cui la guardia porta il focus quando il blocco non e' un campo, quindi si legge
 * col colore del testo normale e non col grigio di `.help-block` di Bootstrap (#737373): la
 * variabile `--text-body-color` e' la stessa che un tema cliente puo' ridichiarare (vedi A COSA
 * SERVE LA VARIABILE). Classe dedicata e non `.help-block`: ridefinire il colore di quella
 * classe cambierebbe ogni suggerimento dell'applicazione, per tutti i clienti.
 * Il margine stacca il testo dal pulsante, ed e' sulla prima riga e non sul contenitore: il
 * contenitore resta nel DOM anche vuoto (role="status" annuncia solo se c'era gia'), e un margine
 * suo allungherebbe di 10px ogni barra delle azioni senza blocchi.
 */
.gw-blocked-reasons > .help-block:first-of-type {
    margin-top: 10px;
}

.gw-blocked-reasons .help-block {
    color: var(--text-body-color);
}