/* Homepage/navbar polish pilot — additive refinements only.
   Scope: linked from index.html only, during pilot review.
   No layout, section, colour, or content change; existing classes
   and markup are untouched. */

/* Withdrawn: an earlier round hid every top-level section icon for a
   "text-only" desktop presentation. This round's instruction
   explicitly reverses that -- keep meaningful icons (including
   Events and language) alongside one selected-language label, using
   the theme's own existing icon system rather than hiding or
   duplicating it. No icon-hiding rule here now; consistent
   icon/text alignment is handled below instead. */
/* Subtle separation + smoother hover/transition on the desktop nav.
   Restrained glass: readable background first, blur as enhancement
   only -- browsers without backdrop-filter support keep the opaque
   fallback and never render an unreadably transparent header. */
.masthead .header-bar {
  background: rgba(255, 255, 255, 0.92);
  border-bottom: 1px solid rgba(0, 0, 0, 0.06);
  box-shadow: 0 2px 10px rgba(0, 0, 0, 0.04);
  transition: box-shadow 0.2s ease, background-color 0.2s ease;
}
@supports (backdrop-filter: blur(1px)) or (-webkit-backdrop-filter: blur(1px)) {
  .masthead .header-bar {
    background: rgba(255, 255, 255, 0.72);
    -webkit-backdrop-filter: blur(14px);
    backdrop-filter: blur(14px);
  }
}
.masthead {
  transition: box-shadow 0.2s ease;
}

/* Icon/label alignment, root cause confirmed in main.min.css: two
   rules target the same ".main-nav>li>a" selector list -- one sets
   align-items:center, a later one (same specificity) sets
   align-items:flex-start, so the later rule wins and every nav
   link's icon+text pair top-aligns instead of centering. Pre-existing
   theme self-conflict, not introduced here. Restores centering, and
   (per this round, icons retained) a consistent icon/text gap so the
   kept icons and the single-language label line up evenly. */
.main-nav > li > a {
  align-items: center;
  gap: 5px;
  transition: color 0.2s ease, opacity 0.2s ease;
}
.main-nav > li > a > img,
.main-nav > li > a > i {
  flex-shrink: 0;
  width: 16px;
  height: 16px;
  font-size: 15px;
  line-height: 1;
}
.main-nav > li > a:hover {
  opacity: 0.85;
}

/* Minimal breathing room around the new Events item so it reads as a
   distinct, calm top-level link rather than crowding its neighbours. */
