/**
 * Shared BASE styling — one file, both estates.
 *
 * The harmonisation layer: the typography and colours that should look the same
 * whether you are on brambleski.com or in the CRM. Loaded by BOTH sites, so a
 * change here lands on both — the same arrangement as the shared site header
 * (core/navigation/header/).
 *
 * ── What belongs here ────────────────────────────────────────────────────
 *   YES  base typography, brand colours, link colour — things that define
 *        "this is Bramble" and should never differ between the two sites.
 *   YES  the SITE HEADER + mega-panel styling (merged in 1 Aug 2026 — see the
 *        big banner further down for why the separate header.css is gone).
 *   NO   other component styling. The CRM utility bar, data tables, its popup
 *        and SqueezeBox chrome are CRM-only and stay in the template's own CSS.
 *   NO   page-builder/layout rules. Those are website-specific.
 *
 * ── ⚠⚠ CASCADE POSITION — LOAD-BEARING, AND IT CHANGED ON 1 AUG 2026 ─────
 * This file must load **AFTER the CRM's legacy stack**
 * (plugins / app / style / frontend / backend / global / new-site / ipad /
 * ie_fixes). It used to load BEFORE them, as an overridable foundation, back
 * when it carried typography only.
 *
 * It moved because it now also carries the header rules, and those MUST beat
 * `global.css` / `backend.css`, which style `.newmenu` as a top-level bar with
 * `position: fixed` and hover-only sub-menus. Lose that and the account panel
 * renders column headings with every module menu invisible.
 *
 * Moving it late costs nothing on the typography side — measured 1 Aug 2026:
 * only THREE bare-element rules in the whole legacy stack could tie with the
 * `body, p, a, ul, li` rule below, and none of them sets font-family or color.
 * Full evidence in the header banner further down.
 *
 * ⚠ Order settles TIES only — it does not beat a class-scoped legacy rule.
 * Deleting the legacy sheets is what actually wins; this just removes order as
 * a variable while that happens.
 *
 * ⚠ It is GLOBAL typography, which is exactly the category that made loading
 * the website's page-builder.css into the CRM unacceptable (it restyles every
 * legacy page, data tables included). That is the intent here — but it means
 * changes to this file are site-wide on two estates. Treat accordingly.
 *
 * ── Phase-out ledger ─────────────────────────────────────────────────────
 * Rules MOVED here (delete the originals as each is verified):
 *   - body font-family + colour
 *       · CRM  templates/bramble-beta/css/master_style.css  (body, lines 5-8)
 *       · CRM  themes/bramble/css/app.css                   (body, line 17)
 *       · WP   css/page-builder.css                         (body, p, a, ul, li)
 *
 * ⚠ master_style.css must NOT be deleted wholesale — it also carries the
 * SqueezeBox modal layout (#sbox-*, referenced by 121 live files) and the
 * .new_popup_table legacy popup styling (14 live files). Remove the body rule
 * only.
 *
 * @see core/navigation/header/CLAUDE.md — the same shared-asset pattern
 */

/* Adobe Fonts (Typekit) — Proxima Nova. Self-contained so either estate gets
   the kit by loading this one file. The CRM's CSP already allows use.typekit.net
   and p.typekit.net in style-src and font-src. */
@import url("https://use.typekit.net/clp8wjy.css");

/* --- Base typography ------------------------------------------------------ */
/*
 * Exactly the website's long-standing rule, now applied to both estates.
 *
 * `a` is included deliberately: the CRM's teal link colour (rgba(14,94,88,1))
 * is RETIRED — links take the same #2C2C2C as body text, as they do on
 * brambleski.com, and are distinguished per-context rather than by colour.
 *
 * ⚠ Consequence to keep an eye on: in dense CRM tables that teal was the cue
 * for "this is clickable". Anywhere that reads poorly now wants a local
 * affordance (underline, or a .cm-* link class) rather than bringing the teal
 * back globally.
 */
body,
p,
a,
ul,
li {
    font-family: proxima-nova, sans-serif;
    color: #2C2C2C;
}

/* --- Base metrics: line-height, weight, paragraph rhythm ------------------
 *
 * Moved from `2023/css/page-builder.css` on 1 Aug 2026 so body copy reads the
 * same on both estates. These are the LAST of the shared typography — the CRM
 * previously took its metrics from whichever legacy sheet happened to win.
 *
 * ⚠ MEASURED IMPACT before the move (CRM `manage-v2`, 1920px), because these are
 * bare-element rules and that is the category this file is most dangerous in:
 *     p          14px    → 15.2px   (11 elements on that page)
 *     p          21px    → 24.32px  line-height
 *     td         19.5px  → 20.8px   line-height, across 3,922 cells
 *     page       8,763px → 9,020px  (+257px, +2.9% taller)
 * `td` FONT-SIZE does not move (13px — a more specific rule holds it), so the
 * "tables jump 14px → 16px" failure that made page-builder.css unloadable in the
 * CRM does NOT occur. The cost is density only, and it was accepted knowingly.
 *
 * ⚠⚠ `.fs-5 { font-size: calc(1.1rem) !important }` was DELIBERATELY NOT brought
 * across. It is not base typography — it is the website OVERRIDING a Bootstrap
 * utility, and sharing it would make `.fs-*` mean something different in the CRM
 * from what Bootstrap documents (78 `.fs-*` elements on that one page; it would
 * shrink 20 of them). The panels do not need it: `.submenu-title` already
 * measures 20px on both estates. Leave it in page-builder.css.
 *
 * 🚩 `p, .p-fs` was declared TWICE in page-builder.css — `1.1rem` then `0.95rem`.
 * The later won there, so 0.95rem is the live value and the one reproduced here.
 * Copy the wrong one and every paragraph on the website changes size.
 *
 * ✅ ALL FOUR ORIGINALS WERE REMOVED FROM page-builder.css (1 Aug 2026) — this
 * file is now the only home, so there is nothing to keep in sync. The removal was
 * a byte-safe excision (that file contains BINARY BYTES; a re-serialising edit
 * corrupts it and `grep` needs `--text`): ranges asserted before cutting, spliced
 * bottom-up, 55,966 → 55,769 bytes, control bytes 3 → 3 preserved, braces
 * 665/665 → 661/661. WordPress verified unchanged afterwards, document height
 * identical at 11,745px.
 * ------------------------------------------------------------------------- */
body,
p {
    line-height: 1.6;
    font-size: 1rem;
    font-weight: 400;
}

p {
    margin-top: 0;
    margin-bottom: 1rem;
}

p,
.p-fs {
    font-size: 0.95rem !important;
}

/* --- Headings: the second brand font --------------------------------------
 *
 * ⛔ DELIBERATELY NOT HERE — reverted to page-builder.css, 29 July 2026.
 *
 * The Ivypresto heading rule (`h1..h5, .fs-1….fs-6, .display-*, .fs-presto`)
 * briefly lived here as part of the harmonisation. It has been moved BACK to
 * `css/page-builder.css`, which is WordPress-only — the CRM deliberately
 * does not load it. Decision: the second brand font is a WEBSITE typeface, and
 * the CRM stays entirely on Proxima Nova. Do not re-add it here; the whole
 * point is that this file no longer carries it onto both estates.
 *
 * ⚠ Known, accepted consequence: the shared header's mega-menu panels set their
 * resort names with `fs-1` / `fs-4` / `fs-5` / `fs-presto` (measured: 42/53/56/7
 * occurrences across the seven cached panels). Those panels render in the CRM
 * too, so in the CRM they now fall back to Proxima. On the website they are
 * unaffected — page-builder.css covers them there. If the CRM's panels are ever
 * wanted in Ivypresto, scope a rule to the HEADER SECTION of this file (e.g.
 * `.header_3_design .submenu-title`) — do NOT bring the global rule back here.
 * ⚠ `header.css` no longer exists; it was merged into this file 1 Aug 2026.
 *
 * @see core/navigation/header/CLAUDE.md
 */

