/* ============================================================================
   THE PRIVACY NOTICE. One appearance, wherever it is shown.

   Leo B. 09/04/2026.

   Views\Shared\_PrivacyNotice.cshtml is included in two places -- the Sign Up
   modal on MemberAccount\Login.cshtml and the consent dialog at
   Membership\DataPrivacy.cshtml -- and until now the same partial rendered as
   two visibly different documents. Not because anything styled it: because the
   two layouts put different base sheets underneath it.

       _LoginLayout   Bootstrap 4 (Css\Test\style.min.css). Body text #313131 at
                      .875rem; <ul> keeps the browser's disc markers.

       _PortalLayout  Bootstrap 3 twice over, plus Css\style.css -- the public
                      marketing template. That file carries

                          li { list-style: none }        style.css:95
                          ul { margin: 0; padding: 0 }   style.css:90
                          p  { color: #7e7e7e; font-size: 15px }   style.css:99

                      so on the membership side the six purposes lost their
                      bullet markers AND their indent, and the whole notice was
                      set in mid-grey.

   That is the wrong way round for a consent form. The membership page is where
   an applicant actually reads it before agreeing, and it was the harder of the
   two to read: an unmarked, unindented list reads as prose that has been broken
   oddly, and #7e7e7e on white is 4.0:1 -- under AA for the body text it is being
   used for. The sign-up modal was already right, so it is the target.

   WHY A FILE AND A WRAPPER CLASS rather than a few rules in each caller. The
   partial exists at all because the notice text had been pasted in three places
   and the copies drifted -- one page carried the support phone as 09503086129
   and the other as 0950308612. Keeping the text in one place and letting the
   appearance be decided by whatever sheet the surrounding page happens to link
   repeats the same mistake one layer down. Both layouts link this file, so a
   third caller gets the same notice by including the partial and nothing else.

   Every rule is scoped to .privacy-notice and every one of them is a plain
   two-class or class-plus-type selector, so this file only ever claims the
   notice. Nothing here reaches a <p> or a <ul> anywhere else on either page.

   IT WINS ON SPECIFICITY, NOT ON BEING LINKED LAST, and that is load-bearing:
   Membership\DataPrivacy.cshtml links Css\TempStyleSheet.css from the BODY,
   which is after every <head> link on the page, and line 719 of that file
   re-declares the same grey

       p { font-size: 15px; color: #7e7e7e }

   as style.css:99 does. `.privacy-notice p` is (0,1,1) against its (0,0,1) and
   beats it wherever it is loaded. Keep the wrapper class on every rule for that
   reason -- a bare `p` here would lose to a sheet the view links four lines into
   its own markup, and the page would look untouched.

   TWO COLOURS AND BOTH ARE TOKENS, AS OF 09/07/2026. The notice follows the
   theme now. It was var(--coop-blue) with the six purposes and the "Data
   Privacy Consent" heading set against it in a literal #313131, and that pair
   was fixed: a cooperative configured its colour, the portal moved, and the
   privacy notice stayed this cooperative's blue in the middle of it. The
   structure is unchanged -- one colour for the prose, a darker one for the
   enumerated purposes and the headings -- but both ends of it are now derived
   from the cooperative's own colour.

   ONE RULE, STATED ONCE: prose is var(--coop-chrome); the six purposes, the
   "Data Privacy Consent" heading and the dialog title are var(--coop-chrome-dark).

   WHY --coop-chrome AND NOT --coop-primary, which is the brand. A skin
   deliberately does not override the coop tokens -- Tier 1 enforces exactly
   that -- so anything that should follow the swatch as well as the cooperative
   has to read the chrome pair. Neither of this notice's two callers can show a
   skin today (see the note on the layouts further down), so on both pages
   --coop-chrome resolves to the cooperative's PrimaryDark from
   _CoopThemeTokens.cshtml. Reading the chrome pair is what makes a third caller
   on a dashboard page correct for free, and it is what Css\loan-progress.css and
   Css\loan-result.css were changed to on 09/04/2026 after painting from the
   brand made a released loan green on a red page.

   CONTRAST, MEASURED NOT GUESSED. On the shipped green --coop-chrome is #3F6A24
   at 6.36:1 on white and --coop-chrome-dark is #2E4E1A at 9.46:1, against the
   6.52:1 and 13.0:1 the old blue and grey gave -- the same document, one hue
   over. Neither level can drift below that for another cooperative:
   ThemePalette derives PrimaryDark by darkening until it clears 6.0:1
   (ComfortableTextContrast) and ChromeDark is Scale(primaryDark, 0.75), a
   straight darkening, so the darker level cannot invert past the lighter one or
   fall under its guarantee. Every skin1-6 chrome value clears 4.5:1 by the same
   construction.

   AND YES, --coop-chrome IS ON 14px BODY TEXT HERE, which the .text-coop note at
   the foot of Css\coop-theme-content.css advises against ("--coop-chrome carries
   white text on a fill, --coop-chrome-dark carries small text on white"). That
   note's failure case is --coop-primary at 3.6:1 ending up in body copy, and
   this is not it: chrome is >=6.0:1 at :root by construction and >=4.5:1 on
   every skin, both clear of AA for 14px. It is deliberate, and it is what keeps
   this notice's two levels at the ratios the previous pair had -- setting the
   prose in chrome-dark instead would flatten the document onto one colour.
   Do not "correct" it to match .text-coop without reading this paragraph.

   The two buttons framing the notice are themed by coop-theme-buttons.css, not
   from here.

   Both values are written as a literal-then-var() pair, the IE11 convention this
   tree uses everywhere. Do not tidy the first line of a pair away. IE11 keeps
   the literals and therefore keeps the SHIPPED green rather than the configured
   colour, which is the same trade accepted for the whole theme on 08/24/2026.

   FONT FAMILY IS SET, AS OF 09/07/2026, AND IT IS A SYSTEM STACK. Until now it
   was deliberately not set and this was the one thing that still differed: the
   notice was Rubik on the login page and Lato on the membership page, because
   each layout's base sheet says so.

   THE REASON IT WAS LEFT ALONE DID NOT HOLD, and that is worth recording rather
   than quietly dropping. The note here used to argue that naming a face would
   either fall back to a generic sans or "require adding a THIRD-PARTY FONT
   REQUEST to the page where an applicant reads a privacy notice and consents to
   how their data is handled". Both pages already make one:

       login        @font-face{font-family:Rubik;...src:local('Rubik'),
                    local('Rubik-Regular'),url(https://fonts.gstatic.com/s/
                    rubik/v7/...ttf)}          Css\Test\style.min.css

       membership   @import url('https://fonts.googleapis.com/css?family=
                    Lato:300,400|Raleway:500,600,700,800');
                                               Css\style.css:56

   That @import is where Lato comes from, and what it returns points at
   fonts.gstatic.com in turn. Neither layout carries a <link> to a font host --
   both requests are buried a layer down in a vendor sheet, which is why removing
   the Font Awesome <link> to cdnjs.cloudflare.com from
   Membership\DataPrivacy.cshtml on 08/20/2026 looked like it had cleared the
   page. It had not. Do not put an external font <link> back in either view; that
   decision stands and this file does not need one.

   SO THE STACK IS THE SYSTEM'S OWN. It resolves identically on both pages by
   construction, costs no request at all, and -- the part that decided it -- the
   one document an applicant must read before consenting still renders when
   Google Fonts is blocked, slow or down. Rubik's src carries local() first so a
   machine that happens to have it installed skips the network; nothing gives the
   membership page that out, and Lato there is a hard dependency on a third party
   for the legibility of a consent form.

   The cost is accepted and small: the notice is now set in a slightly different
   face from the dialog buttons around it. Size, colour, rhythm and the list are
   what carried the visible difference between the two pages, and they were
   already fixed here; the faces were the remainder.

   Member tree only. There is no privacy notice in AdminPortal, so this file has
   no twin and must NOT be folded into one of the coop-theme*.css files -- those
   four are byte-identical across both trees under the Tier 1 twin guard, and a
   member-only concern in them is dead weight in one copy and a drift risk in
   both.

   NOT ONE rem IN THIS FILE, and that is not a style preference. The two pages
   do not agree on what a rem is:

       Content\bootstrap.min.css (3.0.0), linked by _PortalLayout only
           html { font-size: 62.5% }        ->  1rem = 10px

       Css\Test\style.min.css (Bootstrap 4), linked by _LoginLayout only
           no html font-size                ->  1rem = 16px

   That 62.5% is the old "62.5% trick" a 2013 template shipped so its authors
   could write 1.4rem and mean 14px. Written as .875rem, the notice came out at
   14px on the login page and 8.75px on the membership one -- SMALLER than the
   15px it had before, and the fix read as a bug. It was caught in the browser
   and by nothing else, because no stylesheet can be checked for the root it will
   be measured against. Every length here is px for that reason. line-height is
   unitless, which is fine: it multiplies the element's own font-size.

   Loaded after both Bootstraps and the template in each layout, and BEFORE
   Css\responsive-safety.css, which Tier 1 requires to stay last.
   ============================================================================ */

