/* ============================================================================
COOP THEME -- PAGE CONTENT, following the navbar skin
JJE/Claude 08/23/2026. Section headers, headings and the generic action button
take their colour from whichever skin is selected for the Navbar Background, so
picking a swatch repaints the whole page rather than just the bar at the top.
HOW IT FOLLOWS. AdminSettings, app-style-switcher.js and coop-theme-memory.js
all write data-navbarbg onto #main-wrapper, so one variable keyed off that
attribute is enough and the page repaints the instant a swatch is clicked - no
reload, nothing to wire up. Everything below reads --coop-chrome.
WHY NOT THE SKIN'S OWN COLOUR, VERBATIM. Every .bg-info surface in this tree
carries text-white, .btn-info sets color:#fff, and .text-info is body text on
white. Two of the six template skins cannot carry white text at all - skin6 is
#e9ecef, near white, and skin4 is a light grey - so using the swatch colour as
painted would make headings invisible on those two and marginal on others. Even
the template's own default, skin1 #2cabe3, is 2.6:1 against white.
So each skin maps to a DARKENED VARIANT OF ITS OWN HUE, chosen to clear 4.5:1
against white. The page still visibly follows the navbar - blue navbar, blue
headers - it just uses a shade that can be read. Contrast is symmetric, so the
same number covers white-on-colour and colour-on-white.
skin1 #2cabe3 blue -> #1A6E8C 5.8:1
skin2 #707cd2 indigo -> #4E58B0 6.3:1
skin3 #ff7676 red -> #B33A3A 5.9:1
skin4 #a0aec4 grey -> #5A6880 5.6:1
skin5 #2f323e charcoal -> #2F323E 13.1:1 (already dark, used as painted)
skin6 #e9ecef near-white-> #495057 8.2:1 (no dark version of white keeps
its identity; neutral is honest)
skin7 #5B8C3A coop green-> #3F6A24 6.4:1
THE DEFAULT IS THE COOP GREEN. :root carries it, so any page with no skin on it
- the login pages and the whole membership flow on _PortalLayout, which never
load the admin template - stays branded rather than falling back to blue.
THE ACCOUNT-TYPE LEGEND IS CLAIMED HERE TOO, since 08/24/2026 - see the block
at the foot of this file. Views/Transaction/Index.cshtml and the five History
pages colour each card by what it holds, and repeat that colour on the
account's detail page. It reads as decoration but it is a legend: it is how a
member picks their loan out of six cards at a glance. So it kept four colours -
they are simply DERIVED now rather than the template's, and each skin block
below carries its own four alongside the chrome colour. The legend follows the
skin like everything else here; what it must never do is READ --coop-chrome,
which would collapse two account types onto one colour. See the foot of the
file for why deriving is what makes following safe.
Only the INFO family is claimed by the rules immediately below, and only
because in this tree it is not a status at all - all 90-odd uses are chrome:
.bg-info 29x, 26 of them literally card-header / card-title
.text-info 46x, page and section headings
.btn-info 15x, the primary action - Search, Update, SIGN UP, Activate
WHY !important, AND WHY IT IS NOT ENOUGH ON ITS OWN. The template declares
.bg-info and .text-info as Bootstrap 4 utilities, which carry !important
themselves:
.bg-info{background-color:#2cabe3!important}
so the replacement has to carry !important too. But !important only settles a
contest between rules of DIFFERENT importance; between two !important rules of
equal specificity the winner is still the later one. That is why both rules
below are additionally qualified with :root -- see the note above them, and the
Help & FAQs page that spent a day blue because they were not.
.btn-info is no longer declared here at all; Css\coop-theme-buttons.css owns
every button class now.
TWO BOOTSTRAPS. Dashboard pages get .text-info from the admin template; the
membership flow gets it from Bootstrap 3 (#3a87ad, no !important). This file is
linked late in every layout, which covers both -- but "late" is not something to
rely on: 74 views in this tree link a stylesheet from the BODY, which is after
every layout . Specificity is what actually decides it.
IE11 has no var(), so it takes the literal in each pair and gets the coop green
everywhere - correct, just not skin-aware. Do not tidy the first line away.
============================================================================ */
/* --- The chrome colour, and what each skin maps it to -------------------- */
:root {
--coop-chrome: #3F6A24;
--coop-chrome-dark: #2E4E1A;
}
#main-wrapper[data-navbarbg="skin1"] {
--coop-chrome: #1A6E8C;
--coop-chrome-dark: #145A73;
--acct-savings: #217FA8;
--acct-share: #BB2BDE;
--acct-timedeposit: #30881A;
--acct-loan: #BF5425;
}
#main-wrapper[data-navbarbg="skin2"] {
--coop-chrome: #4E58B0;
--coop-chrome-dark: #3F4A9E;
--acct-savings: #6570BD;
--acct-share: #45825C;
--acct-timedeposit: #7E7743;
--acct-loan: #A85A8A;
}
#main-wrapper[data-navbarbg="skin3"] {
--coop-chrome: #B33A3A;
--coop-chrome-dark: #932F2F;
--acct-savings: #BD5757;
--acct-share: #3B7F7F;
--acct-timedeposit: #5D7F3B;
--acct-loan: #925CC7;
}
#main-wrapper[data-navbarbg="skin4"] {
--coop-chrome: #5A6880;
--coop-chrome-dark: #49556B;
--acct-savings: #6D7685;
--acct-share: #976191;
--acct-timedeposit: #517D56;
--acct-loan: #867356;
}
#main-wrapper[data-navbarbg="skin5"] {
--coop-chrome: #2F323E;
--coop-chrome-dark: #23252E;
--acct-savings: #2F323E;
--acct-share: #1B522C;
--acct-timedeposit: #52471B;
--acct-loan: #521B42;
}
#main-wrapper[data-navbarbg="skin6"] {
--coop-chrome: #495057;
--coop-chrome-dark: #343A40;
--acct-savings: #747677;
--acct-share: #AC39AC;
--acct-timedeposit: #2C862C;
--acct-loan: #9E6934;
}
/* SKIN7 IS DELIBERATELY ABSENT FROM THIS BLOCK, AND FROM THE ONE BELOW.
Claude 08/24/2026.
skin1-6 are the template's own palette: six fixed colours that mean nothing but
themselves, so each maps to a fixed darkened variant above. skin7 is different --
it means "the cooperative's colour", and since Phase 5 of docs\coop-theme\PLAN.md
that is a value an administrator sets in Coop Settings.
Views\Shared\_CoopThemeTokens.cshtml already declares the configured colour on
:root. A skin7 entry here would be a SECOND copy of the same fact, at higher
specificity, so it would win -- which is exactly what happened: a cooperative
saved a new colour, every page with no skin turned that colour, and every
dashboard page stayed green because this line overrode it. skin7 being the
shipped default meant a signed-in user saw no change at all.
With no entry, data-navbarbg="skin7" matches nothing here and falls through to
:root, which is the cooperative's colour by definition. Picking skin3 and then
skin7 again still works: the first sets the red, the second matches no rule and
lands back on the brand.
Do not "complete the set" by adding skin7 back. */
/* --- The same mapping, for everything that sits OUTSIDE #main-wrapper -----
Claude 08/24/2026. A custom property only reaches DESCENDANTS of the element
it is declared on, and the block above declares it on #main-wrapper. Several
themed things are not inside #main-wrapper at all -- _LayoutDashboard closes
that div and then renders, as siblings:
_CustomPanel the customizer, including the cog tab and its tabs
the footer
#idle-timeout-dialog whose keepalive button is a .btn-success
Every one of those fell through to the :root default instead, so they painted
the coop green and then STAYED green when someone picked another swatch --
"it changes colour but does not follow the navbar", which is exactly right.
The rules that consume the variable were fine; the variable never arrived.
`~ *` is the general sibling combinator: every element after #main-wrapper,
whose subtree then inherits normally. It is CSS2/IE9-era, unlike :has(), which
would be the obvious modern answer and is not available to this tree.
ONE THING IT DOES NOT COVER: _NotificationPanel is rendered BEFORE
#main-wrapper, and a sibling combinator cannot look backwards. It carries no
themed class today. If one is ever added there, it will sit on the default
green and not follow the skin, and the fix will be to stamp the skin on
in Scripts\dashboard\coop-theme-memory.js rather than to add more selectors
here.
Setting two custom properties on a footer and a few modals costs nothing:
a custom property does nothing at all unless something reads it. */
#main-wrapper[data-navbarbg="skin1"] ~ * {
--coop-chrome: #1A6E8C;
--coop-chrome-dark: #145A73;
--acct-savings: #217FA8;
--acct-share: #BB2BDE;
--acct-timedeposit: #30881A;
--acct-loan: #BF5425;
}
#main-wrapper[data-navbarbg="skin2"] ~ * {
--coop-chrome: #4E58B0;
--coop-chrome-dark: #3F4A9E;
--acct-savings: #6570BD;
--acct-share: #45825C;
--acct-timedeposit: #7E7743;
--acct-loan: #A85A8A;
}
#main-wrapper[data-navbarbg="skin3"] ~ * {
--coop-chrome: #B33A3A;
--coop-chrome-dark: #932F2F;
--acct-savings: #BD5757;
--acct-share: #3B7F7F;
--acct-timedeposit: #5D7F3B;
--acct-loan: #925CC7;
}
#main-wrapper[data-navbarbg="skin4"] ~ * {
--coop-chrome: #5A6880;
--coop-chrome-dark: #49556B;
--acct-savings: #6D7685;
--acct-share: #976191;
--acct-timedeposit: #517D56;
--acct-loan: #867356;
}
#main-wrapper[data-navbarbg="skin5"] ~ * {
--coop-chrome: #2F323E;
--coop-chrome-dark: #23252E;
--acct-savings: #2F323E;
--acct-share: #1B522C;
--acct-timedeposit: #52471B;
--acct-loan: #521B42;
}
#main-wrapper[data-navbarbg="skin6"] ~ * {
--coop-chrome: #495057;
--coop-chrome-dark: #343A40;
--acct-savings: #747677;
--acct-share: #AC39AC;
--acct-timedeposit: #2C862C;
--acct-loan: #9E6934;
}
/* skin7 absent on purpose -- see the note in the block above. */
/* --- Section and page headers -------------------------------------------
:root IS LOAD-ORDER INSURANCE, AND IT IS NOT OPTIONAL. !important beats the
template's own !important only when the two rules are not otherwise equal. The
template declares
.bg-info{background-color:#2cabe3!important}
at (0,1,0), and this file used to declare the same class at the same (0,1,0)
with the same !important -- so the winner was decided purely by which loaded
last. That is fine on the 200-odd pages where this file is last, and wrong on
the ones where it is not: DashBoard\Support.cshtml (Help & FAQs, both portals)
links Content\style.min.css from the BODY, and the "Frequently Asked Questions"
header and every text-info heading on that page stayed template blue while the
rest of the portal went green. Found 08/24/2026 by looking at the page.
`:root` is a pseudo-class, so `:root .bg-info` is (0,2,0) and wins on merit
wherever it is loaded. Everything in is a descendant of the root
element, so the qualifier excludes nothing. Do not "simplify" it away. */
:root .bg-info {
background-color: #3F6A24 !important;
background-color: var(--coop-chrome) !important;
}
/* --- A menu item being clicked -------------------------------------------
Claude 08/24/2026. The template paints the pressed state of every dropdown
entry in its own blue:
.dropdown-item.active, .dropdown-item:active { background-color: #2cabe3 }
It only shows while the mouse is down, which is why it survived every sweep so
far and was eventually reported from the browser: the profile menu flashed blue
as Sign Out was clicked, on the way out of a portal that is otherwise branded.
:root takes this to (0,3,0) against the template's (0,2,0). The HOVER state is
deliberately left alone -- the template greys it #f7fafc, which is a neutral
"you are over this row" and carries no brand meaning. */
:root .dropdown-item.active,
:root .dropdown-item:active {
color: #ffffff;
background-color: #3F6A24;
background-color: var(--coop-chrome);
}
/* --- Table pagination ----------------------------------------------------
Claude 08/24/2026. Every DataTables grid in the back office, and the member
portal's history and statement tables, ends in a pager. The template paints it
from its own palette and nothing here had claimed it:
.page-link #707cd2 (skin2's indigo)
.page-link:hover #3b4abb
.page-item.active .page-link #2cabe3 (skin1's blue)
.dataTables_wrapper ... .active .page-link #4fc3f7
So the current page sat as a pale blue chip on an otherwise branded page --
reported from the browser on 08/24/2026, alongside a red Create button.
FOUR RULES, NOT ONE, because the template states it four times and the
DataTables sheet re-states the active page at (0,5,0). The :root qualifier
takes the last of those to (0,6,0), so it wins wherever it is loaded -- the
same reason every other rule in this file carries it.
The DISABLED pager buttons are deliberately untouched: they are grey because
they do nothing, and that is not a brand decision. */
:root .page-link {
color: #3F6A24;
color: var(--coop-chrome);
}
:root .page-link:hover {
color: #2E4E1A;
color: var(--coop-chrome-dark);
background-color: #EDF3E7;
background-color: var(--coop-primary-light);
}
:root .page-item.active .page-link,
:root .dataTables_wrapper .dataTables_paginate .page-item.active .page-link {
color: #ffffff;
background-color: #3F6A24;
background-color: var(--coop-chrome);
border-color: #3F6A24;
border-color: var(--coop-chrome);
}
/* --- Headings ------------------------------------------------------------ */
:root .text-info {
color: #3F6A24 !important;
color: var(--coop-chrome) !important;
}
/* --- The generic action button -------------------------------------------
MOVED OUT, 08/24/2026. .btn-info used to be styled here, on its own, because at
the time it was the only button class the theme claimed. Css\coop-theme-buttons.css
now claims it alongside .btn-success and .btn-primary -- one action colour
whichever of the three spellings a view happens to use -- and does it at (0,2,0)
via :not(.btn-circle), which this bare (0,1,0) copy could not match.
Leaving both would mean two files declaring the same button, with the weaker one
able to win on load order somewhere. So the rules live in exactly one file now.
Every layout that links THIS file also links that one; Tier 1 fails the build
otherwise, which is what makes the removal safe. */
/* --- Radios, checkboxes and switches -------------------------------------
Claude 08/24/2026. Reported from the browser: the Workflow radio on
Memberships\WorkFlowSetup stayed the template's blue while the page around it
was the cooperative's colour, and picking another swatch left it blue.
THE COLOUR IS NOT ON THE INPUT. .custom-control-input is opacity:0 with
z-index:-1 -- the circle a person actually sees is the LABEL's ::before, and
the dot inside it is ::after. So a rule aimed at input[type=radio] paints
nothing at all, which is why this survived every sweep of the form controls.
What the template declares, and nothing here had claimed:
.custom-control-input:checked ~ .custom-control-label::before #2cabe3
.custom-control-input:indeterminate ~ ... #2cabe3
.custom-control-input:not(:disabled):active ~ ... #000
.custom-control-input:disabled:checked ~ ... rgba(112,124,210,.5)
It is not one screen. Four views in the back office carry these controls
(CoopSettings\Profile, _SettingControl, Memberships\WorkFlowSetup) and two in
the member portal -- including Shared\_CustomPanel, so the switches in the
customizer itself were blue while offering to repaint the page.
:root IS THE SAME LOAD-ORDER INSURANCE AS EVERY OTHER RULE IN THIS FILE. The
template's rule is (0,3,1); the qualifier takes ours to (0,4,1), so it wins on
merit rather than on which stylesheet a given view happens to link last.
THE ACTIVE STATE IS CLAIMED ON PURPOSE. It shows only while the mouse is down
-- exactly how .dropdown-item:active above went unnoticed for months -- and
the template paints it pure black, which reads as a glitch rather than a
press. The white dot keeps 4.5:1 on every skin's dark variant, so ::after is
left as the template has it.
DISABLED-CHECKED GOES NEUTRAL, NOT BRANDED. The template's translucent indigo
belongs to no palette in this tree. A control that cannot be changed is grey
for the same reason the disabled pager buttons are: it does nothing, and doing
nothing is not a brand statement.
is-valid / is-invalid ARE LEFT ALONE. Green for passed and red for failed is
validation STATUS, and status is not brand -- the same line this file draws
for the account badges. */
:root .custom-control-input:checked ~ .custom-control-label::before,
:root .custom-control-input:indeterminate ~ .custom-control-label::before {
border-color: #3F6A24;
border-color: var(--coop-chrome);
background-color: #3F6A24;
background-color: var(--coop-chrome);
}
:root .custom-control-input:not(:disabled):active ~ .custom-control-label::before {
border-color: #2E4E1A;
border-color: var(--coop-chrome-dark);
background-color: #2E4E1A;
background-color: var(--coop-chrome-dark);
}
:root .custom-control-input:disabled:checked ~ .custom-control-label::before,
:root .custom-control-input:disabled:indeterminate ~ .custom-control-label::before {
border-color: #adb5bd;
background-color: #adb5bd;
}
/* --- The NATIVE checkbox and radio ----------------------------------------
Claude 08/28/2026. Reported from the browser: the permission matrix on
UserRoles\Permissions ticks blue, on a page whose every other colour is the
cooperative's.
THE RULE ABOVE DOES NOT REACH IT. .custom-control-input is a Bootstrap 4
custom control -- the box a person sees is the LABEL's ::before, which is why
that rule paints a ::before and not an input. A bare
has no label art at all: the browser draws it, and it draws it in the UA's own
accent, which is blue in every Chromium build and is not ours to inherit.
Nothing in this tree claimed the bare control, so the 08/24 pass repaired the
control it was reported against and left the other one blue. It is not one
screen: the permission matrix (Views\UserRoles\_RoleForm.cshtml, master, row
and cell boxes alike), the loan evaluation conditions in both portals, the
member's Agree/Disagree pair on PreEvalStage, and the plain Html.CheckBoxFor
on EmailTemplate\Modify, PaymentFee\Modify and _BankAccountRow.
accent-color IS THE WHOLE FIX. It is the one property that repaints a native
control's fill without replacing it with label art -- and replacing it here
would mean touching seven views to add markup the browser already draws.
IE11 has no accent-color and this tree still declares IE=edge, so it keeps the
UA blue: the literal below is the fallback pair's first line by the file's
convention, but no IE build reads either. Every browser this deployment is
actually used in (Edge 93+, Chrome 93+, Firefox 92+, Safari 15.4+) honours it.
DISABLED GOES NEUTRAL, for the same reason the custom control above does. The
matrix renders "Not yet in force" capabilities as disabled ticked boxes, and a
box that cannot be changed must not read as a granted permission in brand
colour. The grey is the same #adb5bd. */
:root input[type="checkbox"],
:root input[type="radio"] {
accent-color: #3F6A24;
accent-color: var(--coop-chrome);
}
:root input[type="checkbox"]:disabled,
:root input[type="radio"]:disabled {
accent-color: #adb5bd;
}
/* --- The account-type legend ---------------------------------------------
Claude 08/24/2026. Phase 7 gave the account cards a brand-coloured family;
Phase 8 made that family follow the cooperative's configured colour instead of
being pinned to the shipped green. The literal in each pair below is the
Phase 7 value and is now the IE11 fallback; the var() beside it is what every
other browser reads, and it is rendered per cooperative by
Views\Shared\_CoopThemeTokens.cshtml from SystemSettings\ThemePalette.cs.
THIS IS A LEGEND, NOT DECORATION. Savings / share capital / time deposit /
loan. It is how a member picks their loan out of six cards, and the same
colour is repeated on that account's History page, so a member who clicks a
plum card lands on a plum page. Four colours in, four colours out, whatever
the brand is.
THE FAMILY. All four are mid-dark and muted so they read as one system, and
all four clear WCAG AA (4.5:1) under the white label they carry -- which three
of the template's originals did not, badly: bg-warning #ffc36d was 1.58:1
under text-white, bg-success #2cd07e 2.01:1 and bg-danger #ff5050 3.22:1. The
white label on a Time Deposit card was for practical purposes invisible.
The four are DERIVED, so this file deliberately does not name them: they
follow the cooperative's configured colour, and what is fixed is the
guarantees rather than the values. ThemePaletteContractTests holds all of them
across a sweep of every hue at three saturations -- four DISTINCT colours,
each at 4.5:1 or better under its white label, the loan card never in the
green sector, and no two closer than dE 20 (CIE76). The literals below are the
hand-picked Phase 7 four, which are what IE11 keeps.
For scale: on the shipped green the closest pair sits at dE 56, and the
template's four that were replaced sat at 60. So this is NOT a
distinguishability improvement and is not claimed as one -- both are far above
the ~20 at which two fills stop being told apart. What changed is that all
four now carry a readable label and follow the cooperative.
COLOUR IS NEVER THE ONLY CUE, AND THAT IS LOAD-BEARING. Under deuteranopia and
protanopia the closest pair can fall to dE 1 at some brand colours, and no
derivation fixes it: every fixed hue-offset triple on a 30-degree grid was
measured and the best worst case is dE 1.3, because for a dichromat the hue
circle collapses to one axis. A lightness ladder does not rescue it either --
WCAG contrast is defined on normal-vision luminance, and CVD re-weights
luminance.
WHAT DISCHARGES 1.4.1 IS THE WORDS, and they were already there. Every card
header on Transaction\Index states its type inside the coloured element
("Savings Account", "Non-Savings Account", "Time Deposit Account", "Loan
Account"), and every History page states it in its own heading -- "Savings
Account History", "Non-Savings History", "Time Deposit Account History", "Loan
Account History" -- with the product name on the coloured hero card besides. A
Tier 1 guard checks that each view painting a legend colour still names the
matching type in words. A letter-in-a-ring mark was added on 08/24/2026 and
REMOVED the same day as visual noise; that was safe only because the wording
above carries the requirement on its own. Do not rename a heading out of that
vocabulary without putting a non-colour cue back.
THE LEGEND FOLLOWS THE SKIN TOO, since 08/24/2026, and the six skin blocks at
the head of this file are where. This REVERSES what stood here for a day, so
the reasoning matters more than the rule:
THE ORIGINAL OBJECTION WAS TO FOLLOWING --coop-chrome, AND IT WAS RIGHT.
--coop-chrome on skin1 is #1A6E8C, which is the share-capital teal exactly:
a legend pointed at the chrome variable would render two account types
identical the moment anyone picked that swatch. That is still true and this
file still never does it.
WHAT MAKES FOLLOWING SAFE IS DERIVING, NOT POINTING. Each skin block carries
its own FOUR values, produced by running ThemePalette's derivation over that
skin's colour -- the same rotate-and-darken that produces the cooperative's
four. Because the four rotate together, two of them cannot collide on any
skin, and each one still clears 4.5:1 under its white label. The six skins
are covered by name in ThemePaletteContractTests' spread, so the guarantees
are checked for them and not merely assumed.
THE COST, STATED PLAINLY. The skin is PER BROWSER --
Scripts\dashboard\coop-theme-memory.js keeps it in localStorage -- so two
members of one cooperative who pick different swatches will describe the
same loan card as different colours. That is accepted: it was raised, and
the answer was that a legend which ignores the theme reads as broken, which
is the report that started this. The type mark is what keeps the card
identifiable regardless.
THE VALUES ARE LITERALS ON PURPOSE. They are not var() reads of anything, so
the existing guard "no skin1-6 rule reads a coop token" is untroubled: the
template's six skins are fixed colours that mean nothing but themselves, and
their legends are fixed with them. Only skin7 -- the cooperative's own colour
-- falls through to :root, where _CoopThemeTokens.cshtml renders it. Adding a
skin7 block here would break that exactly as it broke --coop-chrome; see the
note beside the skin blocks.
REGENERATE, DO NOT HAND-EDIT. If ThemePalette's derivation changes, these
twenty-four literals are stale and nothing will say so. Re-run the derivation
over the six skin colours (#2CABE3 #707CD2 #FF7676 #A0AEC4 #2F323E #E9ECEF)
and paste the results back.
!important IS LOAD-BEARING ON THE BORDERS. Views\Transaction\Index.cshtml keeps
Bootstrap's `border` utility beside the type class, and that utility is the
shorthand `border:1px solid #e9ecef!important`, which sets border-color too. A
plain border-color loses to it however late this file loads. The two class
selectors take these to (0,2,0), so they beat it on specificity as well. The
backgrounds carry it for the table head rows, which sit inside tables whose
striping rules are (0,2,1).
IE11 KEEPS THE LITERALS and therefore keeps the shipped green family rather
than the configured one -- the same accepted trade as every other fallback
pair in this file. Do not tidy the first line of a pair away. */
.card.acct-card-savings {
border-color: #3F6A24 !important;
border-color: var(--acct-savings) !important;
}
.card.acct-card-share {
border-color: #1A6E8C !important;
border-color: var(--acct-share) !important;
}
.card.acct-card-timedeposit {
border-color: #B85D01 !important;
border-color: var(--acct-timedeposit) !important;
}
.card.acct-card-loan {
border-color: #8E3A6B !important;
border-color: var(--acct-loan) !important;
}
.card.acct-card-savings > .card-header,
.card.acct-fill-savings,
tr.acct-fill-savings {
background-color: #3F6A24 !important;
background-color: var(--acct-savings) !important;
}
.card.acct-card-share > .card-header,
.card.acct-fill-share,
tr.acct-fill-share {
background-color: #1A6E8C !important;
background-color: var(--acct-share) !important;
}
.card.acct-card-timedeposit > .card-header,
.card.acct-fill-timedeposit,
tr.acct-fill-timedeposit {
background-color: #B85D01 !important;
background-color: var(--acct-timedeposit) !important;
}
.card.acct-card-loan > .card-header,
.card.acct-fill-loan,
tr.acct-fill-loan {
background-color: #8E3A6B !important;
background-color: var(--acct-loan) !important;
}
/* The header sits directly on the card's top corners; the template rounds the
card and leaves the header square, which showed as a white sliver at each top
corner once the header was a solid fill. */
.card.acct-card-savings > .card-header,
.card.acct-card-share > .card-header,
.card.acct-card-timedeposit > .card-header,
.card.acct-card-loan > .card-header {
border-bottom: 0;
border-top-left-radius: inherit;
border-top-right-radius: inherit;
}
/* Leo B. 09/03/2026. The account cards on Views\Transaction\Index.cshtml are
titled with the product description now, not with a fixed account-type word.
"DEPOSIT FOR SHARE CAPITAL SUBSCRIPTION" is 37 characters and the cards are
col-lg-3, so the header has to wrap -- .card-header does not wrap on its own
in this template, and an unwrapped title pushed the card wider than its
column.
min-height rather than a fixed height: a two-line title and a one-line title
sitting side by side gave the row ragged card tops. 3.5rem is two lines at
1.25 line-height plus the template's .75rem of vertical padding. It is a
floor, so a three-line title on a phone still grows the header instead of
spilling out of it.
No flexbox here. Vertical centring is not needed, and IE11 mis-measures
min-height on a flex container -- the same reason the rest of this file
stays on plain box rules. */
.card > .card-header.acct-title {
min-height: 3.5rem;
line-height: 1.25;
white-space: normal;
word-wrap: break-word;
overflow-wrap: break-word;
}
/* Leo B. 09/04/2026. Two readability fixes on the account cards of
Views\Transaction\Index.cshtml, reported off the member's account list.
.acct-no -- the account number sat in a bare h6, and this template sets h6 to
.75rem. 12px is the smallest text on the page and it is carrying the one
string a member reads back to a teller. .9375rem is 15px: bigger than the
body text around it, still under the 1.3125rem balance, so the card's
hierarchy is where it was. A class rather than a heading level, because h5
would bring the template's weight and margins with it.
.acct-amount -- the balance is a right float (.pull-right) and NOTHING
CLEARED IT, so the button sat in the float's shadow with no gap under Php.
The wrapper contains the float with the ::after form and owns the space
below, which is why the view no longer needs the that stood in for it.
Putting margin-bottom on the button instead does not work: an uncleared
button is beside the float, not under it, and the margin lands in the wrong
place. IE11 has ::after and display:table, so this needs no flexbox -- see
the note on .acct-title above for why this file stays on plain box rules.
Both are (0,2,0), which beats the element rules in
Content\Dashboard\style.min.css; that sheet loads before this one. */
.card-body .acct-no {
font-size: .9375rem;
line-height: 1.35;
word-wrap: break-word;
overflow-wrap: break-word;
}
.card-body .acct-amount {
margin-bottom: 1rem;
}
.card-body .acct-amount::after {
content: "";
display: table;
clear: both;
}
/* Leo B. 09/14/2026. The sentence under a card heading -- .card-subtitle, 39
uses across 35 back-office views and 4 in the member tree.
THE SAME DEFECT AS .acct-no ABOVE, one level up. Every one of them is written
, and Content\Dashboard\style.min.css sets
h6{font-size:.75rem}: 12px, smaller than the body text it introduces. On top
of that the template gives the class font-weight:300 and color:#8898aa, which
is 2.9:1 on white -- below the 4.5:1 small text needs. So the one sentence
explaining what a page wants from the reader was the least legible thing on
it, on both portals.
COLOR:INHERIT, NOT A NEW GREY. #313131 is the body colour these cards already
carry, and it is 13.0:1. Picking some intermediate neutral instead would put
a colour in the theme that nothing else uses and that the next cooperative
would have to be given a value for -- the argument the "Settled" pill below
makes at more length. The subtitle recedes by SIZE, sitting under the card
heading, rather than by being washed out.
A RULE HERE RATHER THAN 39 EDITS. Retyping the element in every view is churn
with 39 chances to miss one, and the two portals would drift the moment
somebody added the fortieth. This is also why it is not scoped to the loan
pages that prompted it: the defect is the template's, and it is the same on
every card in both trees.
.card-subtitle text-muted STILL WINS -- .text-muted is #8898aa !important, so
the two CoopSettings hints that ask for muted stay muted. That is an explicit
request in the view and is left alone.
(0,2,0) against the template's (0,1,0), the convention throughout this file;
load order is not relied on. See the note further up on the Help & FAQs page
for why. */
:root .card-subtitle {
font-size: .875rem;
font-weight: 400;
color: inherit;
}
/* Leo B. 09/04/2026. The "Settled" marker on a repaid loan card,
Views\Transaction\Index.cshtml.
A WORD, NOT A COLOUR. The four account-type colours are as close as dE 1.3 for
a dichromat, so a card told apart from its neighbours by shade alone is not
told apart at all -- and whether a loan is repaid is the one thing about the
card that nothing else on it says. The balance reads 0.00 either way.
White fill with the card's OWN colour as the text, rather than a new swatch.
Nothing is added to the palette here, which is what keeps white-labelling the
next cooperative a one-file change. #8E3A6B on #ffffff is 7.1:1, so the badge
carries small text comfortably -- which is why it is this way round and not
the reverse, where the same pair would be a fill behind white text at the
same ratio but a far smaller target.
NOT NAMED acct-SOMETHING, deliberately. Every acct- class in this file carries
one of the four account-type colours, and Tier 1 holds them to a literal-then-
var(--acct-*) fallback pair. This badge is white on every card and takes its
text colour FROM the card, so it is not a legend colour and giving it an
--acct- token to satisfy that rule would have made the stylesheet say something
untrue. The name is what keeps the two apart.
The hex before each var() is the IE11 fallback this file uses throughout, and
the rules stay plain boxes -- no flexbox -- for the reason given on
.acct-title above. */
.card > .card-header .coop-pill {
display: inline-block;
margin-left: .375rem;
padding: .0625rem .375rem;
border-radius: .625rem;
background-color: #ffffff;
font-size: .6875rem;
font-weight: 600;
line-height: 1.4;
letter-spacing: .02em;
text-transform: uppercase;
vertical-align: middle;
white-space: nowrap;
}
.card.acct-card-loan > .card-header .coop-pill {
color: #8E3A6B;
color: var(--acct-loan);
}
/* .card-body > .acct-type stood here from 09/03/2026 to 09/04/2026 and styled
the account type in words on each card of Views\Transaction\Index. The
cooperative asked for that line to go, so the rule has no subject left; see
the note in that view for what the removal costs and what would restore it.
Leo B. 09/04/2026. */
/* --- Chrome this file had not claimed yet --------------------------------
Claude 08/26/2026. Reported from the back-office Roles & Permissions screen
as "the page does not follow the theme". Four surfaces, none of them specific
to that page:
.page-breadcrumb .breadcrumb .active #2cabe3 the current crumb
.nav-tabs .nav-link.active #525f7f the module tab strip
(no rule at all) a chip stating a count
(no rule at all) an action link on a card
The first two are template colours that nothing here had overridden -- the
crumb in particular is the template blue on a green portal, on EVERY back
office page, since the breadcrumb partial is in every one of them. The last
two are absences rather than wrong colours.
All four are CHROME: they say where you are and what to click, not whether
something passed or failed. So they follow --coop-chrome like the rest of this
file, and repaint the instant a swatch is picked in the customizer.
WHAT IS DELIBERATELY NOT CLAIMED HERE:
.badge-secondary UserAccessSetup\Edit renders it as the INACTIVE half of
an active/inactive pair. Grey is the correct answer
there, so the count chip on a role card asks for
.badge-coop by name instead of this file recolouring
every neutral badge in both portals.
.badge-danger "No permissions yet", and the Delete action beside it,
are status and danger. Status is not brand -- see the
note at the top of Css\coop-theme.css.
the muted crumbs .page-breadcrumb ... .breadcrumb-item > a stays #8898aa.
A breadcrumb trail is meant to recede; only the page you
are ON is worth marking. */
/* The current crumb. (0,4,0) against the template .page-breadcrumb .breadcrumb
.active at (0,3,0). */
:root .page-breadcrumb .breadcrumb .active {
color: #2E4E1A;
color: var(--coop-chrome-dark);
}
/* The module tab strip -- Views\Shared\_ModuleTabs.cshtml, and the four other
.nav-tabs strips in the two trees (Logs\_LogTabs, LoanApplications\Index,
Memberships\Index, member Membership\Membertype).
A MARKER, NOT A FILL. The template gives the active tab a white background and
a border open at the bottom, so it reads as joined to the panel below it;
flooding it with chrome would break that and make the strip shout louder than
the page. An inset top edge marks it in brand colour and costs no layout:
box-shadow does not participate in the box model, so the tab does not move by
the 2px a thicker border-top would have cost it.
(0,3,0) against the template (0,2,0). IE9+ supports inset box-shadow; IE11
takes the literal in each pair, as everywhere else in this file. */
:root .nav-tabs .nav-link.active,
:root .nav-tabs .nav-item.show .nav-link {
color: #2E4E1A;
color: var(--coop-chrome-dark);
box-shadow: inset 0 3px 0 #3F6A24;
box-shadow: inset 0 3px 0 var(--coop-chrome);
}
:root .nav-tabs .nav-link:hover,
:root .nav-tabs .nav-link:focus {
color: #2E4E1A;
color: var(--coop-chrome-dark);
}
/* --- Two utilities, so a view can ask for the theme by name ---------------
Both read the same variable as everything above, so a page using them follows
the navbar swatch with no work of its own.
.text-coop uses the DARK pair and .badge-coop the plain one, which is the
contrast rule at the top of Css\coop-theme.css applied: --coop-chrome carries
white text on a fill, --coop-chrome-dark carries small text on white. Using
them the other way round is how a 3.6:1 link ends up in body copy.
:root takes .text-coop to (0,2,0), so it beats the template a { color:#8898aa }
wherever this file happens to be linked. See the note further up about the
Help & FAQs page for why load order is not relied on here. */
:root .text-coop {
color: #2E4E1A;
color: var(--coop-chrome-dark);
}
:root a.text-coop:hover,
:root a.text-coop:focus {
color: #2E4E1A;
color: var(--coop-chrome-dark);
text-decoration: underline;
}
:root .badge-coop {
color: #ffffff;
background-color: #3F6A24;
background-color: var(--coop-chrome);
}
/* --- The jQuery Steps wizard's step circles -------------------------------
Leo B. 09/04/2026.
The vendored steps.css paints the wizard's circles, connectors and labels
with a hardcoded #2962FF -- the Monster Admin template's blue, twelve times.
Nothing in the theme had ever claimed them, so the loan application wizard
drew blue circles under a card header that follows the swatch, and the two
membership wizards drew blue under the cooperative's own colour.
Css\coop-theme-buttons.css already claimed the Next and Finish buttons in the
same widget; only the steps themselves were left behind.
ONE VENDOR FILE, TWO PATHS. Css\sc\steps.css and
assets\libs\jquery-steps\steps.css are byte-identical and carry identical
selectors, so these rules reach all three consuming views:
LoanApplications\Create.cshtml assets\libs\... _LayoutDashboard
Membership\Index.cshtml Css\sc\... _PortalLayout
Membership\PreSeminar.cshtml Css\sc\... _PortalLayout
Both layouts link this file, so --coop-chrome always resolves. Under
_PortalLayout there is no #main-wrapper and so no skin, and it lands on the
:root value -- the cooperative's colour, which is what an applicant should
see.
WHY :root, AND WHY IT IS NOT DECORATION. steps.css is linked from the BODY of
those views, so it loads AFTER this file and wins any contest of equal
specificity. The vendor's circle rules are (0,5,2); :root lifts these to
(0,6,2), which wins on specificity regardless of order. Same trick, same
reason, as the wizard button rules in Css\coop-theme-buttons.css -- see the
note above them. Removing a :root here does not make the rule "cleaner", it
makes it stop applying.
DO NOT FIX THIS BY EDITING steps.css. It is vendored template CSS, in two
copies; overriding it from the theme is how every other template colour in
this tree is handled.
NO !important IS NEEDED HERE, AND THAT IS WORTH KNOWING RATHER THAN
REDISCOVERING. Content\Dashboard\style.min.css does declare
border-color:#007bff!important on the current step, which would beat every
rule below on importance rather than specificity -- but it is qualified with
body[data-theme=dark], and nothing in this portal ever sets that attribute.
If dark mode is ever switched on, these rules lose the current circle's ring
and only then need !important beside the :root.
PENDING IS NEUTRAL and matches Css\loan-progress.css exactly, so the portal's
two steppers read as one component: #e9ecef ring and track, #495057 numeral,
#6c757d label. The vendor had #F3F3F3 and #999, and #999 on white is 2.85:1 --
so both the done and the pending labels were failing 4.5:1 before this.
.error keeps the vendor's #f62d51: a failed validation is a status, not
chrome, and it does not follow a swatch. */
/* Reached: the filled circle. The numeral is a LITERAL #ffffff, not
--coop-primary-contrast -- that token is black for a cooperative with a light
brand colour, and chrome is dark by construction. */
:root .wizard-content .wizard > .steps > ul > li.done .step {
color: #ffffff;
background-color: #3F6A24;
background-color: var(--coop-chrome);
border-color: #3F6A24;
border-color: var(--coop-chrome);
}
/* Current: an outlined circle. --coop-chrome is 5.6:1 or better on white for
every one of the seven skins, so the numeral needs no darker pair. */
:root .wizard-content .wizard > .steps > ul > li.current .step {
background-color: #ffffff;
color: #3F6A24;
color: var(--coop-chrome);
border-color: #3F6A24;
border-color: var(--coop-chrome);
}
/* Pending: the circle nobody has reached yet, and the numeral inside it.
#6c757d would be 3.88:1 on this ground and fail; #495057 is 6.9:1. */
:root .wizard-content .wizard.wizard-circle > .steps .step {
border: 3px solid #e9ecef;
}
:root .wizard-content .wizard > .steps > ul > li.disabled .step {
color: #495057;
}
/* The connector. The vendor fills every one and then repaints the run from the
current step onward, so both halves have to be claimed or the line ahead of
the member stays blue. */
:root .wizard-content .wizard.wizard-circle > .steps > ul > li:after,
:root .wizard-content .wizard.wizard-circle > .steps > ul > li:before {
background-color: #3F6A24;
background-color: var(--coop-chrome);
}
:root .wizard-content .wizard.wizard-circle > .steps > ul > li.current:after,
:root .wizard-content .wizard.wizard-circle > .steps > ul > li.current ~ li:after,
:root .wizard-content .wizard.wizard-circle > .steps > ul > li.current ~ li:before {
background-color: #e9ecef;
}
/* The labels beneath the circles. See the note above on #999. */
:root .wizard-content .wizard > .steps > ul > li.done a,
:root .wizard-content .wizard > .steps > ul > li.done a:focus,
:root .wizard-content .wizard > .steps > ul > li.done a:hover,
:root .wizard-content .wizard > .steps > ul > li.current > a {
color: #3F6A24;
color: var(--coop-chrome);
}
:root .wizard-content .wizard > .steps > ul > li.disabled a,
:root .wizard-content .wizard > .steps > ul > li.disabled a:focus,
:root .wizard-content .wizard > .steps > ul > li.disabled a:hover {
color: #6c757d;
}