/*
 * Innovating Chaos — legibility fixes
 *
 * WHY THIS IS A SEPARATE FILE
 * ---------------------------
 * `ic-pathways.css` is the design of five specific pages. `ic-dark.css` is one
 * colour scheme. This is neither: it is a short list of places where the theme
 * and the Elementor kit disagree about a colour and the reader loses, and it
 * has to load on every page in both schemes. Mixing it into either of the other
 * two would mean it stopped applying somewhere it is needed.
 *
 * Every rule below is a measured contrast failure on the live site, not a
 * preference. The ratio before and after is recorded against each one so the
 * next person can tell a fix from a re-style.
 *
 * The whole file can be switched off with:
 *
 *     add_filter( 'ic_legibility_enabled', '__return_false' );
 */

/* ==========================================================================
   1. THE MAIN CALL-TO-ACTION BUTTONS                          1.51:1 → 6.9:1
   ==========================================================================

   THE BUG
   -------
   Two stylesheets each set a colour that is correct on its own:

     lettery/style.css      .mil-button        { background:#FFA726; color:#263238 }
     kit post-2062.css      .elementor-kit-2062 a { color: var(--e-global-color-d2bcc01) }

   `--e-global-color-d2bcc01` is #FF6600, the brand orange. `.elementor-kit-2062 a`
   is (0,1,1); `.mil-button` is (0,1,0). The kit therefore wins on every button
   that happens to be a link, and the label is painted brand orange on the
   theme's amber fill:

     #FF6600 on #FFA726  =  1.51:1

   That is the site's conversion set — "Start a conversation" on /about/,
   "Start the Expert Practice Diagnostic" on /build-beyond-you/, and the same
   widget across the pathway pages.

   THE FIX, AND WHY IT IS NOT A RESTYLE
   ------------------------------------
   Kit 2062 already declares what a button on this site looks like:

     .elementor-kit-2062 button,
     .elementor-kit-2062 input[type="submit"],
     .elementor-kit-2062 .elementor-button {
         background-color: var(--e-global-color-d2bcc01);   #FF6600
         color:            var(--e-global-color-primary);   #0B0500
     }

   That is 6.9:1 and it is already live — it is what the comment form's Submit
   button renders today. The rule simply never reaches `<a class="mil-button">`,
   because it selects `button`, `input` and `.elementor-button` and not an
   anchor. So the amber is not a decision anybody made about these buttons; it
   is the theme demo colour showing through a gap in the selector list. This
   applies the site's own declared button to the elements that were missing it,
   which is why the two button colours currently on the site become one.

   Specificity, not !important: `body a.mil-button` is (0,1,2) and beats the
   kit's (0,1,1). The variants below are (0,2,0) and still beat this, so
   `.mil-button-light`, `.mil-button-dark` and `.mil-button-linear` keep their
   own treatment untouched — they were never broken, because two classes
   already out-specify the kit.
   ========================================================================== */