/* --- Letter-spacing utilities --------------------------------------------- */
/*
 * Moved from page-builder.css so the class means the same thing on both
 * estates. The website's markup uses them (the mega-menu resort names are
 * `fs-1 … ls-3`), and they did nothing in the CRM until this file carried them,
 * because the CRM does not load page-builder.css.
 *
 * ⚠ `cm_page_title()` NO LONGER emits `ls-2` (retuned 29 Jul 2026 to
 * `fs-3 fw-bold text-uppercase mt-5 mb-4`), so the CRM currently has no consumer
 * of these. They stay because the website's markup depends on them and because a
 * CRM page can still opt in by adding the class.
 *
 * `!important` is carried over from the original, deliberately — these are
 * utilities meant to beat component styling, and dropping it would change
 * behaviour on the website.
 */
.ls-3 { letter-spacing: 3px !important; }
.ls-2 { letter-spacing: 2px !important; }
.ls-1 { letter-spacing: 1px !important; }
.ls-0 { letter-spacing: 0px !important; }

/* ---------------------------------------------------------------------------
 * LAYOUT CONTAINERS — the shared page-width primitives (moved here 29 Jul 2026)
 *
 * These lived in `core/navigation/header/header.css`, which is the site header's
 * COMPONENT stylesheet — the wrong home for a generic layout utility the whole
 * page depends on. They are exactly what this file is for: generic utilities
 * that should never differ between the two estates.
 *
 * The move also killed a duplicate: the CRM carried its own `.bs-container-80`
 * in `templates/bramble-beta/css/backend.css`, added under the belief that the
 * CRM never loads the file defining it. That was true of the website's
 * `page-builder.css`, but stopped being true when the shared header landed and
 * began emitting `header.css` on every CRM page. Deleted in the same change.
 *
 * ⚠⚠ CASCADE POSITION IS LOAD-BEARING. `.bs-h-container-95` is
 * `width:95%!important` and competes with Bootstrap's `.w-100`
 * (`width:100%!important`) — SAME specificity, so whichever sheet loads LATER
 * wins. This file loads after Bootstrap on BOTH estates (CRM: index.php:154 vs
 * the Bootstrap CDN link at :133 — WP: enqueue priority 99 vs `bootstrap-css` at
 * the default 10), which is the only reason 95% wins. Move this file earlier
 * than Bootstrap and the site header silently becomes full width.
 *
 * ⚠ The `max-width: 540px` line in each block is DEAD — the `max-width: 90%`
 * immediately after it overrides it. Preserved verbatim from the original rather
 * than tidied: rewriting inherited CSS during a move makes the move impossible
 * to verify as behaviour-preserving. Clean it up as its own change if wanted.
 * ------------------------------------------------------------------------- */
.bs-h-container-95 { width: 95% !important; }

@media (max-width: 576px) {
    .bs-container-95, .bs-container-90, .bs-container-80, .bs-container-70, .bs-container-60, .bs-container-50, .bs-container-40 {
max-width: 540px;
max-width: 90%
}
}

@media (min-width: 576px) {
    .bs-container-95, .bs-container-90, .bs-container-80, .bs-container-70, .bs-container-60, .bs-container-50, .bs-container-40 {
max-width: 540px;
max-width: 90%
}
}

@media (min-width: 768px) {
    .bs-container-95, .bs-container-90, .bs-container-80, .bs-container-70, .bs-container-60, .bs-container-50, .bs-container-40 {
max-width: 720px;
max-width: 90%
}
}

@media (min-width: 992px) {
    .bs-container-95, .bs-container-90, .bs-container-80, .bs-container-70, .bs-container-60, .bs-container-50, .bs-container-40 {
max-width: 960px;
max-width: 90%
}
}

@media (min-width: 1200px) {
    .bs-container-95, .bs-container-90, .bs-container-80, .bs-container-70,   .bs-container-50, .bs-container-40  {
max-width: 1140px;
max-width: 90%
}
}

@media (min-width: 1300px) {
    .bs-container-95 {max-width: 95%}
}

/* ⚠⚠ THE PER-CONTAINER LADDER — the half of this family the 29 Jul move MISSED.
 *
 * The blocks above are the GENERIC ones: they flatten every container to 90% on
 * Bootstrap's breakpoints. On their own they are wrong — they make a
 * `.bs-container-40` render at 90%. The real widths come from the ladder below,
 * which page-builder.css defines on its own **700/800/900/1100/1300** breakpoints
 * (note: NOT Bootstrap's). The 29 Jul move copied the generic blocks and left the
 * ladder behind; because base.css loads later, its flat 90% then overrode the
 * whole ladder.
 *
 * That was invisible locally in the one place anyone looked (95% and 90% happen to
 * be right either way) and invisible on prod (base.css is not deployed there yet),
 * so the two estates silently disagreed.
 *
 * MEASURED 1 Aug 2026 @1920px — live www.brambleski.com vs local, before the fix:
 *     .bs-container-95    1822.4  (95%)   1822.4  (95%)   ok by luck
 *     .bs-container-90    1714.5  (90%)   1714.5  (90%)   ok by luck
 *     .bs-container-80    1524    (80%)   1714.5  (90%)   ✗
 *     .bs-container-60    1143    (60%)   1714.5  (90%)   ✗
 *     .bs-container-40     762    (40%)   1714.5  (90%)   ✗
 *
 * ⚠ Order matters: this must stay AFTER the generic blocks, or the flat 90% wins
 * again. Copied verbatim from page-builder.css, in its original source order.
 *
 * ⚠ NOT copied, deliberately: the three compound `.full_width_1400.bs-container-80`
 * / `.full_width_1200.bs-container-90` / `.full_width_1200.bs-container-80` rules.
 * They pair a container with a website PAGE-BUILDER class, so they can only ever
 * match on brambleski.com — the same call the 29 Jul move made for the other
 * compounds.
 * ------------------------------------------------------------------------- */
@media (min-width: 700px) {
    .bs-container-60 { max-width: 90%; }
    .bs-container-40 { max-width: 90%; }
}

@media (min-width: 800px) {
    .bs-container-60 { max-width: 80%; }
    .bs-container-40 { max-width: 80%; }
}

@media (min-width: 900px) {
    .bs-container-60 { max-width: 70%; }
    .bs-container-40 { max-width: 60%; }
}

@media (min-width: 1100px) {
    .bs-container-60 { max-width: 60%; }
    .bs-container-40 { max-width: 60%; }
}

@media (min-width: 1300px) {
    .bs-container-100 { max-width: 100%; }
    .bs-container-90  { max-width: 90%; }
    .bs-container-80  { max-width: 80%; }
    .bs-container-70  { max-width: 70%; }
    .bs-container-60  { max-width: 60%; }
    .bs-container-50  { max-width: 50%; }
    .bs-container-40  { max-width: 40%; }
}

/* The compound overrides that pair a container with a website PAGE-BUILDER class
   — `.collections_slider.bs-container-90`, `.blog_four_posts .bs-container-95`,
   `.full_width_90.bs-container-95`, `.full_width_768.bs-container-95` — were kept
   OUT of this section because they can only ever match on the website. They now
   live further down, in the header section merged in on 1 Aug 2026. */