.privacy-notice {
    /* The login page's body size (Bootstrap 4's .875rem against a 16px root),
       restated so the membership page's marketing template cannot set it at 15px
       -- and in px, per the note above. */
    font-size: 14px;
    line-height: 1.5;
    /* The system's own face, so the two pages agree without either of them
       fetching anything. See the note above for why this is set at all now, and
       why a webfont was not the answer. The generic is named last and is a real
       fallback, not decoration -- a stack ending in a face that may be absent is
       the "no match, and now an unpredictable one" outcome this file used to
       warn about. */
    font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif;
    /* The notice's colour, the cooperative's own -- literally, since 09/07/2026.
       It is declared HERE, on the wrapper, rather than on the paragraphs: a
       paragraph added to the partial later then inherits it by existing. The six
       purposes and the "Data Privacy Consent" heading opt out below, and they are
       the only two inside the notice that do. */
    color: #3F6A24;
    color: var(--coop-chrome);
    /* Both callers render inside a centred card -- #loginCard carries
       .text-center, and the membership dialog sits in .detail-container. A
       consent an applicant is expected to READ is set left. */
    text-align: left;
}

/* Bootstrap 3 sizes <p> from the template at 15px and greys it; Bootstrap 4
   leaves it inheriting. Inherit in both. */