body:not(.ic-page) a.mil-button {
  background-color: var( --e-global-color-d2bcc01, #FF6600 );
  color:            var( --e-global-color-primary,  #0B0500 );
}

/* --------------------------------------------------------------------------
   The five pathway pages are the exception, and they turned out to be broken
   in a second, separate way.

   `ic-pathways.css` §6 designs the call to action there as an *outline* button
   — a 45° orange gradient parked off-canvas that wipes in on hover, over a
   1px orange border, with `--ic-brand-ink` (#8C3800) as the label. Its own
   comment records the intent: "5.10:1 on sand", measured against the page
   surface. That figure is only reachable if the page surface is what shows
   through at rest.

   It never was. Lettery's `background-color:#FFA726` was never cleared, so the
   resting button has always been #8C3800 on amber — 4.0:1, below AA, and not
   the design that was measured. In dark mode it is far worse: the amber stays
   while `--ic-brand-ink` lifts to #FF8A3D, which is orange on amber at roughly
   1.2:1.

   Clearing the background-color is what makes the existing design real:

     light  #8C3800 on #FBF8F4 …… 7.4:1   (on Lettery's sand #DACFC1, 5.1:1)
     dark   #FF8A3D on #141C21 …… 7.4:1
     hover  #0B0500 on #FF6600 …… 6.9:1   (the gradient, wiped in)

   Both selectors are (0,2,2), so they beat the kit's `.elementor-kit-2062 a`
   without !important and cannot collide with each other.
   -------------------------------------------------------------------------- */
body.ic-page a.mil-button {
  background-color: transparent;
}

/* The label is usually wrapped in a span for the theme's hover scale. It
   inherits, but Lettery's own `.mil-button span` rules are one class deep and
   would otherwise be able to reach it. */
body a.mil-button > span {
  color: inherit;
}

/* These are the conversion buttons and they had no visible focus state at all:
   the theme's only affordance is `transform: scale(.95)`, which a keyboard user
   never sees. */
body a.mil-button:focus-visible {
  outline: 3px solid var( --e-global-color-primary, #0B0500 );
  outline-offset: 3px;
}

/* ==========================================================================
   2. THE COMMENT COOKIE-CONSENT LABEL                          1.61:1 → 8.6:1
   ==========================================================================

   THE BUG
   -------
   Lettery animates a floating label out of its form fields. When a field has
   content the label shrinks and lifts:

     input:valid ~ label,
     input:focus ~ label,
     input.mil-keep ~ label,  … { color:#FFA726; font-size:9px; top:0; left:0 }

   Correct for a text input. But a checkbox is *always* `:valid` — there is no
   such thing as an empty one — so WordPress's consent checkbox permanently
   drags its own label into the shrunken state:

     #FFA726 on #E9EAEB at 9px  =  1.61:1

   The label reads "Save my name, email, and website in this browser for the
   next time I comment." It is the one control on the page that carries a data
   consent decision, and it was the least readable text on the page.

   THE FIX
   -------
   Exclude checkbox and radio from the floating-label treatment. They have no
   placeholder to float away from, so the effect never applied to them
   meaningfully in the first place. Scoped to the comment form rather than all
   forms, because Lettery may use `.mil-keep` on a checkbox somewhere
   deliberately and this is not the place to find out.
   ========================================================================== */

.comment-form-cookies-consent input[type="checkbox"] ~ label,
.comment-form-cookies-consent input[type="radio"] ~ label,
.comment-form input[type="checkbox"] ~ label,
.comment-form input[type="radio"] ~ label {
  position: static;
  top: auto;
  left: auto;
  color: var( --e-global-color-primary, #0B0500 );
  font-size: 14px;
  line-height: 1.5;
}

/* ==========================================================================
   3. THE POST DATE IN THE BYLINE                               1.66:1 → 5.3:1
   ==========================================================================

   THE BUG
   -------
   `.mil-softened-30 { color:#BEC1C3 !important }` is the theme's way of
   de-emphasising secondary text. On a dark surface — the footer, and the
   gradient over a blog card's image — it is correct and measures about 7.4:1.
   On the single post byline it sits on #F4F5F5:

     #BEC1C3 on #F4F5F5 at 11px  =  1.66:1

   THE FIX
   -------
   Darken it only where it lands on a light surface, and explicitly restore the
   light value inside `.mil-overlay` — the blog-card case, which was never
   broken. The overlay rule is (0,3,0) against this one's (0,2,0), so the
   cascade keeps them apart without a `:not()` that has to know about ancestors.

   `!important` here is not a shortcut: the declaration being overridden is
   itself `!important`, so nothing else can reach it.
   ========================================================================== */

.mil-post-info .mil-softened-30 {
  color: #63676A !important;
}

/* Cards whose text is light, which is the ones painting over a dark scrim.
   `.mil-light` is Lettery's own marker for "this text is white", so it is a
   reliable test for which card variant we are in — and it matters, because the
   blog card ships in two of them. /blog/ builds `h5.mil-light` over a gradient;
   /about/ builds a plain `h5` that the kit paints near-black. Lightening the
   date on the second kind would put pale grey next to a black title. */
.mil-overlay:has(.mil-light) .mil-post-info .mil-softened-30,
.mil-dark-bg .mil-post-info .mil-softened-30 {
  color: rgba( 255, 255, 255, 0.82 ) !important;
}

/* ==========================================================================
   4. A BLOG CARD WITH NO FEATURED IMAGE
   ==========================================================================

   THE BUG
   -------
   Lettery's blog card is an image with a dark gradient over it and white text
   on the gradient. The image is what gives the card its height —
   `.mil-cover { padding-bottom:70% }` — and what makes the white text legible.

   When a post has no featured image the theme emits no `.mil-cover` at all.
   The card collapses to nothing and its white `h5` paints straight onto the
   page background. On /blog/ and the home page that produced a card that was
   simply not there: 1.09:1, invisible.

   That is what "Transformative Power of AI" was doing. It now has a featured
   image, so this rule is currently dormant. It stays because the failure comes
   back the moment anybody publishes without one, and it fails silently — the
   card does not look broken, it looks absent.

   THE FIX
   -------
   Give a coverless card the height the cover would have given it and a surface
   dark enough for the text that is already there. `:has()` keeps this scoped to
   exactly the broken case; the same `:has()` idiom is already used in
   `ic-pathways.css` to hide the empty testimonial carousel.
   ========================================================================== */

.mil-card-1:not(:has(.mil-cover)) {
  padding-bottom: 70%;
  background-color: #263238;
}

/* --------------------------------------------------------------------------
   The same card, used a second way, with the same result.

   Lettery ships the blog card with two overlay recipes and only one of them
   carries a scrim:

     /blog/          .mil-overlay.mil-inside.mil-gradient-overlay   9 of 9 cards
     /about/         .mil-overlay.mil-inside.mil-between            7 of 7 cards
     home            .mil-overlay.mil-inside.mil-between            5 of 8 cards

   `.mil-between` has no background and no gradient, so on /about/ and on five
   of the eight home-page cards the white `h5.mil-light` title and the meta line
   are painted straight onto the photograph. Whether that is readable is decided
   by whichever image the post happens to carry, which is to say it is not
   decided at all — and it is the same failure the missing featured image
   produced, arriving by a different route.

   Give those overlays the scrim the gradient variant already has.

   THE SCOPING MATTERS, AND THE FIRST ATTEMPT AT IT WAS WRONG
   ---------------------------------------------------------
   `:has(.mil-post-info)` alone looks like the right test — it selects the blog
   card and not the numbered service cards — and it is not enough. /about/
   builds the same blog card with a plain `<h5>` that the kit paints
   `--e-global-color-primary` (#0B0500), not Lettery's white `h5.mil-light`.
   Scrimming that variant put near-black text on a near-black wash: measured at
   1.54:1, worse than the unscrimmed photograph it replaced.

   `:has(.mil-light)` is the honest test, because `.mil-light` is Lettery's own
   marker for "this text is white". A scrim is only ever added under text that
   is actually light.

   Left alone deliberately: /about/'s dark-title cards still put #0B0500 over an
   uncontrolled photograph. That is a real weakness, but the fix is a lighter
   scrim or a solid card surface — a design decision about a page nobody has
   raised, not a contrast repair. It is recorded rather than guessed at.
   -------------------------------------------------------------------------- */

.mil-card-1 .mil-overlay:not(.mil-gradient-overlay):has(.mil-post-info):has(.mil-light) {
  background: linear-gradient(
    180deg,
    rgba( 38, 50, 56, 0.10 ) 30%,
    rgba( 38, 50, 56, 0.70 ) 70%,
    rgba( 38, 50, 56, 0.95 ) 100%
  );
}

.mil-card-1:not(:has(.mil-cover)) > .mil-overlay {
  /* The gradient assumes an image beneath it and starts at 10% opacity. With
     nothing behind it, start where it is already carrying the contrast. */
  background: linear-gradient(
    180deg,
    rgba( 38, 50, 56, 0.35 ) 0%,
    rgba( 38, 50, 56, 0.80 ) 60%,
    rgba( 38, 50, 56, 0.95 ) 100%
  );
}

/* ==========================================================================
   5. DARK MODE
   ==========================================================================

   Scoped exactly as `ic-dark.css` is — `body.ic-dark-ok` plus the media query —
   so this follows the reader's system setting and the same master switch.

   The buttons need nothing here. #0B0500 on #FF6600 is 6.9:1 whatever the page
   behind it is doing, because both colours belong to the button.
   ========================================================================== */

@media ( prefers-color-scheme: dark ) {

  body.ic-dark-ok a.mil-button:focus-visible {
    outline-color: var( --icd-ink, #F2EFEA );
  }
}

/* --------------------------------------------------------------------------
   WHAT IS DELIBERATELY *NOT* HERE, AND WHY

   The first version of this block lifted the byline date to `--icd-muted` and
   the consent label to `--icd-body` in dark mode, on the assumption that they
   land on `--icd-paper`. Measured against a real dark render, they do not:

     consent label   #A9B2B7 → 1.79:1
     byline date     #8A9498 → 2.84:1

   The rules were applying correctly. The assumption underneath them was wrong.
   `ic-dark.css` carries no rule for the single-post template at all — no
   `.mil-gray-bg`, no content frame, no comment block — because it was written
   for the Elementor pathway pages. So on a post it darkens the page body while
   `.col-xl-9` stays #F4F5F5 and the comment block stays #E9EAEB, and lifting
   the text put pale grey on a near-white panel.

   The surfaces are light in both schemes, so the light values above are already
   correct in both, and no dark override belongs here. Adding one back means
   first giving the post template a real dark treatment — at which point this is
   the place for the matching text colours.

   The underlying gap is recorded in HANDOFF.md: single posts are half-inverted
   in dark mode, which is the exact failure `ic-dark.css`'s own header warns
   against. It is not visible today because the Light Mode Default plugin is
   active and no reader can reach dark mode at all.
   -------------------------------------------------------------------------- */