/* ==========================================================================
Form control fill — one value for every input box on the panel
==========================================================================
Owner-directed (2026-09-16): every input box on the LIGHT theme fills with
#FFF8EB. The first instruction was #FFFCF7 and the owner corrected it to
#FFF8EB, which is the panel/surface rung of the cream ladder — so the fields
now sit on the same value as the cards they live on and are read by their
border, rather than as a recessed #F5EBDC control well. `.interface-design/system.md`
and DESIGN.md were updated in the same pass on purpose: the old value is written
down there as locked, and a stale "locked" line is exactly how a change like this
gets silently reverted by the next person who reads the doc.
LIGHT THEME ONLY. Dark keeps the locked dark well (#2A2C36 on the #383A46
panel). There is no dark rule in this file, deliberately.
HOW THE VALUE IS HELD UP — two mechanisms, both needed:
1. The declarations themselves were fixed at the source: 177 value swaps across
19 stylesheets, every one of them a light field fill (#F5EBDC 21, #fff 49,
#F0E4D0 1, #FFF1DC, …) becoming #FFF8EB. A value swap keeps each rule's own
specificity and importance intact, which an appended override cannot do for the
ID-level rules this repo is full of (`#pcTitle`, `#madProviderMarkup`,
`#settlementType`, `#menuPermissionFilter`, …). The diff is auditable: every
changed line differs from its original by exactly one colour token.
2. This sheet is the guarantee for everything a value swap could not reach: controls
with no rule of their own, and the field-shaped boxes that carry a fill through a
`var(--token)` which resolves per theme — those cannot be flattened to a literal
without breaking dark, so they are overridden here under a light guard instead.
WHY `body:not(#bo-input-fill-legacy):not(#bo-input-fill-legacy-2)`: nothing in the markup carries
either id. This is the specificity escalation this repo already uses
(`body:not(#bo-filter-standard-off):not(#bo-filter-standard-legacy)` in
bo-wallet-transaction-amber.css), and the step count is measured, not guessed: against
main-report-charcoal-content.css `…#settlementPaymentModal .modal-body .form-control{
background:#F5EBDC!important}` a single step still lost — the textarea computed to the old
#F5EBDC — and two steps won. Without them this file documents an intent it cannot enforce.
`background-color` only, never the `background` shorthand: a select draws its caret with
a background-image, and the shorthand would wipe it. Verified that no light-theme rule
fills a control with a gradient, so a colour override is enough to be visible everywhere.
-------------------------------------------------------------------------- */
/* 1. The real controls, whatever their class — 875 inputs, 379 selects and 60 textareas
across the 142 pages carry 29 different class names, so the tag is the reliable
selector and the :not() list is the exclusion set:
· hidden — no box to fill
· checkbox / radio / file / range / color — not text fields
· submit / button / reset — buttons, not fields
· :disabled / [readonly] — locked fields keep the #EDE4D4 dead state
(e.g. #madEditUsername on the edit page, which is `readonly`) */
html:not([data-bo-theme="dark"]) body:not(#bo-input-fill-legacy):not(#bo-input-fill-legacy-2) input:not([type="hidden"]):not([type="checkbox"]):not([type="radio"]):not([type="file"]):not([type="range"]):not([type="color"]):not([type="submit"]):not([type="button"]):not([type="reset"]):not(:disabled):not([readonly]),
html:not([data-bo-theme="dark"]) body:not(#bo-input-fill-legacy):not(#bo-input-fill-legacy-2) select:not(:disabled),
html:not([data-bo-theme="dark"]) body:not(#bo-input-fill-legacy):not(#bo-input-fill-legacy-2) textarea:not(:disabled):not([readonly]):not(.layout-code-pane textarea){
background-color:#FFF8EB!important;
}
/* The one control that must stay transparent, and why: the code editors on layout-section.html
are an overlay trick — a `.layout-code-highlight` layer paints the colourised code and the
textarea sits on top with `color:transparent` to catch the caret, so an opaque fill would
cover the code and leave an empty box. The `:not(.layout-code-pane textarea)` above is a
Selectors-4 complex :not() (Chrome-supported). Measured on layout-section.html: the textarea
still computes to transparent. */
/* 2. The field-shaped widgets that are not /