.privacy-notice p {
    font-size: inherit;
    line-height: inherit;
    color: inherit;
    margin: 0 0 16px;
}

/* No p:last-child { margin-bottom: 0 } here, though the trailing 16px above the
   footer border is arguably 16px too much. Bootstrap 4 gives the login modal
   that gap today, and this file's job is to make the membership dialog match the
   sign-up one -- not to restyle the sign-up one on the way past. Tightening it
   is a change to BOTH, and a separate decision. */

/* The six purposes. list-style is restated on BOTH the list and the items:
   style.css:95 sets it on `li`, so putting it back on the `ul` alone would lose
   to it on the membership page. 40px is the browser's own list indent, which is
   what the login page gets -- Bootstrap 4's reboot resets the margins of a list
   but not its padding. */
.privacy-notice ul {
    margin: 0 0 16px;
    padding-left: 40px;
    list-style: disc outside;
}

.privacy-notice li {
    list-style: disc outside;
    margin: 0;
}

/* "Data Privacy Consent". style.css:69 gives every heading Raleway 700 at
   #231F20 with letter-spacing; Bootstrap 4 leaves h5 at the body size and
   colour. The <strong> inside it is what makes it bold, in both. */
.privacy-notice h5 {
    font-family: inherit;
    font-size: inherit;
    font-weight: 500;
    line-height: 1.2;
    letter-spacing: normal;
    margin: 0 0 8px;
}

