/* ============================================================================
   THE HEADER
   ----------------------------------------------------------------------------
   Loaded on EVERY front-end page, unlike adinkra.css, which icgc-adinkra.php
   enqueues only where the page content uses the design. That distinction used
   to be right and stopped being right the day the logo changed: the artwork is
   white lettering with a gold script and no dark ink in it at all, so on a page
   that did not get this stylesheet the theme's white bar would render an
   invisible logo. The header is now site chrome rather than part of a concept.

   THE SOLID STATE IS THE DEFAULT, DELIBERATELY. Seven pages carry a dark
   photographic band at the top and the navigation floats on it; everywhere else
   is cream, and light navigation on cream is an invisible menu. Defaulting to
   transparent and having script solidify it would mean a failed script leaves
   the menu unreadable. Defaulting to solid means a failed script leaves the
   design plainer than intended and perfectly usable. Fail toward legible.
   ========================================================================== */

#main-header {
  background-color: var(--ad-ink, #14100C) !important;
  box-shadow: 0 1px 0 rgba(224, 178, 92, .28) !important;
  transition: background-color .35s ease, box-shadow .35s ease;
}

/* Light in every state, so nothing changes colour on scroll and there is no
   second logo to keep in step. A colour swap that runs at one scroll position
   and not another is the usual way this pattern breaks. */
#top-menu > li > a,
#top-menu > li > a:hover,
.mobile_menu_bar:before { color: #F4F6F1 !important; }
#top-menu > li.current-menu-item > a { color: #E0B25C !important; }

#logo { max-height: 62px !important; }

/* The mobile panel is part of the same bar, so it takes the same ink. Left
   white it would have been a white sheet hanging off a dark header - and the
   rule that lightens the bar's own links would have put white text on it. */
.et_mobile_menu {
  background-color: var(--ad-ink, #14100C) !important;
  border-top-color: rgba(224, 178, 92, .28) !important;
}
.et_mobile_menu li a { color: #F4F6F1 !important; border-bottom-color: rgba(244, 246, 241, .12) !important; }
.et_mobile_menu li.current-menu-item > a { color: #E0B25C !important; }

/* ----------------------------------------------------------------------------
   THE CLEAR STATE — the photograph runs up behind the navigation.
   Set by script, only on pages whose FIRST section is a dark photographic band
   (body.ad-top-photo, from icgc_adinkra_body_class()).
   -------------------------------------------------------------------------- */

/* Transparent, but NOT bare. The scrim is a safety net rather than a
   decoration: if the script that manages this class ever stops running at the
   right moment, the navigation would otherwise sit on whatever happens to be
   underneath. With it the worst case is a dark wash at the top of a cream page
   - odd-looking, and still readable.

   IT ALSO CARRIES THE CONTRAST, AND THE FIRST VERSION DID NOT.
   The effect was applied to every page whose first section carries
   ad-band-photo, on the reasoning that a photographic band is a dark band.
   IT IS NOT. About Us opens on a pale portrait and the white logo very nearly
   vanished into it. "Photographic" and "dark" are different properties and only
   one of them was being checked.
   Measured on all seven bands - the 95th-percentile brightest cell of the strip
   the bar covers - the .55 this shipped with FAILED FIVE OF THEM, worst on the
   gold current-page item: Become a member 2.13:1, Watch 2.35:1, Give 2.83:1,
   against 4.5:1 needed at 15px. At .80 every page clears, white 9.5-15.2 and
   gold 5.3-8.4. scripts/measure-header-contrast.py re-runs it.

   AND IT HAS TO BE STRONG THROUGH THE BAR, NOT ONLY AT ITS TOP EDGE. The links
   sit vertically centred, around 30-50px down an 80px bar, so a gradient that
   is heavy at y=0 and gone by y=80 is weakest exactly where the words are. The
   scrim is therefore drawn by a pseudo-element TWICE the bar's height: full
   strength across the bar, fading out below it, where nothing is read. */
body.ad-nav-clear #main-header {
  background-color: transparent !important;
  background-image: none !important;
  box-shadow: none !important;
}
body.ad-nav-clear #main-header::after {
  content: "";
  position: absolute;
  inset: 0 0 auto 0;
  height: 200%;                 /* the bar, and as much again below it */
  z-index: -1;                  /* #main-header has z-index 99999, so this
                                   negative layer stays inside it: behind the
                                   logo and links, above the photograph. */
  pointer-events: none;
  background: linear-gradient(180deg,
    rgba(20, 16, 12, .84) 0%,
    rgba(20, 16, 12, .80) 42%,   /* still .80 where the links are */
    rgba(20, 16, 12, .44) 72%,
    rgba(20, 16, 12, 0) 100%);
}

/* The theme holds content clear of its fixed header with padding on
   #page-container. Removing it is what lets the band start at y=0. */
body.ad-top-photo #page-container { padding-top: 0 !important; }

/* Then hand the band's CONTENT back exactly the header's height — as a margin
   on the row, not as padding on the section.
   PADDING WOULD MEAN RESTATING EACH SECTION'S OWN VALUE AT EVERY BREAKPOINT,
   AND THOSE DIFFER: the hero is 150px on desktop and 80px on a phone. A flat
   230px override was measured right on a desktop and 150px too low on a phone.
   The row does not care what the section's padding is, so this needs one
   number and survives that padding being changed later. */
body.ad-top-photo #page-container .et_pb_section:first-of-type > .et_pb_row {
  margin-top: 80px;
}


/* ==========================================================================
   MOVED HERE FROM adinkra.css ON 10 SEPTEMBER 2026
   --------------------------------------------------------------------------
   Both blocks below style SITE CHROME - the footer strip and the signed-in
   menu's breakpoint - and both were sitting in adinkra.css, which
   icgc-adinkra.php enqueues only where the page content contains "ad-sec".
   Every page that carried the design also carried the chrome, so nothing
   ever looked wrong and the dependency stayed invisible.

   The 2026 home page is the first page that deliberately does NOT load
   adinkra.css - it has its own scoped stylesheet, and its plugin says in as
   many words that adinkra.css must not reach its elements. Publishing it
   would therefore have taken the footer's layout and the member menu's
   1500px breakpoint off the church's most-visited page and nowhere else,
   which is the kind of fault that gets reported as "the footer looks odd on
   the home page" three weeks later.

   The reasoning inside each block is the original author's and is kept
   verbatim; only the file changed.
   ========================================================================== */

/* ==========================================================================
   FOOTER ACCOUNT LINKS
   ========================================================================== */
/* Flex rather than Divi's floats, so the order on screen is stated here and
   does not depend on where the markup could be injected. */
#footer-bottom .container {
  display: flex;
  flex-wrap: wrap;
  align-items: center;
  justify-content: space-between;
  gap: 10px 26px;
}
/* The copyright line is ~660px of text and was pushing the social icons onto a
   row of their own, which put them bottom-left instead of bottom-right. Letting
   it shrink keeps all three on one line: copyright, then the account links,
   then the icons. */