.events-nav-link > a {
  transition: color 0.2s ease, opacity 0.2s ease;
}
.events-nav-link > a:hover {
  opacity: 0.85;
}
.main-nav > li > a:focus-visible,
.events-nav-link > a:focus-visible,
#mobile-menu > li > a:focus-visible,
.mobile-main-nav > li > a:focus-visible {
  outline: 2px solid var(--the7-accent-color, #9d2f20);
  outline-offset: 2px;
}

/* Navbar overflow fix, v4 -- withdraws v3's 2000px figure and its
   forced mobile-switch block (both based on a now-disproven premise).

   Confirmed (unchanged from v3): v2 had zero effect because this
   stylesheet's <link> loaded before custom.css (same selector/
   specificity, later rule always wins) -- fixed, link now loads
   immediately before </head>.

   WITHDRAWN: v3 assumed the language item's ~550px came from
   gtranslateSettings' "horizontal_position":"inline" rendering all
   10 flags permanently inline. Reading popup.js's actual widget
   construction disproves this: it builds exactly ONE inline trigger
   element (<a class="gt_switcher-popup"> containing the current
   flag + name + arrow) plus a language list that popup.js's own
   injected CSS sets to `display:none; position:fixed` -- removed
   from layout flow entirely, so it cannot affect flex-item width
   even when "open". No theme CSS overrides that hiding rule either
   (checked). So the widget is already the compact trigger+popup
   pattern; there is no inline ten-flag presentation to replace, and
   the measured 555px (like the account item's 645px) is most likely
   the same post-wrap flex-stretch artifact, not genuine content
   width -- this cannot be confirmed without the items' true
   unwrapped widths, which requires a live browser measurement I do
   not have.

   Given that, a large forced breakpoint is no longer justified by
   evidence. Restoring the more conservative, previously-reasoned
   1500px cap (calc from the confirmed 1200px first-seven-item budget
   plus modest headroom for login+switcher) and removing the forced
   mobile-switch -- the theme's own original 1100px breakpoint
   (unmodified, already correct) is the only fallback until a real
   measurement justifies a specific wider one. NOT a measured exact
   fit; flagged pending confirmation, same as before.

   UPDATE: the audit that passed 1534px one-row was measured while
   decorative section icons were hidden (text-only desktop links).
   A later round explicitly reversed that and restored icons, which
   adds back width this cap didn't need to cover before -- the new
   screenshot evidence (language control dropping to row 2) is very
   plausibly a direct, mechanical consequence of that restoration,
   not a new unrelated regression. Bumped the cap accordingly and
   trimmed the icon footprint below (smaller box, smaller gap) to
   partially offset it, rather than only pushing the number up
   blindly. Still not a measured exact fit.

   UPDATE 2: audit 9 measured the STICKY clone specifically still
   capped at 1200px wide, at a window wide enough that this rule's
   1650px value should have applied. The theme's own sticky-header
   script clones the masthead at runtime (confirmed: no #phantom
   element exists in the static HTML, so it is JS-created) and very
   plausibly sets sizing via inline style when positioning that
   clone, the same way many sticky-header scripts do -- an inline
   style with no !important still outranks this rule as previously
   written. Added !important so this value wins regardless of
   whether the constraint comes from a stylesheet or an inline style
   set by that script. Still not a measured exact fit. */
.masthead:not(.side-header):not(.side-header-menu-icon) .header-bar {
  max-width: calc(1650px) !important;
}

/* GTranslate language popup placement, corrected.
   Read popup.js's own injected CSS directly: .gt_white_content is
   `position:fixed; top:50%; left:50%` with a JS-computed negative
   margin (-height/2, -width/2) -- a classic viewport-centred modal,
   NOT positioned relative to the trigger button at all (my previous
   attempt's `top:100%` assumed the latter and would have pushed it
   almost entirely below the viewport instead -- withdrawn before it
   shipped anywhere).
   The real bug, found by reading popup.js's actual DOM calls: it
   builds this rule's CSS text into a <style> element created with
   `document.createElement('style')` and appended via
   `document.head.appendChild(add_css)` AT RUNTIME, on every page
   load -- after every static <link> in <head>, regardless of where
   mine is placed. Same selector, same specificity as my previous
   attempt; the later-appended rule in the DOM always wins, so that
   fix was silently overridden by the plugin's own injected
   `top:50%` + negative-pixel-margin rule every single time, exactly
   as it originally was. Confirmed this is unfixable by load order
   alone (nothing I place in a static <link> can load after a
   runtime-appended <style>) -- the only way to reliably win is
   !important on every geometry property that injected rule sets
   (top, left, width, height, margin), not just some of them.

   STILL BROKEN after that fix -- measured rect at 1534x855 was
   [668,-96,184,363], nowhere near where `top:50%` on an 855px
   viewport should place a 363px-tall centred box (~246px, not -96).
   Root cause, found in main.min.css: `.masthead:not(#phantom):
   not(.no-slider){transform:translateY(-100%)}` -- our masthead
   matches this (no #phantom id, no .no-slider class) and so always
   carries a `transform`. Per the CSS spec, ANY non-none transform on
   an ancestor becomes the containing block for `position:fixed`
   descendants -- not the viewport -- regardless of what value that
   transform eventually animates to once a theme/JS "reveal" state
   is applied; the property merely being present is what matters.
   So `top:50%` was resolving against the masthead's own (~170px)
   box, not the 855px window -- but this was STILL wrong even with
   `vh`/`vw`: those fix the computed magnitude, not the reference
   origin the browser measures from, which remains the hijacked
   ancestor's box for a position:fixed element whose containing
   block that ancestor became. Superseded below.

   v3: per the explicit request to anchor the popup beside/below its
   trigger rather than centre it in a modal, and to stop treating
   vh/vw as sufficient, the centring properties (top/left/transform)
   are now set by the companion JS (index.html) directly as inline
   styles with priority "important", computed from the trigger's own
   getBoundingClientRect() and clamped to the viewport -- an inline
   !important declaration outranks any external-stylesheet
   !important of equal origin, so it reliably wins over this file's
   rule and over popup.js's own injected one. This stylesheet now
   only sets the safety-net properties that don't depend on the
   trigger's position: still fixed, auto width/height so content
   isn't force-stretched, zero margin so popup.js's own negative-
   pixel margin never applies, and viewport-capped max-height/width
   with scrolling so the box can never exceed the screen regardless
   of where the JS places it. */
.gt_white_content {
  position: fixed !important;
  width: auto !important;
  height: auto !important;
  margin: 0 !important;
  max-height: 90vh !important;
  max-width: 90vw !important;
  overflow-y: auto !important;
  border: 1px solid rgba(0, 0, 0, 0.1) !important;
  box-shadow: 0 8px 24px rgba(0, 0, 0, 0.15) !important;
}

/* Chrome audit found this overlay (fixed, full-width, 1519x170 in
   that test) was intercepting real clicks to the navbar/trigger
   underneath it while "open" -- confirmed cause: it stayed in normal
   hit-testing even though invisible. pointer-events:none removes it
   from hit-testing entirely, so real clicks reach the navbar again.
   Its own click-to-close handler (popup.js's own code) can no longer
   fire via real hits, so outside-click-to-close is reimplemented via
   the companion script (index.html): a document-level listener
   detects a click outside the trigger/content and dispatches a
   synthetic click directly on this element -- dispatchEvent still
   invokes its handler regardless of pointer-events, which only
   governs real hit-testing, not programmatic dispatch -- reusing the
   plugin's own close function rather than duplicating it. */
.gt_black_overlay {
  background: transparent !important;
  opacity: 0 !important;
  pointer-events: none !important;
}

/* Kalpurush: self-hosted, SIL Open Font License v1.0, official source
   https://omicronlab.com/download/fonts/kalpurush.ttf -- license
   verified from the font's own embedded metadata, recorded alongside
   it at wp-content/uploads/the7-css/fonts/KALPURUSH-LICENSE.txt. */
@font-face {
  font-family: "Kalpurush";
  src: url("fonts/Kalpurush.ttf") format("truetype");
  font-display: swap;
}

/* Language-appropriate type, applied only where lang is actually set.
   Arabic keeps the theme's existing font and RTL behaviour untouched;
   icon fonts (icomoon/FontAwesome) set their own font-family on the
   icon element itself, which overrides this inherited value by normal
   CSS cascade rules, so they are unaffected regardless of html lang.
   GTranslate sets html lang="en" while translated and leaves it
   lang="auto" by default (verified via the Chrome audit) -- these
   rules only ever match the translated state, never the default
   Arabic one.

   Residual Arabic ("becomes Inter" in the audit): corrected from the
   previous round's broken attempt, which used `src: local("Cairo")`
   in a same-name @font-face override -- local() only matches fonts
   installed on the user's OS, never an already-loaded web font, so
   that override would have silently failed for virtually everyone.
   The actual fix needs no @font-face trick at all: Cairo and Tajawal
   are both already loaded via real <link> tags elsewhere on this
   page (confirmed: href="...css2?family=Tajawal...", href="...
   family=...Cairo:700..."). Listing them as plain font-family stack
   fallbacks is enough -- Inter/Hind Siliguri/Kalpurush genuinely lack
   Arabic glyphs, so the browser's normal per-character fallback
   already renders any Arabic-range character via the next font in
   the same stack, with no unicode-range declaration needed. Matches
   the original site's own split: headings use Cairo, body/menu text
   uses Tajawal (confirmed by the audit). A declared font-family is
   not proof of the rendered glyph -- this relies on standard,
   verifiable per-character font substitution, not a claim about the
   declared value alone.

   Page-wide coverage: set the body-text font on :lang() itself (an
   inherited property), which cascades to every descendant -- navbar,
   headings, body, footer, dynamically-translated text alike -- then
   override specifically for headings. This replaces the previous
   round's hand-picked p/li/a/span list, which could not have reached
   every container tag on the page.

   lang-attribute reliability: I cannot independently verify from
   static files alone whether `html[lang]` always tracks the actually
   *displayed* language without lag -- that needs live browser
   observation I don't have. The Chrome audit separately reported a
   `translated` class appearing on <html> while GTranslate is active;
   adding it as a parallel qualifier (OR'd with :lang(), not
   replacing it) means the rule fires if either signal is present,
   without my inventing a mechanism neither of us has confirmed. */
/* Icon font protection. The audit found 4 nav icons (Media Center,
   Contact Us, Coaches, Centers -- all FontAwesome, `class="fa-fw fas
   fa-*"`) computing to Kalpurush/Tajawal instead of their own font.
   FontAwesome's own CSS sets `.fas{font-family:"Font Awesome 5
   Free"}` with NO !important, so it is not protected against being
   outranked; notranslate (already applied) stops Google wrapping the
   glyph in a <font> element, but does not address a plain CSS
   cascade override, which is a separate failure mode. Restoring each
   known icon class's own font-family explicitly with !important,
   rather than relying on specificity/inheritance ordering to resolve
   in its favour on its own. */
.fa-fw, .fas, .far {
  font-family: "Font Awesome 5 Free" !important;
}
.fab {
  font-family: "Font Awesome 5 Brands" !important;
}
[class*="icomoon-the7-font"] {
  font-family: "icomoon-the7-font" !important;
}

:lang(bn),
html.translated[lang="bn"] {
  font-family: "Kalpurush", "Tajawal", sans-serif;
}
:lang(bn) h1,
:lang(bn) h2,
:lang(bn) h3,
:lang(bn) h4,
:lang(bn) h5,
:lang(bn) h6,
html.translated[lang="bn"] h1,
html.translated[lang="bn"] h2,
html.translated[lang="bn"] h3,
html.translated[lang="bn"] h4,
html.translated[lang="bn"] h5,
html.translated[lang="bn"] h6 {
  font-family: "Hind Siliguri", "Cairo", sans-serif;
}
:lang(en),
html.translated[lang="en"] {
  font-family: "Inter", "Tajawal", sans-serif;
}
:lang(en) h1,
:lang(en) h2,
:lang(en) h3,
:lang(en) h4,
:lang(en) h5,
:lang(en) h6,
html.translated[lang="en"] h1,
html.translated[lang="en"] h2,
html.translated[lang="en"] h3,
html.translated[lang="en"] h4,
html.translated[lang="en"] h5,
html.translated[lang="en"] h6 {
  font-family: "Inter", "Cairo", sans-serif;
}