/* ============================================================================ COOP THEME -- BUTTONS. One action colour, everywhere, in both portals. JJE/Claude 08/23/2026. Phase 1 of docs\coop-theme\PLAN.md. WHAT THIS CLAIMS. Every button that means "do the thing" now paints from --coop-chrome, whichever Bootstrap class it happens to carry: .btn-success 58x admin, 53x member Save, Update, Approve, Continue .btn-info 48x admin, 15x member Search, Back, Activate .btn-primary 5x admin, 69x member Send, Browse, Calculate Three classes for one role is not a design; it is what forty views written by different hands over ten years look like. Nothing distinguishes them -- the same Update button is btn-success on Memberships\Review and btn-info two rows down -- so rather than reclass 248 call sites, all three resolve here. WHAT THIS DOES NOT CLAIM, and why each is deliberate: .btn-danger and .btn-warning are UNTOUCHED. They are the only two colour classes in this tree that still carry meaning: danger is refuse/delete/decline, warning is a caution. A destructive action that follows the brand hue is a safety problem, not a theming win -- on the red skin, Approve and Decline would be the same colour. Phase 3 of the plan may derive a warning tone from the brand; it should not derive danger. .btn-circle is EXCLUDED by :not() on every rule. It is not a button. It is the round icon behind a dashboard statistic -- DashBoard\Index.cshtml:135 (admin) and :74 (member, where it is a ) -- and they are colour-coded per statistic in the same way the account-type cards are. Painting them one colour would delete the distinction. The ACCOUNT-TYPE LEGEND (savings / share capital / time deposit / loan, on Transaction\Index and the five History pages) is a bg- family and is not reachable from this file at all. Said here anyway because it is the first thing anyone assumes this broke. It is claimed by Css\coop-theme-content.css as of 08/24/2026 -- four brand-family colours rather than the template's four -- and it deliberately does NOT follow the skin, for the reason recorded there. One button moved with it: the Time Deposit card's View Details was btn-warning, the one action class this file excludes, so it stayed yellow in a row of green ones. It is btn-success now. The exclusion below is about DESTRUCTIVE actions, and a View Details link is not one. FIVE BUTTON SYSTEMS, NOT ONE. Bootstrap is only where most of them live. The member portal also ships: .button / .button.active Css\style.css:1092, hardcoded #222 .button-online-PMES Css\TempStyleSheet.css:663, #222 again .btn-primary-pill / -outline Css\Login.css:113, hardcoded #0c447c .wizard > .actions > ul > li a Css\sc\steps.css:178, hardcoded #2962FF .fileUpload.btn-primary 17 file pickers across both portals All five are re-pointed below. A theme that reaches four of the five leaves a navy or charcoal button next to a green one and reads as a bug, not a theme. THAT COUNT WAS FOUR UNTIL 08/24/2026, AND THE MISSING ONE WAS THE WHOLE LIVE MEMBERSHIP FLOW. Each system was found the same way -- somebody looked at a rendered page -- and never by the test suite, because a stylesheet cannot be checked for what it forgot to mention. That is what the two Tier 1 coverage guards are for now: one fails on a button class used in a view that no rule here claims, the other on a rule weak enough to lose to a body-linked sheet. Add a sixth system and the build fails before anyone has to notice by eye. SPECIFICITY, AND THE ONE PLACE LOAD ORDER IS NOT ENOUGH. :not() raises specificity, so `.btn-success:not(.btn-circle)` is (0,2,0) against Bootstrap's (0,1,0) and wins on merit rather than on being loaded late. That matters here: 74 views in this tree link a stylesheet from the BODY, which is after every layout , so "this file is linked last" is simply not true on those pages. The wizard is the case where it bites. Views\Membership\Index.cshtml links Css\sc\steps.css at line 20 -- in the body -- and that file's rule .wizard-content .wizard>.actions>ul>li>a (0,3,3) would beat an identical selector here on document order. So the rule below targets a[href="#next"] and a[href="#finish"] instead, at (0,4,3). It wins regardless of order, and it excludes a[href="#previous"] for free, which is what we wanted anyway -- Previous stays the white secondary it already is. jquery.steps.min.js emits exactly those three hrefs and no others. Two views go further and body-link a WHOLE Bootstrap/template sheet, which redefines all 48 btn- rules: DashBoard\Support.cshtml (both trees, pulling Content\style.min.css) and Home\LoanCalc.cshtml (member, Css\bootstrap.min.css). Those links are LEFT IN PLACE. Every btn- rule in both sheets is a bare single-class selector at (0,1,0) with no !important, so the :not() form below outranks them and the pages theme correctly with the extra sheet still loading after this one. That is the point of doing it with specificity instead of load order. Do not "tidy" either link away on the assumption it is a duplicate of what the layout already loads. It is not: Content\style.min.css and the layout's Content\Dashboard\style.min.css are different files with different hashes, and the Support page's FAQ accordion is styled by the copy the view links. IE11 has no var(), so every declaration is a FALLBACK PAIR -- literal first, var() second. IE11 keeps the literal and gets the coop green everywhere: correct, just not skin-aware. Do not tidy the first line of a pair away. --coop-chrome comes from Css\coop-theme-content.css, which must therefore load BEFORE this file. It follows the navbar skin on dashboard pages and falls back to the coop green on the login and membership pages, which never load the admin template. Nothing here re-declares it. This file exists twice, in Merge-All\MemberPortal\Css\ and in AdminPortal\MemberPortal\Css\, and the two copies are BYTE-IDENTICAL. It is in tests\baselines\twin-files.txt -- change one, change both. ============================================================================ */ /* --- The action button, all three spellings of it ------------------------ */ .btn-success:not(.btn-circle), .btn-info:not(.btn-circle), .btn-primary:not(.btn-circle) { color: #ffffff; background-color: #3F6A24; background-color: var(--coop-chrome); border-color: #3F6A24; border-color: var(--coop-chrome); } .btn-success:not(.btn-circle):hover, .btn-success:not(.btn-circle):focus, .btn-success:not(.btn-circle).focus, .btn-success:not(.btn-circle):active, .btn-success:not(.btn-circle).active, .btn-success:not(.btn-circle):not(:disabled):not(.disabled):active, .btn-info:not(.btn-circle):hover, .btn-info:not(.btn-circle):focus, .btn-info:not(.btn-circle).focus, .btn-info:not(.btn-circle):active, .btn-info:not(.btn-circle).active, .btn-info:not(.btn-circle):not(:disabled):not(.disabled):active, .btn-primary:not(.btn-circle):hover, .btn-primary:not(.btn-circle):focus, .btn-primary:not(.btn-circle).focus, .btn-primary:not(.btn-circle):active, .btn-primary:not(.btn-circle).active, .btn-primary:not(.btn-circle):not(:disabled):not(.disabled):active { color: #ffffff; background-color: #2E4E1A; background-color: var(--coop-chrome-dark); border-color: #2E4E1A; border-color: var(--coop-chrome-dark); } /* --- Disabled --------------------------------------------------------------- Needed explicitly. Both template sheets declare .btn-success.disabled at (0,2,0), which ties with the base rule above and would win on load order on the pages that body-link them -- a disabled button would sit there in the template's green while its enabled neighbour is coop green. The dimming stays the template's job: .btn:disabled{opacity:.65} still applies on top. */ .btn-success:not(.btn-circle).disabled, .btn-success:not(.btn-circle):disabled, .btn-info:not(.btn-circle).disabled, .btn-info:not(.btn-circle):disabled, .btn-primary:not(.btn-circle).disabled, .btn-primary:not(.btn-circle):disabled { color: #ffffff; background-color: #3F6A24; background-color: var(--coop-chrome); border-color: #3F6A24; border-color: var(--coop-chrome); } /* --- The outline variants of the same role ------------------------------- Bootstrap 4 only; Bootstrap 3 has no outline family, so the member portal's Bootstrap 3 pages simply do not match these selectors. */ .btn-outline-success:not(.btn-circle), .btn-outline-info:not(.btn-circle), .btn-outline-primary:not(.btn-circle) { color: #3F6A24; color: var(--coop-chrome); background-color: transparent; border-color: #3F6A24; border-color: var(--coop-chrome); } .btn-outline-success:not(.btn-circle):hover, .btn-outline-success:not(.btn-circle):focus, .btn-outline-success:not(.btn-circle):not(:disabled):not(.disabled):active, .btn-outline-info:not(.btn-circle):hover, .btn-outline-info:not(.btn-circle):focus, .btn-outline-info:not(.btn-circle):not(:disabled):not(.disabled):active, .btn-outline-primary:not(.btn-circle):hover, .btn-outline-primary:not(.btn-circle):focus, .btn-outline-primary:not(.btn-circle):not(:disabled):not(.disabled):active { color: #ffffff; background-color: #3F6A24; background-color: var(--coop-chrome); border-color: #3F6A24; border-color: var(--coop-chrome); } /* --- A button that is really a link --------------------------------------- Used for the FAQ accordion toggles and a handful of in-table actions. The template leaves these the Bootstrap blue, which is the one remaining blue on an otherwise green page. */ .btn-link:not(.btn-circle) { color: #3F6A24; color: var(--coop-chrome); } .btn-link:not(.btn-circle):hover, .btn-link:not(.btn-circle):focus { color: #2E4E1A; color: var(--coop-chrome-dark); } /* --- The file picker ------------------------------------------------------- .fileUpload is a div dressed as a button: an input-group-addon with a hidden file input inside it. Scoped to .fileUpload rather than restyling every input-group-addon, because the plain addons are field decoration -- a peso sign, a calendar icon -- and are not actions at all. */ .fileUpload.btn-primary, .fileUpload.input-group-addon { color: #ffffff; background-color: #3F6A24; background-color: var(--coop-chrome); border-color: #3F6A24; border-color: var(--coop-chrome); } /* --- The membership wizard Next and Finish -------------------------------- See the note on specificity above: this is (0,4,3) on purpose, because Css\sc\steps.css is linked from the BODY of Membership\Index.cshtml and would otherwise win on document order. Previous is deliberately not matched. */ .wizard-content .wizard > .actions > ul > li > a[href="#next"], .wizard-content .wizard > .actions > ul > li > a[href="#finish"] { background: #3F6A24; background: var(--coop-chrome); color: #ffffff; } /* --- The membership flow's own two button classes ------------------------- TWO classes, not one, and missing the second is what made this file's first version look correct and ship broken. .button Css\style.css:1092, charcoal #222 .button-online-PMES Css\TempStyleSheet.css:663, charcoal #222 again, plus border-radius:50px and its own sizing WHY BOTH EXIST. The membership flow ships in TWO variants and an administrator picks between them with Session["WorkFlowSetup"]. Workflows 1 and 2 render MembershipStatus / ViewStatus / PMES, which use .button alone. Workflow 3 renders the TempMembershipStatus / TempViewStatus / TempPMES / TempMembershipApplication / TempPayment / TempUpload / TempUploadNotification twins, which add .button-online-PMES -- and four of those seven do not carry .button at all, so there is nothing for a .button rule to attach to. THIS DEPLOYMENT IS ON WORKFLOW 3. The first version of this file themed only .button, was verified against MembershipStatus.cshtml, and passed -- while every page a member actually sees stayed charcoal. Verifying the variant that is not running proves nothing. Two guards in Tier 1 now cover the gap: one fails on a button class no rule here claims, the other on a rule that could lose to a body-linked sheet. :root RATHER THAN A BARE CLASS. Every Temp* view links TempStyleSheet.css from the BODY, after this file. A bare .button here is (0,1,0) and .button-online-PMES there is also (0,1,0), so the later one wins and the button stays charcoal -- which is exactly the bug. :root is a pseudo-class, so `:root .button` is (0,2,0) and settles it on specificity instead of order. Everything in is a descendant of the root element, so nothing is excluded by it. THE ACTIVE STATE IS DECLARED HERE, NOT INHERITED. style.css puts .button.active on the accent orange at (0,2,0) -- the call to action, so the pair reads secondary-then-primary. Now that the resting state is also (0,2,0) and loads later, that orange would lose and every button would come out green. So the orange is restated below at (0,3,0). Deleting these two rules does not restore the old behaviour; it flattens the distinction. NOTE FOR WHOEVER TOUCHES THE VIEWS NEXT: TempMembershipApplication and TempPMES mark no primary at all -- both their buttons are plain .button-online-PMES -- so both come out green. Giving the Next input an `active` class would make those two pages match the rest of the flow. That is a view change and is deliberately not done here. */ :root .button, :root .button-online-PMES { background: #3F6A24 none repeat scroll 0 0; background: var(--coop-chrome) none repeat scroll 0 0; border: 1px solid #3F6A24; border: 1px solid var(--coop-chrome); color: #ffffff; } :root .button:hover, :root .button-online-PMES:hover { background: #2E4E1A none repeat scroll 0 0; background: var(--coop-chrome-dark) none repeat scroll 0 0; border-color: #2E4E1A; border-color: var(--coop-chrome-dark); color: #ffffff; } :root .button.active, :root .button-online-PMES.active { background: #F17B02 none repeat scroll 0 0; background: var(--coop-accent) none repeat scroll 0 0; border: 1px solid #F17B02; border: 1px solid var(--coop-accent); color: #ffffff; } :root .button.active:hover, :root .button-online-PMES.active:hover { background: #B85D01 none repeat scroll 0 0; background: var(--coop-accent-dark) none repeat scroll 0 0; border-color: #B85D01; border-color: var(--coop-accent-dark); color: #ffffff; } /* --- The membership card pills -------------------------------------------- Css\Login.css:113 hardcodes #0c447c, which is not a template default -- it is another cooperative's navy, left behind by an earlier onboarding. The card is the way into the membership flow, so a navy button in front of a green flow is the first thing a member sees. The two classes were BYTE-IDENTICAL there, so "outline" was a filled button with a different name. Given a real outline here, which is what the two variants are for: the card offers a primary and a secondary action. EACH RULE IS WRITTEN TWICE, BARE AND `a.`-QUALIFIED. Login.css declares these classes at (0,1,0) -- exactly what a bare rule here would be -- so the winner would be decided by load order. In _LoginLayout this file happens to come after Login.css and would win; but Views\Shared\_Register.cshtml links Login.css from the BODY, and on any page rendering that partial the pills would silently revert to the navy. Every pill in this tree is an (_MembershipCard, Message, VerifyAccount, ChangeAcctPassword), so the `a.`-qualified rule is (0,1,1) and settles it on specificity like everything else in this file. The bare rule is kept for a non-anchor that may appear later. Caught by rendering the page, not by the suite. */ .btn-primary-pill, a.btn-primary-pill { background-color: #3F6A24; background-color: var(--coop-chrome); color: #ffffff; border: 1px solid #3F6A24; border: 1px solid var(--coop-chrome); } .btn-primary-pill:hover, a.btn-primary-pill:hover { background-color: #2E4E1A; background-color: var(--coop-chrome-dark); color: #ffffff; } .btn-outline-pill, a.btn-outline-pill { background-color: transparent; color: #3F6A24; color: var(--coop-chrome); border: 1px solid #3F6A24; border: 1px solid var(--coop-chrome); } .btn-outline-pill:hover, a.btn-outline-pill:hover { background-color: #3F6A24; background-color: var(--coop-chrome); color: #ffffff; } /* The non-anchor the comment above anticipated. Leo B. 09/11/2026. Views\MemberAccount\Message.cshtml renders a POSTING action as a small form with a