/* ===========================================================================
 * SITE HEADER + MEGA PANELS  (merged in from header.css, 1 Aug 2026)
 * ===========================================================================
 *
 * `core/navigation/header/header.css` was a separate file until 1 Aug 2026. It
 * was merged here because the split had no remaining justification and cost
 * more than it bought — see below.
 *
 * ── The ONLY reason the split existed ────────────────────────────────────
 * The two files sat on OPPOSITE SIDES of the CRM's nine legacy stylesheets:
 * base.css loaded 3rd (before them) as an overridable foundation; header.css
 * loaded 27th (after them) because it must BEAT `global.css` / `backend.css`,
 * which style `.newmenu` as a top-level bar with `position: fixed` and
 * hover-only sub-menus. Lose that fight and the account panel renders column
 * headings with every module menu invisible.
 *
 * ── Why merging is safe (MEASURED 1 Aug 2026, not assumed) ────────────────
 * Cascade ORDER only decides ties at EQUAL specificity. Across all nine legacy
 * sheets there are exactly THREE bare-element rules that could tie with this
 * file's `body, p, a, ul, li`, and NONE of them sets font-family or color:
 *     frontend.css:177  body { height: 100% !important }
 *     app.css:38        a, … { text-decoration: none }
 *     app.css:2070      @media(min-width:768px) body { font-size: 14px }
 * Every legacy `font-family` declaration (14 in total) is class- or ID-scoped
 * (`.welmsg input`, `#com_crmery …`, the Kalinga rules in master_style.css), so
 * it beats a bare-element rule REGARDLESS of order. The one rule that genuinely
 * forced the early position — app.css's bare `a { color: teal }` — was deleted
 * on 28 Jul 2026. So there is nothing left for this file to lose a tie against,
 * and it can safely take the LATE position the header half requires.
 *
 * ⚠⚠ THIS FILE MUST NOW LOAD **AFTER** THE CRM'S LEGACY STACK.
 * On the CRM that means after `global.css` / `backend.css` in
 * `templates/bramble-beta/index.php`. Move it earlier and the account panel
 * breaks — that is the one behaviour here that genuinely depends on order, and
 * it is not subtle: 15 nested `.newmenu` <ul>s flip from `display:block;
 * position:static` to `display:none; position:fixed`.
 *
 * ⚠ Order buys LESS than it looks. It settles ties only; it does not make this
 * file beat a class-scoped legacy rule. Retiring the legacy sheets is what
 * actually wins — this merge just removes order as a variable while that
 * happens.
 *
 * ── Provenance of the rules below ────────────────────────────────────────
 * They were extracted from `2023/css/page-builder.css` on 27 Jul 2026 (the CRM
 * cannot load that file: 19 bare-element rule blocks in it restyle the whole
 * app, measured table font 14px → 16px).
 *
 * 🚩 That extraction matched on SELECTOR NAME and so was incomplete: 14 rules
 * that style the mega panels remain in page-builder.css because they carry no
 * header class (`.w-80`, `.fs-5`, `.special_line`, `.submenu_sidemenu a`, …).
 * The CRM gets none of them, which is why its panels still differ from the
 * website's. See core/navigation/header/CLAUDE.md.
 *
 * ⚠ GREPPING page-builder.css: it contains binary bytes, so `file` reports it as
 * `data` and PLAIN GREP SILENTLY PRINTS NOTHING. Always pass `--text`.
 * ------------------------------------------------------------------------- */


/* `.bs-h-container-95` and the `.bs-container-*` family MOVED to
   core/shared/base.css (29 Jul 2026) — they are generic page-width utilities,
   not header styling, and the CRM needs them for its content region too.
   Both estates already load base.css, so nothing needed re-wiring. */
.account_menu ul.dropdown-menu {margin-top: -3px}
.submenu_content {
opacity: 0;      /* Start with zero opacity */
height: 0;       /* Start with zero height */
overflow: hidden;
transition: opacity 0.5s ease-in-out, height 0.5s ease-in-out; /* Add transitions */
}
.submenu_content.active {
opacity: 1;      /* Fully visible */
height: auto;    /* Auto height, expanding the element */
}
.header_3_design{}
.header_3_design .navbar-nav > li.nav-item > a, .header_3_design .navbar-nav > li.nav-item > .btn-group > a,  #search-menu button{
color: #FFF;
padding: 36px 17px 35px;
font-size: 16px;
letter-spacing: 1px;
text-transform: none;
}
.header_3_design .navbar-nav > li.nav-item > a.thin-headermenu-left  {

margin-left: 7px
}
.header_3_design .navbar-nav > li.nav-item > a.thin-headermenu, .header_3_design .navbar-nav > li.nav-item > .btn-group > a.thin-headermenu,  #search-menu button {
font-size: 18px;
padding: 34px 10px 35px; 
}
.header_3_design .navbar-nav > li.nav-item > a.thin-headermenu-right, .header_3_design .navbar-nav > li.nav-item > .btn-group > a.thin-headermenu-right   {

padding-right:0
}
.header_3_design .logo-white {
color: #FFF;
}
.header_3_design .collapse.navbar-collapse{
float: right;  
}
.header_3_design .navbar-nav > li.nav-item {
width: auto;
text-align: center;
}
.header_3_design .navbar-nav.ml-auto{  float: right; }
.header_3_design .bs_logo {
height: 65px;
width: 200px;
text-align: left;
align-self: baseline;
}
.header_3_design .navbar-nav > li > .dropdown-menu {

}
.header_3_design.bg-body-tertiary  .logo-white {
color: #202020; 
}
.header_3_design.bg-body-tertiary  .navbar-nav > li.nav-item > a ,  .header_3_design.bg-body-tertiary  .navbar-nav > li.nav-item > .btn-group > a, .header_3_design.bg-body-tertiary #search-menu button {
color: #202020;
}
.header_3_design.bg-body-tertiary{
border-bottom: 1px solid #CACACA; 
box-shadow: 1px 1px 6px 0px rgba(202, 202, 202, 0.5)}
.header_3_design .dropdown-menu {
border: 0;
border-top-right-radius: 0;
border-top-left-radius: 0;

}
.header_3_design .navbar-nav > li > .dropdown-menu{
opacity: 0;
visibility: hidden;
display:block;

transition: opacity 0.2s ease, visibility 0.2s ease;
margin-top: 1px!important }
.header_3_design .navbar-nav > li.show > .dropdown-menu{

opacity: 1;
visibility: visible;
}
.navbar-nav > li.nav-item.account_menu .dropdown-item {
text-transform: none;
letter-spacing: normal;
}
/* ⚠⚠ z-index 1030 = Bootstrap's `$zindex-fixed`, the layer a fixed header belongs on.
   It is declared HERE, not as a `.z-3` utility in header.php, and that matters (Aug 2026).

   `position: fixed` + a z-index makes this element a STACKING CONTEXT, so the mega
   panels' own `z-index: 1000` is sealed inside it and counts as the header's value
   against the rest of the page. At `.z-3` that meant **3** — so on the CRM, whose pages
   are full of Bootstrap-layer components, anything above 3 covered the navigation. The
   deals Filters panel (999) did exactly that: measured on Bookings, the mega panel spans
   y 100-604 and the panel y 282-885, and the panel won all 322px of the overlap.

   1030 slots the whole header correctly against the rest of the stack:
       toolbar dropdowns 999  <  HEADER 1030  <  offcanvas 1045  <  modal 1055
   so modals and offcanvas still open over the header, and page content never does.

   ⚠ The website was unaffected only because nothing there uses high z-indexes — it was
   always wrong, just invisible. Do not "restore" the utility class.
   ⚠ Keep the backdrop one step below the header: it must dim the PAGE, not the nav. */
