/*
 * Market-value colours — DA/RT × LMP/CC, in one place.
 * =====================================================
 *
 * Owner ask 2026-08-25: "I want to be able to see the color and know if it's
 * DA/RT lmp/CC instantly." So the four numbers are encoded on two independent
 * channels, and a cell is identified by reading both:
 *
 *                 |  DA ground (blue)   |  RT ground (amber)
 *   --------------+---------------------+--------------------
 *   LMP ink       |  DA LMP             |  RT LMP        <- pale ground
 *   CC ink        |  DA CC              |  RT CC         <- deeper ground
 *
 *   INK    = WHAT the number is.  Every LMP is one colour whether it is DA or
 *            RT; every congestion component is another. This is the half of
 *            the ask that reads at a glance from across the desk.
 *   GROUND = WHICH market it came from. Hue says DA or RT; depth of the same
 *            hue says LMP or CC, so DA CC sits next to DA LMP as an obviously
 *            related but distinct cell rather than an unrelated fifth colour.
 *
 * The two channels are deliberately redundant on the LMP/CC axis (ink AND
 * depth both carry it), which is what keeps the scheme legible to a
 * red-green-deficient reader and in a greyscale print.
 *
 * THAT REDUNDANCY IS WHAT PAID FOR THE FOLLOW-UP. Asked on the same day to
 * colour the CC columns by sign the way the P&L column is coloured, the CC ink
 * could be handed over — a CC VALUE is red or green now, and only the CC
 * HEADER and the deeper ground still carry "this column is congestion". The
 * LMP columns kept their ink, because their pale ground is not saying "LMP"
 * on its own and there would be nothing left holding the distinction.
 *
 * TO RECOLOUR ANYTHING, EDIT ONLY THE TWO TOKEN BLOCKS BELOW. Nothing else in
 * this file, and nothing in any template or .js, names a colour: the markup
 * only says which of the four cells it is (mv-da-lmp / mv-rt-lmp / mv-da-cc /
 * mv-rt-cc) and this file decides what that looks like.
 *
 * Two token sets, because these cells appear on two different grounds. The
 * ls-/ca- tables of the bid pages follow the site theme — white when the
 * viewer picks light, slate otherwise (base.html defaults to DARK, so the
 * light set is the minority case, not the common one). The node cards, their
 * hourly tables and the drill-down panel are slate in EITHER theme, which is
 * why they take the dark set unconditionally rather than through
 * .dark-theme. Grounds are rgba on purpose — they tint whatever row highlight
 * is beneath them (peak-hour, inc-row, hover) instead of painting over it.
 */

:root {
    /* --- ink: what the number is --------------------------------------- */
    --mv-ink-lmp:    #1d4ed8;                    /* blue   — DA LMP + RT LMP */
    --mv-ink-cc:     #6d28d9;                    /* violet — DA CC  + RT CC  */

    /* --- ground: which market it came from ------------------------------ */
    --mv-bg-da-lmp:  rgba(59, 130, 246, 0.10);   /* blue,  pale   */
    --mv-bg-rt-lmp:  rgba(217, 119, 6,  0.10);   /* amber, pale   */
    --mv-bg-da-cc:   rgba(59, 130, 246, 0.24);   /* blue,  deeper */
    --mv-bg-rt-cc:   rgba(217, 119, 6,  0.24);   /* amber, deeper */

    /* --- supporting ----------------------------------------------------- */
    --mv-edge-da:    #3b82f6;   /* opaque DA hue, for card edges and rules */
    --mv-edge-rt:    #d97706;   /* opaque RT hue */
    --mv-neg-rule:   #dc2626;   /* underline under a negative value */

    /* Ink OF a negative / positive value, on the cells that hand sign the ink
       channel (the CC columns — see below). These are the P&L column's own
       red and green (`.pos`/`.neg` in cleared_actual.css and dark_mode.css),
       stepped one shade darker where the P&L colour does not survive the move.
       It does not survive it here: the CC grounds are the deepest tints in the
       palette, so a colour that reads fine on a plain table row can miss 4.5:1
       on them. Measured on the real composites — P&L's #dc2626 is 3.65 and its
       #15803d is 3.79/3.87, both short; #b91c1c is 4.89/4.99 and #166534 is
       5.39/5.50.
       Neither of these two ships. Every surface carrying a CC column is an
       .hourly-table or .hourly-table-compact, both of which take the dark set
       below in either theme. They are here so the light palette stays a
       complete set for the first light-ground CC column. */
    --mv-ink-neg:    #b91c1c;
    --mv-ink-pos:    #166534;
}