/* THE TWO EXCEPTIONS TO THE NOTICE'S COLOUR: the six purposes, and the heading
   that introduces the consent. Both are set dark against the prose, which is how
   the cooperative's own copy of this notice reads.

   THIS WAS A LITERAL #313131 UNTIL 09/07/2026 and is now the theme's darker
   chrome, so the contrast BETWEEN the two levels follows the cooperative along
   with the levels themselves. It has to be the same pair the prose is drawn
   from: a themed prose colour against a fixed neutral would drift apart on its
   own, going near-invisible for a cooperative whose colour happens to sit close
   to #313131 and washing out for one at the light end. ChromeDark is
   Scale(primaryDark, 0.75) -- a straight darkening of the value above, never a
   separate choice -- so the darker level cannot invert past the lighter one for
   any colour an administrator can type.

   The dialog title is drawn from this same rule, below, because it is a heading
   and the notice now has two of them.

   Declared after the two rules that size the list and the heading rather than
   inside them, so what is a colour DECISION stays separate from what is
   undoing Css\style.css. Delete this block and the notice is uniformly the
   chrome colour. */
.privacy-notice ul,
.privacy-notice li,
.privacy-notice h5 {
    color: #2E4E1A;
    color: var(--coop-chrome-dark);
}

/* THE DIALOG TITLE -- "Privacy Notice And Consent Form". Leo B. 09/07/2026.

   The same six words rendered as two different headings, which is the drift this
   whole file exists to end, one element higher up than it reached. MEASURED in a
   headless browser against each layout's real stylesheet chain, not read off the
   source -- three of the five values below are not what the source suggests:

                    face             size   weight  tracking  colour
       login        Poppins          18px   400     normal    #313131
       membership   Helvetica Neue   18px   500     .5px      #231F20

   READING THE SOURCE GETS THIS WRONG THREE TIMES, which is why the numbers
   below came from a render:

     - the login face is NOT Rubik, though Css\Test\style.min.css sets
       body{font-family:Rubik} and is linked after the dashboard template.
     - the membership face is NOT Raleway, though Css\style.css:65 sets
       h1..h6{font-family:'Raleway'}. Content\bootstrap.min.css (3.0.0) is
       linked AFTER style.css and carries h1..h6{font-family:inherit}, which
       wins on source order and hands the heading back to the body font.
     - the membership weight is 500, not style.css's 700, beaten the same way
       by Bootstrap 3.0.0's own h4 rule.

   What DID survive from style.css is the colour and the letter-spacing, because
   Bootstrap 3 sets neither on a heading. So the file that greys the prose and
   strips the bullets reaches the title too, just not with everything it declares.

   EVERY ONE OF THOSE FIVE PROPERTIES IS NAMED BELOW, or the membership title
   keeps whichever is left over. That is the same discipline .privacy-notice h5
   already follows for the consent heading, and for the same reason.

   THE VALUES ARE THE LOGIN PAGE'S -- 18px and weight 400, both as measured. 18px
   is 1.125rem against that page's 16px root; Bootstrap 4's own h4 default is
   1.5rem and this template overrides it, so the obvious guess was wrong by 6px.
   In px, never rem: Content\bootstrap.min.css sets html{font-size:62.5%} on the
   membership page, so 1.125rem there is 11.25px. That is the trap described at
   the head of this file, which cost a fix that shipped the notice at 8.75px.

   A CLASS, NOT '#myModal .modal-title, #dataPrivacyModal .modal-title'. Pinning
   two dialog ids into this sheet would break the one promise it makes -- that a
   third caller gets the same notice by including the partial and nothing else --
   and would leave the title behind on any caller that is not one of those two.
   Tier 1 checks both views still carry the class, because a class dropped in one
   of them is exactly the silent divergence this rule is repairing.

   Specificity is comfortable and, unlike the prose, uncontested: (0,1,0) against
   style.css's (0,0,1), and Css\TempStyleSheet.css -- the sheet
   Membership\DataPrivacy.cshtml links from its BODY, after every <head> link on
   the page -- carries a bare `p` rule at line 719 but no heading rule at all. */
.privacy-notice-title {
    font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif;
    font-size: 18px;
    font-weight: 400;
    line-height: 1.5;
    letter-spacing: normal;
    /* Both pages resolve to 0 already -- Bootstrap 4's .modal-title zeroes the
       bottom and its reboot the top, Bootstrap 3.0.0's .modal-title zeroes both
       and beats style.css's margin-top on specificity. Stated so it stays 0 if
       either template is replaced. */
    margin: 0;
    color: #2E4E1A;
    color: var(--coop-chrome-dark);
}