#footer-bottom #footer-info {
  order: 1;
  margin: 0;
  float: none;
  flex: 1 1 220px;
  min-width: 0;
}
/* The account link takes the right-hand corner; the icons sit in beside the
   copyright. Order is stated here rather than left to the markup, because
   the account block is injected by a plugin and lands wherever the theme
   template part happens to fire. */
#footer-bottom .et-social-icons { order: 2; float: none; margin: 0; flex: 0 0 auto; }
.icgc-footer-account            { order: 3; flex: 0 0 auto; }

.icgc-footer-account {
  display: inline-flex;
  align-items: center;
  gap: 12px;
  font-family: var(--ad-display, Futura, "Avenir Next", "Century Gothic", "URW Gothic", "Trebuchet MS", sans-serif);
  font-size: 15px;
  font-weight: 700;
  letter-spacing: 0.13em;
  text-transform: uppercase;
}
.icgc-footer-account a {
  color: inherit;
  text-decoration: none;
  border-bottom: 1px solid transparent;
  padding-bottom: 2px;
  transition: border-color .2s, color .2s;
}
.icgc-footer-account a:hover {
  color: var(--ad-gold-bright, #C08A2E);
  border-bottom-color: currentColor;
}
.icgc-footer-dot { opacity: .45; }

@media (max-width: 980px) {
  /* Divi already centres the icons here; keep the whole row together. */
  #footer-bottom .container { justify-content: center; text-align: center; }
  .icgc-footer-account { margin-left: 0; order: 2; }   /* centred here - "right" has no meaning once stacked */
  #footer-bottom #footer-info { order: 3; width: 100%; }
  #footer-bottom .et-social-icons { order: 1; width: 100%; }
}

/* ==========================================================================
   THE HEADER WHEN THE MENU IS LONG
   --------------------------------------------------------------------------
   Signed out, the menu is four items and Divi's own 980px breakpoint is right.
   Signed in, icgc-member-menu.php appends up to ten more and the menu wants
   1257px of its own. The theme runs et_fullwidth_nav, so there is no 1080px
   container to stop it.

   What actually breaks is the WRAP, not the width. Divi indents
   #et-top-navigation from the left to clear the logo, but that padding shrinks
   with the viewport - 122px at 1600, 30px at 1100 - and every wrapped row
   starts at that same indent. So once the menu needs a second row on a narrow
   window, the row begins left of the logo and runs underneath it. That is the
   screenshot the church sent: the logo sitting on top of "Recordings".

   Measured on 20 August 2026, with the menu at fourteen items:

       items need           1257px
       available            viewport - 122px of indent
       one row needs        viewport >= ~1379
       clears the logo at   viewport >= ~1394

   So it is sound above about 1400 and broken below it, with no margin in
   between worth trusting - one more item, or one longer label, moves the
   number. Below 1500px the long menu therefore becomes the hamburger Divi
   already ships, which is rendered from the same wp_nav_menu call and so
   already carries the member items. The hundred pixels between 1400 and 1500
   are deliberate headroom, and they cost a signed-in member on a 1440 laptop
   the horizontal bar - which is the same menu, complete, one click away.

   Fourteen top-level items do not fit on a laptop and tightening does not
   change that: dropping the item padding to 14px recovered 21px of the 400
   needed.

   Specificity, not source order, is what wins here: Divi sets #top-menu-nav
   and #et_mobile_nav_menu with bare id selectors at (1,0,0), and adding the
   body class takes these to (1,1,1).

   The class comes from icgc_menu_body_class() and is present only when the
   member items actually rendered - so a signed-out visitor, and anyone whose
   roles add nothing, keeps the full menu down to 980px as before.

   NO max-width guard on #et-top-navigation. One was written here first, as
   belt and braces against the menu ever reaching the logo, and it made things
   worse: capping the box at calc(100% - 160px) left 1256px of room for 1257px
   of menu, so at 1600px - a width where everything fits comfortably - a single
   item wrapped to a second row. A guard that manufactures the failure it was
   added to prevent is worth recording rather than quietly deleting.
   ========================================================================== */
@media (max-width: 1500px) {
  body.icgc-nav-long #top-menu-nav { display: none; }
  body.icgc-nav-long #et_mobile_nav_menu { display: block; }
}