/* Dark ground: the site-wide dark theme, plus the surfaces that are slate in
   EITHER theme — the node cards and their hourly tables on the cleared and
   node-detail pages, and the drill-down panel. Same token names, so every rule
   below is untouched; only what they resolve to changes. */
html.dark-theme,
.node-section,
.summary-card,
.hourly-table,
.hourly-table-compact,
.bidx-panel {
    --mv-ink-lmp:    #93c5fd;
    --mv-ink-cc:     #c4b5fd;

    /* Note these are DEEP hues (blue-800 / amber-800), not the light ones the
       white set uses, and they are laid on thick. Two measured reasons:
       slate is itself blue (#1e293b is r30/b59), so a PALE amber wash over it
       still composites out cool and the two LMP grounds both read blue-grey;
       and a light wash raises the ground's luminance until the only inks that
       clear 4.5:1 are near-white, which costs the LMP/CC ink distinction the
       whole scheme rests on. Darkening instead keeps the hue obvious and
       leaves room for a real blue and a real violet on top. */
    --mv-bg-da-lmp:  rgba(30, 64, 175, 0.32);
    --mv-bg-rt-lmp:  rgba(146, 64, 14, 0.32);
    --mv-bg-da-cc:   rgba(30, 64, 175, 0.52);
    --mv-bg-rt-cc:   rgba(146, 64, 14, 0.52);

    --mv-edge-da:    #60a5fa;
    --mv-edge-rt:    #fbbf24;
    --mv-neg-rule:   #f87171;

    /* THESE are the two that actually ship. The green needed no adjustment —
       #34d399 is the P&L column's own dark green and it measures 5.74 on the
       dark DA CC ground and 5.37 on RT CC. The red did: P&L's #f87171 is only
       3.85 as ink on dark RT CC, so the negative steps one shade lighter to
       #fca5a5 (6.04 / 5.61). Same family and same reading, one of them just
       cannot be used at the P&L column's own value here — which is why they
       are tokens and not a shared class. */
    --mv-ink-neg:    #fca5a5;
    --mv-ink-pos:    #34d399;
}

/* ---------------------------------------------------------------------------
 * The four cells. Each class only DECLARES which pair it is; the rule after
 * them applies it. Adding a fifth cell type is one line here plus one line in
 * the applier.
 * ------------------------------------------------------------------------ */
/* Each cell states three inks, not one: what it looks like, what a NEGATIVE
   value in it looks like, and what a POSITIVE one does. That is the whole knob
   for the owner ask of 2026-08-25 — "for DA/RT CC cols, have negative values be
   red and positive green like 'P&L' col".
     LMP — both sign inks point back at the market ink, so an LMP number's
           colour still says LMP and nothing else; sign shows as the rule under
           a negative.
     CC  — hands the ink channel to sign outright, exactly as the P&L column
           does. On a CC cell it can afford to: the DEEPER ground is already
           saying "congestion", so the ink is free to leave. On an LMP cell the
           pale ground is not doing that job, which is why the same change
           there would delete a distinction instead of moving it.
   To make the LMP columns behave like the CC ones, change four words below and
   the two GRIDS follow — hybrid_daily.js and node_common.js mark every market
   cell with mv-neg / mv-pos whichever column it is, precisely so that stays a
   one-file decision. ⚠️ Three surfaces would NOT follow, because they carry LMP
   and no CC and so were never given a positive marker: cleared_summary.js,
   cleared_actual_day.js and bid_drilldown.js emit mv-neg only. Their positives
   would fall through to var(--mv-ink) and keep the blue while the grids went
   green. Add the marker there first, or the same column reads two ways on two
   pages. */
