/* Solid <select> backgrounds — documented pitfall #9.
 *
 * Most select styling in the app comes from shared `.form-control,
 * .form-select` / `input, select, textarea` rules with a semi-transparent
 * background. That reads fine on the closed control, but the native dropdown
 * list inherits it and renders illegibly on Windows and some Linux browsers.
 *
 * Editing those shared rules would restyle every text input too, so this
 * targets selects only. The colour matches the fix protrack already applies
 * locally (static/css/protrack/styles.css) — the app is uniformly dark-themed
 * (the single light `body` rule is inside @media print), so one value works
 * everywhere.
 *
 * Specificity is deliberate. `select[class]` is (0,1,1), which beats every
 * single-class rule that styles selects in this app (.form-control,
 * .form-select, .crm-form-select, .accounting-form-select, .glass-input, ...)
 * without having to enumerate them and without catching future ones by
 * surprise. Anything more specific — a two-class rule, an id, or !important —
 * still wins, so a page that has deliberately styled a select keeps its look.
 *
 * The `option` rule below is deliberately left at (0,0,2) so the per-module
 * `option` rules several stylesheets already define keep winning; those are
 * already opaque, which is all this needs to guarantee.
 */

select,
select[class] {
    background-color: #1a2b4c;
}

/* The dropdown list itself — the part that was actually illegible. */
select option,
select optgroup {
    background-color: #1a2b4c;
    color: #ffffff;
}