.topnav_menu {
z-index: 1030;
transition: all 0.4s ease;
opacity: 1;
}
.topnav_menu.hide-menu {
opacity: 0;
transform: translateY(-100%);
}
.menu_background {
z-index: 1020;
opacity: 0;
transition: opacity 0.4s; /* Change duration as you like */

}
.menu_background.active {
opacity: 0.8; 
}
.wide_menu .dropdown-menu {
	width: 106% !important;
	left: -3% !important;
	top: 100%;
}
.icon-hamburger,
.icon-close {
transition: opacity 0.3s ease;
}
.icon-hamburger {
opacity: 1;
}
.icon-close {
opacity: 0;
position: absolute;
top: 50%;
left: 50%;
transform: translate(-50%, -50%);
}
.navbar-nav > li.nav-item .aboutmenu-item p a {
	font-size: 1.1rem;
	text-transform: none;
	letter-spacing: 0;
	color: #2C2C2C;
}
@media screen and (max-width: 992px) {
    .header_3_design .navbar-nav > li.nav-item > a, .header_3_design .navbar-nav > li.nav-item > .btn-group > a {

padding: 16px 17px 15px;
font-size: 24px; 
}
}

.navbar-nav > li.nav-item_fullhover:hover, .bg-body-tertiary .navbar-nav > li.item_fullhover_nm{
background: #F0D8BD!important; 
background: #b49b56!important;   

}
.navbar-nav > li.nav-item_fullhover:hover > a, .bg-body-tertiary .navbar-nav > li.item_fullhover_nm a {
color: #FFF !important 

}
.item_fullhover_icon:hover a, 
.item_fullhover_icon:hover button, 
.bg-body-tertiary #search-menu button:hover   , 
.bg-body-tertiary .item_fullhover_icon:hover a{  color: #b49b56!important;   }
.header_3_design .form-control.bramble-form-control{background-color: transparent; color:#ffffff;}
.header_3_design .form-control.bramble-form-control::placeholder{color:#ffffff;}
.header_3_design.bg-body-tertiary .navbar-nav > li.nav-item .form-control.bramble-form-control::placeholder{color:#202020;}
.header_3_design.bg-body-tertiary .navbar-nav > li.nav-item .form-control.bramble-form-control{color:#202020;}
/* The generic `.bs-container-*` responsive family MOVED to core/shared/base.css
   (29 Jul 2026). The compound overrides below stayed: each pairs a container with
   a website PAGE-BUILDER class, so they can only ever match on brambleski.com and
   are not shared layout primitives. */

@media only screen and (max-width: 1200px) {
    .collections_slider.bs-container-90, .blog_four_posts .bs-container-95, .full_width_90.bs-container-95 {
	width: 100% !important;
	max-width: 100%;
}
}

@media only screen and (max-width: 768px) {
    .full_width_768.bs-container-95 {
	width: 100% !important;
	max-width: 100%;
}
}

@media (min-width: 992px) and (max-width: 1100px) {
    .header_3_design .navbar-nav > li.nav-item > a, .header_3_design .navbar-nav > li.nav-item > .btn-group > a, #search-menu button {

	padding: 36px 10px 35px;
}
}

@media only screen and (min-width: 768px) and (max-width: 1400px) {
    .topnav_menu p, .topnav_menu  .p-fs {

font-size: 0.88rem !important;
}
}

@media only screen and (max-width: 768px) {
    #chalets .bs-container-95{max-width: 95%}
}

.header_3_design .bs_logo { transition: filter 0.3s ease; }
.header_3_design .bs_logo img { height: 72px; width: auto; }
.header_3_design.bg-body-tertiary .bs_logo img { filter: brightness(0); }
@media (max-width: 991.98px) {
    .header_3_design .bs_logo img { height: 63px; }
}

/* ---------------------------------------------------------------------------
 * Additions (28 Jul 2026) — NOT extracted from page-builder.css.
 * ------------------------------------------------------------------------- */

/*
 * Reveal a panel that BOOTSTRAP opened.
 *
 * The extracted rules only reveal "li.show > .dropdown-menu", which is what
 * WordPress's main.js sets on hover. Bootstrap 5's own dropdown JS puts .show on
 * the .dropdown-menu instead — so a CLICK-opened panel (the account panel, which
 * uses data-bs-toggle="dropdown") stayed opacity:0 / visibility:hidden and
 * appeared not to open at all.
 */
.header_3_design .navbar-nav > li > .dropdown-menu.show {
    opacity: 1;
    visibility: visible;
}

/*
 * Suppress Bootstrap's caret on header toggles.
 *
 * page-builder.css does this with a GLOBAL .dropdown-toggle::after rule, which
 * was deliberately NOT extracted (it carries no header class, and moving a
 * site-wide rule into this component would be wrong). The CRM does not load that
 * file, so it was drawing carets the website does not have. Scoped to the header.
 */
.header_3_design .dropdown-toggle::after {
    display: none;
}

/* ---------------------------------------------------------------------------
 * Mega-panel rules RECOVERED from page-builder.css (1 Aug 2026)
 *
 * The 27 Jul extraction matched on SELECTOR NAME, so it took only rules naming a
 * header class and left behind everything that styles the panels' *contents*.
 * The CRM never loads page-builder.css, so its panels lost them — measured
 * against the live WP header:
 *
 *     property              WordPress        CRM (before)
 *     sidemenu list-style   none             circle   ← bullets
 *     .w-80 column width    340.47px         425.59px ← no width cap
 *     title colour          rgb(32,32,32)    rgb(44,44,44)
 *
 * ⚠ These are SCOPED to `.header_3_design` deliberately. The originals are bare
 * utility selectors (`.w-80`, `.text-lightblack`) — copying them unscoped would
 * put website utility classes onto every CRM page, which is the whole reason the
 * CRM refuses page-builder.css.
 *
 * ⚠ Values are IDENTICAL to what WordPress already computes, so this changes
 * nothing there — it only stops the CRM from missing them. Verified before/after
 * on both estates.
 *
 * 🚩 The originals are still in page-builder.css. They are not duplicated *in
 * effect* (same value, and this file loads later), but if you ever change one,
 * change it here — the website reads whichever wins, and that is this file.
 * ------------------------------------------------------------------------- */
.header_3_design .submenu_sidemenu {
    list-style: none;
}

.header_3_design .submenu_sidemenu a {
    color: #202020;
}

.header_3_design .w-80 {
    width: 80%;
}

/* ---------------------------------------------------------------------------
 * Mega-panel HEADING FONT — Ivypresto on both estates (1 Aug 2026)
 *
 * Two things at once, both verified against the LIVE site (www.brambleski.com):
 *
 * 1. FIXES A PRODUCTION BUG. `page-builder.css` sets the panels' column headings
 *    with `.navbar-nav > li.nav-item .submenu_sidemenu a { font-family:
 *    "Leitura Two Bold" }` — a family with **no @font-face anywhere in the theme**
 *    (the declared ones are Roman/Medium/Bold/Black + italics) and **no fallback
 *    stack**. Measured on the live element: the title renders at 175.2px and the
 *    SAME text forced to `serif` renders at 175.2px — identical, i.e. the browser
 *    is substituting. The public site's main navigation has been rendering those
 *    headings in **Times**. In `ivypresto-display` the same string is 158.75px,
 *    so this rule visibly changes the website — that is the point, and it was
 *    signed off.
 *
 * 2. GIVES THE CRM PARITY. The selector list mirrors page-builder's own
 *    `h1..h5, .fs-*, .display-*, .fs-presto` heading rule, which the CRM never
 *    sees. Scoped to `.header_3_design`, so the CRM's own pages stay entirely on
 *    Proxima — the 29 Jul decision ("the second brand font is a WEBSITE typeface")
 *    is preserved everywhere except this shared component, which is exactly the
 *    exception that decision anticipated.
 *
 * ⚠ Ivypresto is real and loading: measured on live, `ivypresto-display` renders
 * distinctly from both `serif` and `proxima-nova` (473.33 / 494.72 / 527.05px at
 * 40px). It ships in the same Typekit kit (clp8wjy) both estates already load.
 *
 * ⚠ On WordPress every selector here EXCEPT `.submenu-title` already resolves to
 * Ivypresto via page-builder.css, so this is a no-op there — only the headings
 * change. Verified before/after on both estates.
 * ------------------------------------------------------------------------- */
/* ⚠⚠ SPECIFICITY, not just source order. page-builder.css sets the headings via
   `.navbar-nav > li.nav-item .submenu_sidemenu a` = (0,0,3,2). A plain
   `.header_3_design .submenu-title` is (0,0,2,0) and LOSES to it on WordPress —
   the first attempt at this rule changed the CRM and left the website on Times,
   i.e. it made the two estates differ MORE. This selector mirrors page-builder's
   own shape with the header class in front = (0,0,4,2), so it wins on both. */
.header_3_design .navbar-nav > li.nav-item .submenu_sidemenu a,
.header_3_design .submenu-title,
.header_3_design h1,
.header_3_design h2,
.header_3_design h3,
.header_3_design h4,
.header_3_design h5,
.header_3_design .fs-1,
.header_3_design .fs-2,
.header_3_design .fs-3,
.header_3_design .fs-4,
.header_3_design .fs-5,
.header_3_design .fs-6,
.header_3_design .display-1,
.header_3_design .display-2,
.header_3_design .display-3,
.header_3_design .display-4,
.header_3_design .display-5,
.header_3_design .display-6,
.header_3_design .fs-presto {
    /* Stack mirrors page-builder.css exactly (`ivypresto-display, Medium, serif`).
       `Medium` is a real @font-face on WordPress (LeituraTwo-Medium) and simply
       falls through to `serif` in the CRM, which does not declare it — so the
       rendered result is the same on both while the WP fallback chain is left
       exactly as the theme intended. */
    font-family: ivypresto-display, Medium, serif;
}

/* ---------------------------------------------------------------------------
 * Mega-panel LINK STATES + META TEXT — the rest of the stranded set (1 Aug 2026)
 *
 * The panels contain exactly three kinds of anchor (measured on the live WP
 * header — 11 / 11 / 7 of them per panel):
 *   1. `.submenu-title …`                     — resort column headings
 *   2. `.special_line .p-fs .text-lightblack` — chalet name links  ← GOLD HOVER
 *   3. `.normal-font .small-font …`           — the smaller sub-links
 * …plus `ul.chalet_meta.small-text`, the stat line rendered as
 * "410KM Slopes | 1500m Altitude | 55 Properties".
 *
 * Everything below was stranded in page-builder.css, so the CRM had: no gold
 * hover, no underline affordance, no `" | "` separators between the stats, and
 * meta text at full size instead of 0.8×.
 *
 * ⚠ SCOPED to `.header_3_design`. The originals are bare utility selectors
 * (`.small-font`, `.small-text`, `.normal-font`, `.text-lightblack`,
 * `.special_line`, `.p-fs`) — copying them unscoped would put website utility
 * classes onto every CRM page, which is exactly what the CRM refuses
 * page-builder.css for.
 *
 * ⚠ Values copied verbatim from page-builder.css, so WordPress is unchanged.
 * The `.header_3_design` prefix raises specificity by one class, which means
 * these WIN there too — same declarations, so no visible effect, but if you edit
 * one, edit it HERE: this file is what the website now reads.
 *
 * ⚠ `p, .p-fs` is declared TWICE in page-builder (1.1rem, then 0.95rem). The
 * later wins, so 0.95rem is the live value — and only the `.p-fs` half is ported;
 * the bare `p` is global typography and must never come across.
 * ------------------------------------------------------------------------- */
.header_3_design .special_line {
    position: relative;
    display: inline-block;
    text-decoration: none;
    transition: color 0.3s ease-in-out;
    letter-spacing: normal !important;
    text-transform: none !important;
}

.header_3_design .special_line::after {
    content: "";
    position: absolute;
    bottom: -3px;
    left: 0;
    width: 0;
    height: 2px;
    background-color: currentcolor;
    transition: width 0.3s ease-in-out;
}

.header_3_design .text-lightblack,
.header_3_design .navbar-nav > li.nav-item a.text-lightblack {
    color: rgb(44, 44, 44);
}

/* The gold hover. */
.header_3_design .special_line.text-lightblack:hover,
.header_3_design .navbar-nav > li.nav-item a.special_line.text-lightblack:hover {
    color: rgb(180, 155, 86) !important;
}

.header_3_design .text-gold,
.header_3_design .text-gold.special_line,
.header_3_design .navbar-nav > li.nav-item a.text-lightblack:hover {
    color: rgb(135, 101, 44) !important;
}

.header_3_design .special_line.text-gold:hover {
    color: rgb(219, 188, 143) !important;
}

/* Meta / sub-link sizing. */
.header_3_design .small-font { font-size: 0.8rem !important; }
.header_3_design .small-text { font-size: 0.8em; }
.header_3_design .p-fs      { font-size: 0.95rem !important; }

.header_3_design .text-standard,
.header_3_design .normal-font {
    font-family: proxima-nova, sans-serif !important;
}

/* "410KM Slopes | 1500m Altitude | 55 Properties" — the separator is CSS. */
.header_3_design .chalet_meta li:not(:last-child)::after {
    content: " | ";
}

/* ---------------------------------------------------------------------------
 * Nav-link line-height — STATED, not inherited (1 Aug 2026)
 *
 * The header links carried NO line-height of their own, so each estate inherited
 * a different ratio and the headers ended up different heights at mobile:
 *     WordPress  ~1.655  → phone link 98.8px  → header 99.8px
 *     CRM         2.0    → phone link 106px   → header 107px
 * (CRM ratio confirmed on two elements: 18px→36px and 24px→48px.) The CRM's
 * source could not be found in any readable stylesheet — it arrives by
 * inheritance through the legacy stack — which is exactly why the fix is to
 * STATE the value here rather than hunt and override it.
 *
 * ✅ MEASURED AFTER: both estates' phone link is now 24px/38.4px and both headers
 * are 99.8px at mobile — the CRM came down from 107px and **WordPress did not
 * move at all**. (I predicted WP would lose ~1px here; it did not, because its
 * inherited ratio was already close enough that the 34/35px padding dominated.
 * Stating the value cost WordPress nothing and fixed the CRM's 7px gap.)
 * `#rm_menu { top: 98px }` below assumes that ~98px header on both.
 * ------------------------------------------------------------------------- */
.header_3_design .navbar-nav > li.nav-item > a,
.header_3_design .navbar-nav > li.nav-item > .btn-group > a {
    line-height: 1.6;
}

/* ===========================================================================
 * MOBILE OFF-CANVAS  (#rm_menu) — recovered from page-builder.css, 1 Aug 2026
 * ===========================================================================
 *
 * ⚠⚠ `#rm_menu` is a SIBLING of `.header_3_design`, not a child — `header.php`
 * closes the header before emitting the off-canvas. So NONE of the
 * `.header_3_design`-scoped rules above reach it, and it needs its own scope
 * root. That is why the mobile menu still did not match after the desktop
 * panels did.
 *
 * The off-canvas BODY is fetched from WordPress (`bramble_menu_fetch('mobile')`)
 * and was already correct — 74 links on both estates. What was missing was its
 * styling, and crucially its BEHAVIOUR: `.content-section` is the slide-in
 * mechanism for the sub-panels, so without it the CRM's mobile sub-menus were
 * mispositioned and unscrollable, not merely differently styled.
 *
 * Measured before (CRM vs WP, ~570px): links 22.071px Proxima vs 17.2px
 * Ivypresto; no slide transition; no `top` offset.
 *
 * ⚠ `#rm_menu` / `#mob_menu` are IDs and unique, so those two are copied
 * verbatim. Everything else is scoped under `#rm_menu` — the originals are bare
 * utility selectors and must not leak onto CRM pages.
 *
 * ⚠ The `.fs-4` / `.fs-5` media overrides are scoped here DELIBERATELY. They are
 * the off-canvas's own type scale; the global `.fs-*` utilities stay untouched
 * (see the base-metrics banner — `.fs-5` was excluded from sharing on purpose).
 * ------------------------------------------------------------------------- */
#rm_menu { top: 98px; }
#mob_menu { position: relative; transition: transform 0.5s; }

#rm_menu.offcanvas { transition-duration: 0.5s; }

#rm_menu .content-section {
    position: absolute;
    top: 0;
    right: -100%;
    transition: transform 0.5s;
    width: 100%;
    height: calc(100vh - 75px);
    overflow-y: auto;
}

@media screen and (max-width: 992px) {
    #rm_menu .offcanvas-body { overflow-y: auto; }
}

#rm_menu h1,
#rm_menu h2,
#rm_menu h3,
#rm_menu h4,
#rm_menu h5,
#rm_menu .fs-1,
#rm_menu .fs-2,
#rm_menu .fs-3,
#rm_menu .fs-4,
#rm_menu .fs-5,
#rm_menu .fs-6,
#rm_menu .display-1,
#rm_menu .display-2,
#rm_menu .display-3,
#rm_menu .display-4,
#rm_menu .display-5,
#rm_menu .display-6,
#rm_menu .fs-presto {
    font-family: ivypresto-display, Medium, serif;
}

#rm_menu h1,
#rm_menu h2,
#rm_menu h3,
#rm_menu h4,
#rm_menu h5 {
    color: rgb(44, 44, 44);
    text-transform: none !important;
}

#rm_menu .text-lightblack { color: rgb(44, 44, 44); }
#rm_menu .text-beige      { color: rgb(219, 188, 143) !important; }
#rm_menu .mm_link         { letter-spacing: 3px; }

@media only screen and (min-width: 768px) and (max-width: 1400px) {
    #rm_menu .fs-5 { font-size: 1rem !important; }
}

@media only screen and (max-width: 768px) {
    #rm_menu .fs-5 { font-size: calc(1.1rem) !important; }
    #rm_menu .fs-4 { font-size: calc(1.075rem) !important; }
}

/* ===========================================================================
 * SITE FOOTER (.footer) — recovered from page-builder.css, 1 Aug 2026
 * ===========================================================================
 *
 * The CRM now renders the LIVE WordPress footer (fetched as the `footer`
 * fragment) instead of the hand-built 155-line copy it carried until 1 Aug 2026.
 * That copy shipped its own inline <style> block; these are the equivalent rules,
 * taken from page-builder.css so both estates read from one place.
 *
 * Measured on the CRM immediately after the fragment went live, before this
 * block existed — the markup was correct but unstyled:
 *     footer height   96px      (WordPress: 596px)
 *     heading colour  #2C2C2C   dark-on-dark, effectively invisible
 *     heading font    Proxima   (WordPress: Ivypresto)
 *     link colour     #2C2C2C   invisible on the dark background
 *     link size       10px      (WordPress: 12.8px)
 *
 * ⚠ Scoped to `.footer`. The originals are a mix of bare utility (`.text-tan`)
 * and component selectors; unscoped they would leak onto CRM pages.
 *
 * ⚠ Values copied verbatim, so WordPress is unchanged — the `.footer` prefix
 * raises specificity by one class, which means these win there too, with
 * identical declarations. Edit HERE, not in page-builder.css.
 * ------------------------------------------------------------------------- */
.footer .text-tan { color: rgb(219, 188, 142) !important; }

.footer .footer_menu ul { margin: 0; padding: 0; }

.footer .footer_menu li a {
    color: rgb(255, 255, 255);
    text-decoration: none;
    font-size: 0.8rem !important;
}

.footer .footer_menu li a:hover { color: rgb(219, 188, 143); }

.bg-dark.footer p { font-size: 0.8rem !important; }

.bg-dark.footer input {
    background: rgba(255, 255, 255, 0.3);
    font-size: 0.8rem !important;
    color: rgba(255, 255, 255, 0.6);
}

.bg-dark.footer button { background: rgba(255, 255, 255, 0.3); }
.bg-dark.footer button:hover { color: rgba(255, 255, 255, 0.6); }

/* Headings use the website's display serif, as they do on brambleski.com. */
.footer h1,
.footer h2,
.footer h3,
.footer h4,
.footer h5,
.footer .fs-1,
.footer .fs-2,
.footer .fs-3,
.footer .fs-4,
.footer .fs-5,
.footer .fs-6,
.footer .display-1,
.footer .display-2,
.footer .display-3,
.footer .display-4,
.footer .display-5,
.footer .display-6,
.footer .fs-presto {
    font-family: ivypresto-display, Medium, serif;
}

/* ⚠ `text-transform: none` is NOT cosmetic here — it is a fix.
   The CRM's global.css puts `h1, h2, h3, h4` in a `text-transform: uppercase`
   list, so the footer headings rendered UPPERCASE against the website's normal
   case. page-builder.css neutralises it there with the same `!important`; this
   reproduces that so both estates match. (Removing `h4` from the CRM's list
   would restyle every legacy CRM page, so it is overridden here, not deleted.) */
.footer h1,
.footer h2,
.footer h3,
.footer h4,
.footer h5 {
    text-transform: none !important;
}


/* ═══════════════════════════════════════════════════════════════════════════
 * ACCOUNT PANEL (Tier 2) — merged in from core/navigation/header/account-panel.css
 * on 2 Aug 2026. See the block comments below for what each part does.
 * ═══════════════════════════════════════════════════════════════════════════ */

/**
 * Account panel presentation — SHARED by both estates (Tier 2 navigation).
 *
 * Ships with the shared header component and is emitted by header.php itself
 * via $nav->assetUrl(), so WordPress and the Joomla CRM get it automatically
 * and there is only ever one copy.
 *
 * The panel's markup is the CRM's legacy `.newmenu` menu, written to be a
 * top-level horizontal bar. Inside the header's dropdown the dropdown IS the
 * panel, so its contents must simply be open and unadorned.
 *
 * ── What each block is for, and where it bites ───────────────────────────
 *  1. LIST RESET — needed on BOTH. Neither estate resets `<ul>` inside the
 *     dropdown, so the panel renders with browser-default bullets and a 32px
 *     indent (verified on both sites).
 *  2. UNDO LEGACY POSITIONING — only bites in the CRM, which loads global.css /
 *     backend.css. Those give `.newmenu` sub-menus `position: fixed` and hide
 *     them until hover, so the CRM showed column HEADINGS ONLY with every menu
 *     underneath invisible. On WordPress these rules are harmless no-ops (they
 *     restate defaults), which is why one shared file is correct rather than
 *     two platform copies.
 *  3. HEIGHT CAP — needed on both. A full admin menu is ~825px tall, so on
 *     anything smaller than a 1080p screen the lower items are unreachable
 *     without scrolling.
 *
 * RULES (per the CRM's core-modules/CLAUDE.md styling standards): every
 * selector is scoped under `.topnav_menu .account-panel` so nothing leaks — the
 * CRM's legacy template CSS loads on the same pages and `.newmenu` is used by
 * other chrome. No bare/global selectors. No `!important` — the scoped
 * selectors already out-specify the legacy rules.
 */

/* 1 + 2 — reset the list, and undo the legacy bar positioning/chrome. */
.topnav_menu .account-panel,
.topnav_menu .account-panel ul {
    list-style: none;
    margin: 0;
    padding: 0;
    position: static;
    float: none;
    width: auto;
    background: none;
    border: 0;
    box-shadow: none;
}

/* Every level open — the dropdown is the panel, not a hover trail.
   Must match ALL descendant lists, not just `> li > ul`: the module menus nest
   four levels deep, and targeting only the first level rendered the column
   headings with nothing under them. */
.topnav_menu .account-panel ul {
    display: block;
}

.topnav_menu .account-panel li {
    display: block;
}

/* 3 — never taller than the viewport. */
.topnav_menu .account_menu .dropdown-menu {
    max-height: calc(100vh - 120px);
    overflow-y: auto;
}

/* The hidden Availability item carries a season list that must STAY hidden —
   the "every level open" rule above would otherwise reveal it. */
.topnav_menu .account-panel > li[style*="display:none"] {
    display: none;
}

/* 4 — MATCH THE MARKETING PANELS' WIDTH.
 *
 * Every role branch wraps its columns in Bootstrap's `.container`, which is a
 * FIXED max-width ladder (540/720/960/1140/1320px), so the panel stopped at
 * 1320px and sat centred inside its own 95% wrapper. The six marketing panels
 * use `.bs-container-95` — a PERCENTAGE — so on a 1920px screen they ran to
 * ~1822px and the account panel to 1320px: visibly narrower content behind an
 * identically-sized dropdown.
 *
 * Neutralising the cap here makes `.container` behave as `.container-fluid`
 * INSIDE the panel only, so the width comes from the one wrapper that should
 * own it — `bs-h-container-95` on the dropdown in header.php.
 *
 * ⚠ Deliberately CSS rather than editing the markup: there are EIGHT
 * `class="container"` wrappers in the panel — one per role branch (7) plus one
 * in the hidden Availability seasons list — and those branches are faithful
 * lifts of the original menu with a documented history of mis-nesting (see the
 * CRM's core-modules/navigation/CLAUDE.md → "Bare <li>s inside a <div> will
 * unwind the whole panel"). One scoped rule cannot unbalance a tag.
 *
 * The seasons-list one is inside a `display:none` item, so widening it is inert.
 *
 * Scoped to the panel, so `.container` everywhere else on either estate is
 * untouched. No !important needed — Bootstrap's own `.container` max-widths are
 * single-class rules, so three classes win.
 *
 * ⚠ The CRM's legacy `backend.css` also carries `#com_crmery div.container`
 * (float + width:100%), which an ID makes STRONGER than this rule. It is not a
 * conflict: the header renders above `#com_crmery`, so the panel is never inside
 * it. If a future layout ever moves the header into the component wrapper, that
 * rule wins and this one silently stops applying.
 */
.topnav_menu .account-panel .container {
    max-width: 100%;
}

/* ─────────────────────────────────────────────────────────────────────────────
 * BLOCK 5 — the panel's own CONTENT styling (added 2 Aug 2026)
 *
 * WHY THIS EXISTS. Everything above styles the panel's WRAPPER. The panel's
 * CONTENTS are rendered by the CRM (BrambleAccountPanel::render() + Joomla
 * mod_menu), so they carry CRM class names — measured on a real 17KB panel:
 * .crmmenu x13, .menuchal x11, .moduletable x11, .fa x11, plus .bottomadminmenu,
 * .seperator20 and .reportsplitter. Those were styled ONLY by
 * `crm .../templates/bramble-beta/css/{global,frontend}.css`, which WordPress
 * does not load — so the panel rendered correctly on the CRM and effectively
 * unstyled on the website.
 *
 * Measured on WordPress before this block, against the CRM as the target:
 *
 *   .newmenu h2 (column headings)   32px   vs   12px   <- the glaring one
 *   .crmmenu li margin-bottom        0px   vs    4px
 *   .menuchal margin                  8px  vs   10px
 *   .seperator20 height              auto  vs   20px
 *   .reportsplitter margin-top       0px   vs   39px
 *   .bottomadminmenu .moduletable    none/880px vs right/calc(100% - 115px)
 *
 * ⚠⚠ EVERY RULE IS SCOPED TO `.topnav_menu .account-panel`. The unscoped
 * originals name `h2`, `.menu`, `.moduletable` and `.container` — generic enough
 * that porting them bare into a file the PUBLIC WEBSITE loads would restyle
 * brambleski.com. Scope anything added here the same way, without exception.
 *
 * ⚠ Values are copied VERBATIM from the CRM originals, and the scope makes these
 * rules more specific than them (0,0,3,x vs 0,0,1,x). So on the CRM the computed
 * result is unchanged — same declarations, just won by a longer selector — and
 * only WordPress gains anything. That is what makes this safe to ship to both.
 *
 * ⛔ DELIBERATELY NOT PORTED — `global.css`'s legacy top-level-nav rules that
 * also match `.newmenu`: `.newmenu ul { position: fixed; top: 155px; width: 100%;
 * background: rgba(0,0,0,.8) }` and `.newmenu li ul { display: none }`. Those
 * style the retired CRM menu BAR, not this panel; on the CRM they are overridden
 * further down the cascade, and on WordPress they do not exist at all. Porting
 * them would HIDE every sub-menu on the website. If a heading or column ever
 * goes missing here, check you have not pulled one of those in.
 */
/* The panel's headings are styled by BOOTSTRAP UTILITIES on the markup —
 * `class="menuchal fs-6 fw-semibold"` in BrambleAccountPanel::render(). The old
 * 9-declaration rule here (teal, 12px !important, letter-spacing, padding,
 * text-transform, border, float, text-align) was deleted 2 Aug 2026: the teal was
 * off-brand and the rest is what utilities are for.
 *
 * ⚠⚠ THIS ONE DECLARATION CANNOT MOVE TO THE MARKUP, which is why the rule is not
 * gone entirely. The Ivypresto block above sets
 * `font-family: ivypresto-display, Medium, serif` on `.header_3_design h1..h5`
 * — and on `.header_3_design .fs-1 … .fs-6` too. So the account panel's headings
 * inherit the WEBSITE's display serif twice over, and adding `fs-6` re-triggers it
 * rather than escaping it. Bootstrap ships no font-family utility to counter that
 * (only `.font-monospace`), so the override has to be CSS.
 *
 * Ivypresto is deliberately scoped to the shared header for the MARKETING panels
 * (resort names, chalet titles) — the 29 Jul decision that the second brand font
 * is a website typeface and the CRM stays on Proxima. The account panel is the
 * CRM's own navigation sitting inside that same component, so it is the exception
 * the scoping did not anticipate.
 *
 * Specificity: (0,0,2,1) beats the `.header_3_design h2` block's (0,0,1,1). */
.topnav_menu .account-panel h2 {
    font-family: proxima-nova, sans-serif;

    /* Heading colour — the house `--cm-table-head` token (custom/style.md).
     *
     * ⚠⚠ THE FALLBACK IS NOT OPTIONAL, and it is the reason a hex appears in a
     * file whose own standard says "tokens, never a hex". The token is declared
     * in the CRM's `core-modules/assets/generic-styles.css`, which:
     *   · is NOT loaded on WordPress at all (measured — the site loads
     *     back-to-top / bootstrap / bootstrap-icons / page-builder / aos /
     *     typekit / base, and nothing else), and
     *   · is OPT-IN per CRM page, so legacy CRM screens do not carry it either.
     * A bare `var(--cm-table-head)` therefore resolves to nothing on the website
     * and on any legacy page, and the headings lose their colour entirely —
     * silently, because an invalid var falls back to inherit.
     *
     * With the fallback: pages that have the token follow it, everything else
     * gets the identical literal, and the two estates stay in step.
     *
     * ⚠ MAINTENANCE: if `--cm-table-head` is ever retuned in generic-styles.css,
     * change this fallback in the SAME commit or WordPress silently keeps the old
     * colour while the CRM moves. */
    color: var(--cm-table-head, #17566E);
}

.topnav_menu .account-panel .menuchal {
    margin: 0 0 10px !important;
}

/* Icon spacing inside a heading — the one rule of this set that came from
   frontend.css rather than global.css. */
.topnav_menu .account-panel .menuchal i {
    padding-right: 10px;
}

.topnav_menu .account-panel .content {
    padding: 15px 0 5px;
}

/* The panel's own top-level indent. Ported from global.css 2 Aug 2026 when that
   file's `.newmenu` rules were retired — it was the one declaration in that set
   with no equivalent here, so deleting it without this would have shifted the
   whole panel 10px left. */
.topnav_menu .account-panel > li {
    margin-left: 10px;
}

.topnav_menu .account-panel .crmmenu ul {
    background: none;
    min-height: 0;
    position: static;
    width: auto;
}

.topnav_menu .account-panel .crmmenu li {
    margin-bottom: 4px;
}

.topnav_menu .account-panel li ul li {
    line-height: 120%;
    text-align: left;
    width: 100%;
    padding: 0 !important;
}

.topnav_menu .account-panel .seperator20 {
    height: 20px;
}

.topnav_menu .account-panel .reportsplitter {
    margin-top: 39px;
}

/* ---------------------------------------------------------------------------
 * The panel's FOOTER STRIPS — HR / Marketing / Help / Dev.
 *
 * Layout: a fixed label column, then every content block beside it, with the
 * items on one wrapping pipe-separated line:
 *
 *     HR        Staff | Inventory | Weekly Report Config | …
 *
 * ⚠⚠ REBUILT ON GRID, 2 Aug 2026 — the float version was measurably broken, not
 * merely untidy. Measured before the change:
 *   · every `.bottomadminmenu` computed **height: 0** — all its children were
 *     floated, so the parent collapsed and the blocks did not reserve space;
 *   · **Help and Dev rendered at the SAME y (658px)** — overlapping each other;
 *   · HR's hardcoded "Finance Kanban" `<ul>` (a sibling of `.moduletable`, not
 *     part of the module's own list) floated into the 115px label gutter and
 *     read as a stray item unrelated to the HR menu.
 * Only the first `hrBlock()` emitted a `.clr` clearfix, so the rest had nothing
 * to contain them at all.
 *
 * The grid fixes all three at once, and is robust to the CHILD COUNT — which is
 * the real lesson: `> *:not(h2) { grid-column: 2 }` puts the module, the extra
 * `<ul>`, and anything added later into the content column automatically, so a
 * future hardcoded item cannot fall into the gutter the way Finance Kanban did.
 * ------------------------------------------------------------------------- */
/* ⚠ The label column is a FIXED width on purpose. Each strip is its own grid, so
   `max-content` would size each one independently and the four labels would stop
   lining up with each other — the whole point of the column. 140px is set by the
   longest label, "Marketing", which at 16px/600 with `ls-2` plus its icon and the
   10px icon gap needs ~121px; it wrapped to two lines at the original 115px. */
.topnav_menu .account-panel .bottomadminmenu {
    display: grid;
    grid-template-columns: 140px 1fr;
    column-gap: 1rem;
    row-gap: 0.25rem;
    align-items: baseline;
    padding: 20px 0 0;
}

/* ⚠ Order matters: this zeroes the padding of the element carrying BOTH classes,
   exactly as the original did. */
.topnav_menu .account-panel .bottomadminmenu2 {
    padding: 0;
}

.topnav_menu .account-panel .bottomadminmenu h2.menuchal {
    grid-column: 1;
    float: none;
    width: auto;
    margin: 0;
}

/* Everything that is not the label goes in the content column — the module's
   list, the extra `<ul>`, and anything added later. */
.topnav_menu .account-panel .bottomadminmenu > *:not(h2) {
    grid-column: 2;
    float: none;
    width: auto;
    min-width: 0;
}

.topnav_menu .account-panel .bottomadminmenu ul {
    display: flex;
    flex-wrap: wrap;
    border: none;
    float: none;
    margin: 0;
    padding: 0 !important;
}

.topnav_menu .account-panel .bottomadminmenu li {
    border-right: 1px solid #46b1a7;
    float: none;
    margin-right: 10px;
    padding-right: 10px !important;
    width: auto !important;
}

.topnav_menu .account-panel .bottomadminmenu li:last-child {
    border-right: none;
}

/* ─────────────────────────────────────────────────────────────────────────────
 * BLOCK 6 — link COLOUR. Read the specificity note before touching this.
 *
 * Symptom without it, on WordPress only: the panel lays out perfectly and the
 * link text is INVISIBLE — white on a white dropdown. The teal `|` separators of
 * the bottom strip still show, which is what gives it away; nothing is missing
 * from the DOM (113 links, all `visibility: visible`, `opacity: 1`).
 *
 * Cause: `page-builder.css` paints the header's nav links white for the site's
 * dark/transparent header — `.navbar-nav > li.nav-item a { color: #fff }`. The
 * account panel is inside that nav, so it inherits the treatment. The CRM never
 * sees this because it deliberately does not load `page-builder.css`; there the
 * links fall through to `base.css`'s `a { color: #2C2C2C }`, and #2C2C2C is
 * therefore the value matched here.
 *
 * ⚠⚠ SPECIFICITY IS THE WHOLE RULE. `.navbar-nav > li.nav-item a` is (0,0,2,2).
 * The obvious `.topnav_menu .account-panel a` is (0,0,2,1) and LOSES — it looks
 * correct, changes nothing, and the text stays invisible. The third class here
 * is not decoration: it takes this to (0,0,3,1). Any future addition to this
 * block needs the same treatment, and `!important` is not the answer (this file
 * loads on the public site).
 *
 * The marketing panels solved the identical problem in the other direction — see
 * base.css's `.submenu_sidemenu a { color: #202020 }`, recovered 1 Aug 2026 when
 * the CRM was the estate rendering them wrongly.
 */
.topnav_menu .account_menu .account-panel a,
.topnav_menu .account_menu .account-panel a:hover,
.topnav_menu .account_menu .account-panel a:focus {
    color: #2C2C2C;
    /* The rest of this block undoes the site header's LINK TREATMENT, which the
     * panel inherits for the same reason as the colour above. Measured on
     * WordPress before it: UPPERCASE, `letter-spacing: 4px` and underlined —
     * fine for seven marketing words, unreadable for 113 menu items. The CRM
     * values (text-transform none / letter-spacing normal / no underline /
     * line-height 100%) are the target; these are that rule's own resets, which
     * `global.css` carries as `.newmenu li ul li a`.
     *
     * ⚠ `font-size` is a deliberate HARMONISATION, not a copy: the CRM computes
     * 16px (base.css) and WordPress 15px (page-builder.css). Pinning it here
     * makes the panel identical on both estates and is a no-op on the CRM. */
    text-transform: none;
    letter-spacing: normal;
    text-decoration: none;
    line-height: 100%;
    font-size: 16px;
}