.mv-da-lmp {
    --mv-bg:           var(--mv-bg-da-lmp);
    --mv-ink:          var(--mv-ink-lmp);
    --mv-ink-sign-neg:     var(--mv-ink-lmp);
    --mv-ink-sign-pos: var(--mv-ink-lmp);
}
.mv-rt-lmp {
    --mv-bg:           var(--mv-bg-rt-lmp);
    --mv-ink:          var(--mv-ink-lmp);
    --mv-ink-sign-neg:     var(--mv-ink-lmp);
    --mv-ink-sign-pos: var(--mv-ink-lmp);
}
.mv-da-cc {
    --mv-bg:           var(--mv-bg-da-cc);
    --mv-ink:          var(--mv-ink-cc);
    --mv-ink-sign-neg:     var(--mv-ink-neg);
    --mv-ink-sign-pos: var(--mv-ink-pos);
}
.mv-rt-cc {
    --mv-bg:           var(--mv-bg-rt-cc);
    --mv-ink:          var(--mv-ink-cc);
    --mv-ink-sign-neg:     var(--mv-ink-neg);
    --mv-ink-sign-pos: var(--mv-ink-pos);
}

.mv-da-lmp, .mv-rt-lmp, .mv-da-cc, .mv-rt-cc {
    background: var(--mv-bg);
    color: var(--mv-ink);
}

/* Column headers wear their column's colour, which is what makes the scheme
   self-documenting — no legend to look up. The `table th` prefix is the whole
   reason this second rule exists: every host stylesheet here sets
   `.hourly-table th { background: #0f172a }` at (0,1,1), which outranks a bare
   class, so the header rule has to be (0,1,2) to land. */
table th.mv-da-lmp, table th.mv-rt-lmp,
table th.mv-da-cc,  table th.mv-rt-cc {
    background: var(--mv-bg);
    color: var(--mv-ink);
}

/* Sign.
 *
 * On the CC columns the ink now reads the way the P&L column's does — red
 * below zero, green at or above it (owner ask, and `>= 0` is green there and
 * in the spread column, so it is green here; a value that is absent is neither
 * and keeps the market ink). The LMP columns are unchanged: their sign inks
 * point back at the market ink, so sign shows only as the rule underneath.
 *
 * ⚠️ Red-and-green is the one pair a colour-deficient reader cannot separate,
 * which makes the RULE under a negative load-bearing rather than decorative —
 * it is now the only channel that says "negative" without colour, and it is
 * why nothing similar is added to the positives. Underlined-and-bold means
 * negative on all four columns whether or not the ink moved, and it survives a
 * greyscale print.
 *
 * Both routes into a sign are caught: the cell-level mv-neg / mv-pos class the
 * grids put on the <td>, and the val-negative / negative spans the hybrid
 * formatter emits INSIDE these cells. The fallback keeps a bare mv-neg or
 * mv-pos (no market class) on its inherited ink. */
.mv-neg,
.mv-da-lmp .val-negative, .mv-rt-lmp .val-negative,
.mv-da-cc  .val-negative, .mv-rt-cc  .val-negative,
.mv-da-lmp .negative,     .mv-rt-lmp .negative,
.mv-da-cc  .negative,     .mv-rt-cc  .negative {
    color: var(--mv-ink-sign-neg, var(--mv-ink));
    font-weight: 700;
    text-decoration: underline;
    text-decoration-color: var(--mv-neg-rule);
    text-decoration-thickness: 2px;
    text-underline-offset: 2px;
}

/* No rule and no extra weight here on purpose — see above. */
.mv-pos,
.mv-da-lmp .val-positive, .mv-rt-lmp .val-positive,
.mv-da-cc  .val-positive, .mv-rt-cc  .val-positive,
.mv-da-lmp .positive,     .mv-rt-lmp .positive,
.mv-da-cc  .positive,     .mv-rt-cc  .positive {
    color: var(--mv-ink-sign-pos, var(--mv-ink));
}

/* ---------------------------------------------------------------------------
 * Neighbours that are not one of the four cells but must move with them.
 * ------------------------------------------------------------------------ */

/* "Avg CC" on a node card: a congestion number with no DA/RT of its own, so it
   takes the CC ink and no ground. */
.cc-value { color: var(--mv-ink-cc); }

/* The DA / RT period-average cards above a node's hourly table. Their left
   edge is the only thing saying which market the number is, so it uses the
   same hue as that market's ground. */
.summary-card.da { border-left-color: var(--mv-edge-da); }
.summary-card.rt { border-left-color: var(--mv-edge-rt); }
.summary-card.da .summary-value,
.summary-card.rt .summary-value { color: var(--mv-ink-lmp); }