/*
 * Hand-authored rules layer (1.3 of THEME-REFACTOR-PLAN-V13.md). Every selector starts with the
 * literal scope placeholder (see ThemeRules.ScopePlaceholder) — replaced with "" on the frontend,
 * ".be-preview" in the backoffice preview — so these rules can never leak into Umbraco's own chrome.
 *
 * This is deliberately short: block-level colour variation needs no rules at all here — it is
 * handled entirely by :root (base tokens) + .be-v-{alias} (sparse overrides) + ordinary CSS custom
 * property inheritance. A handful of --bs-* / --footer-* names (navbar/dropdown/link/heading colours)
 * are already consumed by Bootstrap's own compiled component CSS or by index.css directly, so no
 * rule for them belongs here either. What's left — and everything below — is exactly what used to
 * be a literal, per-request value with no var() indirection at all: global typography, corner
 * radius, drop shadow, and the two background values that never had a custom property behind them.
 */

/* ---- Global typography (body) ----
    body covers the frontend (real <body>, reached via inheritance by everything). It can never
   match anything in a backoffice block-view preview though -  resolves to .be-preview there, a
   local wrapper <div> inside each block view's own light DOM, not an ancestor of a real <body> tag. The
   old AngularJS app's per-block <style ng-bind="styles"> hit the same constraint and targeted
   `.rich-text` directly instead of `body` for exactly this reason - restored here alongside body so
   both contexts get the base font/size.

   color is included here too even though it's normally Bootstrap's own compiled `body { color:
   var(--bs-body-color) }` reboot rule's job (not otherwise duplicated in this file, per its own header
   comment) - that rule has the exact same real-<body>-only reach, confirmed live: .be-preview correctly
   carries --bs-body-color, but the rendered text fell through to Umbraco's own base text color instead
   (~rgb(6,6,6)) because nothing in the block-view's own reachable ancestor chain ever set `color`
   itself.

   A bare  rule below covers every OTHER plain-text case that isn't wrapped in .rich-text -
   e.g. auth-form-shell.custom-view.js's bare `<a>Remember password? Sign In</a>`, which on the frontend
   just inherits from the real <body> like any other untagged text, but had nothing to inherit from at
   all in the backoffice preview before this. It's kept in its OWN separate rule rather than added to the
   selector list above:  resolves to "" on the frontend, and every selector in a plain (non-:is/
   :where) comma list must be individually valid or the WHOLE rule is dropped - folding a bare 
   into the list above would silently kill the frontend's body/.rich-text typography rule outright. As
   its own rule,  alone becomes an invalid empty selector on the frontend (that one rule is
   dropped, harmlessly - frontend doesn't need it) and `.be-preview` in the backoffice (matches the
   preview root directly, at normal class specificity - it only ever matters through inheritance here,
   since nothing more specific targets .be-preview itself). (That decorative `<a>` above renders in body
   colour rather than link colour for an unrelated reason: it has no `href` in the backoffice preview, so
   Bootstrap's own higher-specificity `a:not([href]):not([class]) { color: inherit }` reboot rule wins
   over the plain `a { color: var(--bs-link-color) }` one - same as it would with or without this rule,
   just inheriting a better value now. The frontend's version of this link has a real href, so it's
   unaffected and correctly link-coloured.) */

 body,  .rich-text {
  color: var(--bs-body-color);
  font-family: var(--be-font-text-family), var(--be-font-text-category);
  font-size: var(--be-font-text-size-desktop);
  font-style: var(--be-font-text-style);
  font-weight: var(--be-font-text-weight);
}

 {
  color: var(--bs-body-color);
  font-family: var(--be-font-text-family), var(--be-font-text-category);
  font-size: var(--be-font-text-size-desktop);
  font-style: var(--be-font-text-style);
  font-weight: var(--be-font-text-weight);
}

@media (max-width: 992px) {
   body,  .rich-text { font-size: var(--be-font-text-size-tablet); }
   { font-size: var(--be-font-text-size-tablet); }
}

@media (max-width: 575px) {
   body,  .rich-text { font-size: var(--be-font-text-size-mobile); }
   { font-size: var(--be-font-text-size-mobile); }
}

/* .lead-lg/.lead-md/.lead-sm stay derived from the single body text size via calc(), not three
   independent tokens — preserves the "always offset from body size" relationship losslessly. */
 .lead-lg { font-size: calc(var(--be-font-text-size-desktop) + 4px); }
 .lead-md { font-size: var(--be-font-text-size-desktop); }
 .lead-sm { font-size: calc(var(--be-font-text-size-desktop) - 2px); }

/* ---- Headings h1-h6 ---- */

 .h1,  h1 {
  font-family: var(--be-font-h1-family), var(--be-font-h1-category);
  font-size: var(--be-font-h1-size-desktop);
  font-style: var(--be-font-h1-style);
  font-weight: var(--be-font-h1-weight);
}
@media (max-width: 992px) {  .h1,  h1 { font-size: var(--be-font-h1-size-tablet); } }
@media (max-width: 575px) {  .h1,  h1 { font-size: var(--be-font-h1-size-mobile); } }

 .h2,  h2 {
  font-family: var(--be-font-h2-family), var(--be-font-h2-category);
  font-size: var(--be-font-h2-size-desktop);
  font-style: var(--be-font-h2-style);
  font-weight: var(--be-font-h2-weight);
}
@media (max-width: 992px) {  .h2,  h2 { font-size: var(--be-font-h2-size-tablet); } }
@media (max-width: 575px) {  .h2,  h2 { font-size: var(--be-font-h2-size-mobile); } }

 .h3,  h3 {
  font-family: var(--be-font-h3-family), var(--be-font-h3-category);
  font-size: var(--be-font-h3-size-desktop);
  font-style: var(--be-font-h3-style);
  font-weight: var(--be-font-h3-weight);
}
@media (max-width: 992px) {  .h3,  h3 { font-size: var(--be-font-h3-size-tablet); } }
@media (max-width: 575px) {  .h3,  h3 { font-size: var(--be-font-h3-size-mobile); } }

 .h4,  h4 {
  font-family: var(--be-font-h4-family), var(--be-font-h4-category);
  font-size: var(--be-font-h4-size-desktop);
  font-style: var(--be-font-h4-style);
  font-weight: var(--be-font-h4-weight);
}
@media (max-width: 992px) {  .h4,  h4 { font-size: var(--be-font-h4-size-tablet); } }
@media (max-width: 575px) {  .h4,  h4 { font-size: var(--be-font-h4-size-mobile); } }

 .h5,  h5 {
  font-family: var(--be-font-h5-family), var(--be-font-h5-category);
  font-size: var(--be-font-h5-size-desktop);
  font-style: var(--be-font-h5-style);
  font-weight: var(--be-font-h5-weight);
}
@media (max-width: 992px) {  .h5,  h5 { font-size: var(--be-font-h5-size-tablet); } }
@media (max-width: 575px) {  .h5,  h5 { font-size: var(--be-font-h5-size-mobile); } }

 .h6,  h6 {
  font-family: var(--be-font-h6-family), var(--be-font-h6-category);
  font-size: var(--be-font-h6-size-desktop);
  font-style: var(--be-font-h6-style);
  font-weight: var(--be-font-h6-weight);
}
@media (max-width: 992px) {  .h6,  h6 { font-size: var(--be-font-h6-size-tablet); } }
@media (max-width: 575px) {  .h6,  h6 { font-size: var(--be-font-h6-size-mobile); } }

/* ---- Buttons / icon links ----
   Responsive button sizing now applies uniformly to .icon-link and .btn-light too — the old code
   left them desktop-only (open question #10 in the audit); there is no reason for two of three
   button-styled selectors to ignore tablet/mobile sizing, so this fixes that gap. */

 .icon-link,  .btn-light,  .btn {
  font-family: var(--be-font-button-family), var(--be-font-button-category);
  font-style: var(--be-font-button-style);
  font-weight: var(--be-font-button-weight);
  font-size: var(--be-font-button-size-desktop);
}
@media (max-width: 992px) {
   .icon-link,  .btn-light,  .btn,  .btn-lg,  .btn-md {
    font-size: var(--be-font-button-size-tablet);
  }
}
@media (max-width: 575px) {
   .icon-link,  .btn-light,  .btn,  .btn-lg,  .btn-md {
    font-size: var(--be-font-button-size-mobile);
  }
}

 .icon-link { color: var(--bs-link-color); text-decoration-color: var(--bs-link-color); }
 .icon-link:hover { color: var(--bs-link-hover-color); text-decoration-color: var(--bs-link-hover-color); }

/* ---- Corner radius ----
   .card-border-radius needs the compound form (.card-border-radius, no space) alongside the
   descendant one: several card-family custom views (feature "Card With Icon", card-with-number,
   case-study-card, pricing-card, text-card-with-button, team-member - confirmed via a repo-wide grep)
   put .card-border-radius/.card-box-shadow on the SAME element as .be-preview, not nested inside it -
   the exact same shape as the .be-v-{alias} bug fixed earlier in this file. Confirmed live: the
   variable itself (--be-radius-cards) reached the element fine, but border-radius computed to 0 because
   the descendant-only selector never matched. .border-radius/.box-shadow-pictures-and-video are left
   alone - those are only ever applied to a nested <img>, genuinely a descendant of .be-preview in every
   view that uses them (image.custom-view.js, card.custom-view.js), so the descendant form already
   works there. */

 .btn-sm,  .btn,  .btn-lg { border-radius: var(--be-radius-buttons); }
 .card-border-radius, .card-border-radius { border-radius: var(--be-radius-cards); }
 .border-radius { border-radius: var(--be-radius-pictures-and-video); }

/* ---- Drop shadow ---- */

 .card-box-shadow, .card-box-shadow {
  box-shadow: var(--be-shadow-cards-offset-x) var(--be-shadow-cards-offset-y) var(--be-shadow-cards-blur-radius) var(--be-shadow-cards-color);
}
 .box-shadow-pictures-and-video {
  box-shadow: var(--be-shadow-pictures-and-video-offset-x) var(--be-shadow-pictures-and-video-offset-y) var(--be-shadow-pictures-and-video-blur-radius) var(--be-shadow-pictures-and-video-color);
}

/* ---- Header / footer background ----
   The only two header/footer values that were ever literal-only (never a custom property before);
   everything else in that family (navbar/dropdown link colours, footer link/title/copyright) is
   already wired to Bootstrap's own compiled component CSS or to index.css directly. */

/* .header .main-nav, not just .main-nav: index.css paints the mobile menu panel `background: white`
   as `.header .main-nav` (0,2,0) inside its max-width: 991.98px block, which beat a bare .main-nav
   here - v13 hid that behind an inline background-color on the element. Same specificity now, and
   this file loads after index.css. Desktop keeps index.css's `transparent !important`. */
 nav.header,  .header .main-nav { background-color: var(--bs-header-bg); }
 footer { background-color: var(--footer-bg); }

/* ---- Header text/border scope ----
   The old header set a literal `color:` and `--bs-border-color` directly on <nav class="header">
   itself (token-audit.md Open Question #7 — an independent cascade scope from the per-block one).
   Descendants with no more specific rule of their own — .navbar-brand's own Bootstrap-native
   --bs-navbar-brand-color is only ever set inside .navbar, which this header never has — need this
   to inherit the header's link colour instead of falling through to body's --bs-body-color. */
 nav.header {
  color: var(--bs-navbar-color);
  --bs-border-color: var(--bs-header-border-color);
}

/* ---- Dropdown menu (header) ----
   Bootstrap's own .dropdown-menu rule locally re-derives --bs-dropdown-bg (and its link/hover
   variants) from generic body/tertiary tokens as its own theming mechanism. That custom property is
   shadowed on this exact element for every reader, including a redeclaration of the same name here —
   a custom property redeclared as a reference to itself, on an element that already has another
   declaration for that same property, is a genuine cycle (invalid), not a defeat of the shadow; it
   does not fall through to the inherited/:root value.
   Overriding the *rendered* properties directly, at higher specificity than Bootstrap's own rule,
   sidesteps the shadow entirely instead — the same pattern this file already uses just above for
   .header .dropdown-menu's border-color.

   The design's own dropdown tokens (color.header.dropdown-background / -background-hover, which v13
   wrote inline on the menu) are read through --be-header-dropdown-*: declared on .header, above the
   .dropdown-menu that shadows the --bs-* names, they carry the theme's values down.

   The hover/active rule names .main-nav to match index.css's own
   `.header .main-nav .dropdown-item:hover` (0,4,0), which paints Bootstrap's shadowed defaults and
   beat a shorter selector here; equal specificity is enough, this file loads after index.css. The
   current page's item (.active) takes the hover colours, as in v13. */
 .header {
  --be-header-dropdown-bg: var(--bs-dropdown-bg);
  --be-header-dropdown-hover-bg: var(--bs-dropdown-link-hover-bg);
}
 .header .dropdown-menu {
  background-color: var(--be-header-dropdown-bg);
}
 .header .dropdown-item {
  color: var(--bs-navbar-color);
}
 .header .main-nav .dropdown-item:hover,  .header .main-nav .dropdown-item:focus,
 .header .main-nav .dropdown-item.active {
  color: var(--bs-navbar-hover-color);
  background-color: var(--be-header-dropdown-hover-bg);
}

/* ---- Variant background + text color ----
   A block wearing .be-v-{alias} needs its background to actually follow that variant's overridden
   --bs-body-bg — .be-v-base intentionally omitted, it IS the page background already.

   color is also set explicitly here, not left to inheritance: custom-property overrides only affect
   descendants THROUGH a property that itself references var(...) at that descendant's own position
   in the tree. Headings are fine without this (h1 { color: var(--bs-heading-h1-color) } matches at
   any depth), but generic text (p, li, span) has no such per-element rule — it just inherits body's
   already-resolved color, computed against body's own (base) scope, not the variant's. Without this
   rule, only backgrounds would flip on a variant block; text would stay the base color.

    .be-v-{alias} (a descendant combinator) never matched anything in the backoffice preview:
   every custom view puts be-preview and be-v-{alias} on the SAME element
   (['be-preview', variant ? `be-v-${variant}` : '', ...] - confirmed universal across BlockViews/*.js),
   never nested. On the frontend  is "" so ` .be-v-inverse` still matches regardless of
   co-location, which is why this variant only ever visibly worked there. Added the compound form
   `.be-v-{alias}` (no space) alongside it to cover the same-element case: on the frontend this
   resolves to plain `.be-v-inverse` again (redundant with the descendant form, harmless), and in the
   backoffice to `.be-preview.be-v-inverse` (matches the actual co-located element). Both forms use
    rather than hardcoding .be-preview, per this file's own selector convention (enforced by
   SchemaConsistencyTests.ThemeRules_EverySelectorStartsWithScopePlaceholder).

   :not(.be-v-text-only) excludes rich-text/headline's OWN be-v-{alias} (added purely to receive the
   Active-variant bridge below, not because the block has a real themeVariant of its own - see that
   section). Those two blocks nest inside arbitrary ancestors (a plain color layout, but also e.g. Hero's
   own image background) - painting a solid background on them is correct for a block with a REAL
   themeVariant (a layout choosing to recolor its whole box), but wrong for bridged/inherited text: it
   used to paint an opaque rectangle over whatever the ancestor actually rendered (confirmed live: a
   RichText nested in Hero's area got a solid black box hiding the hero's background image). Text color
   still needs to follow the variant either way - see the .be-v-text-only rule right after this one.

   background-color, never the `background` shorthand: the shorthand also resets background-size,
   -position and -repeat, and at 0,2,0 it beats the index.css classes that make a block's background
   image cover and centre - the image (set inline) then tiled from the top-left corner. Variant tokens
   are plain colours, and v13 likewise only ever set background-color inline. */

 .be-v-inverse:not(.be-v-text-only),  .be-v-accent:not(.be-v-text-only),  .be-v-muted:not(.be-v-text-only),
 .be-v-style-4:not(.be-v-text-only),  .be-v-style-5:not(.be-v-text-only),  .be-v-style-6:not(.be-v-text-only),
 .be-v-style-7:not(.be-v-text-only),  .be-v-style-8:not(.be-v-text-only),  .be-v-style-9:not(.be-v-text-only),
.be-v-inverse:not(.be-v-text-only), .be-v-accent:not(.be-v-text-only), .be-v-muted:not(.be-v-text-only),
.be-v-style-4:not(.be-v-text-only), .be-v-style-5:not(.be-v-text-only), .be-v-style-6:not(.be-v-text-only),
.be-v-style-7:not(.be-v-text-only), .be-v-style-8:not(.be-v-text-only), .be-v-style-9:not(.be-v-text-only) {
  background-color: var(--bs-body-bg);
  color: var(--bs-body-color);
}

 .be-v-inverse.be-v-text-only,  .be-v-accent.be-v-text-only,  .be-v-muted.be-v-text-only,
 .be-v-style-4.be-v-text-only,  .be-v-style-5.be-v-text-only,  .be-v-style-6.be-v-text-only,
 .be-v-style-7.be-v-text-only,  .be-v-style-8.be-v-text-only,  .be-v-style-9.be-v-text-only,
.be-v-inverse.be-v-text-only, .be-v-accent.be-v-text-only, .be-v-muted.be-v-text-only,
.be-v-style-4.be-v-text-only, .be-v-style-5.be-v-text-only, .be-v-style-6.be-v-text-only,
.be-v-style-7.be-v-text-only, .be-v-style-8.be-v-text-only, .be-v-style-9.be-v-text-only {
  color: var(--bs-body-color);
}

/* ---- Base reset (layout-type blocks) ----
   The layout-type blocks (sections, heroes, banners, reviews, clients, features, team, gallery) render
   `be-v-base be-v-reset` when no variant is picked. v13 wrote their resolved style inline on every
   render - with nothing picked, the design's baseline - so they painted the base theme even nested in a
   parent's variant (a CTA section inside a style-7 blog wrapper kept dark buttons; the home page's
   rounded panel kept its white fill). The values CSS re-declares the base tokens for
   .be-v-base.be-v-reset; this paints them, like the variant rule above. Cards and other blocks that
   v13 only styled when a style differed from the baseline do not carry be-v-reset and still inherit.
   --be-active-variant: base stops rich-text/headline previews nested in such a block from picking up
   an outer variant through the bridge below. */
 .be-v-base.be-v-reset, .be-v-base.be-v-reset {
  background-color: var(--bs-body-bg);
  color: var(--bs-body-color);
  --be-active-variant: base;
}

/* ---- Active-variant bridge (backoffice preview only) ----
   A block with no themeVariant of its own (rich-text, headline - the only two content types with no
   own variant property that still render plain text) still nests inside its own separate `.be-preview`
   wrapper (every custom view wraps itself in one, for its own stylesheet-linking reasons - see
   shared/global-styles.js). Since `.be-preview`'s own base rule above re-declares
   --bs-body-bg/--bs-heading-*-color/etc unconditionally, a nested block's OWN `.be-preview` resets those
   back to the base theme regardless of an ancestor's .be-v-{alias} - the nearest matching declaration
   always wins, not the outermost. --be-active-variant carries the ancestor's variant alias down through
   ordinary inheritance instead (nothing else re-declares this name, so it survives crossing a nested
   .be-preview untouched); a custom view with no variant of its own reads it via getComputedStyle(this)
   and adds its own `be-v-{alias} be-v-text-only` classes to match - see rich-text.custom-view.js. The
   be-v-text-only marker is what keeps this text-only for these two (see the rule above) rather than also
   painting a background, since neither block owns the box it's rendered inside - unlike a block with a
   REAL themeVariant (e.g. a layout, or Hero), which intentionally recolors its whole box and so gets the
   full background+color rule instead. Frontend needs no bridge: there's only ever one .be-v-{alias}
   wrapper for the whole variant-scoped section, with nothing nested inside it re-declaring the base
   tokens. */
 .be-v-inverse, .be-v-inverse { --be-active-variant: inverse; }
 .be-v-accent, .be-v-accent { --be-active-variant: accent; }
 .be-v-muted, .be-v-muted { --be-active-variant: muted; }
 .be-v-style-4, .be-v-style-4 { --be-active-variant: style-4; }
 .be-v-style-5, .be-v-style-5 { --be-active-variant: style-5; }
 .be-v-style-6, .be-v-style-6 { --be-active-variant: style-6; }
 .be-v-style-7, .be-v-style-7 { --be-active-variant: style-7; }
 .be-v-style-8, .be-v-style-8 { --be-active-variant: style-8; }
 .be-v-style-9, .be-v-style-9 { --be-active-variant: style-9; }

/* ---- Hover-variant bridge (textCardWithButton2Block) ----
   This block picks its hover palette independently from its resting palette, but a custom property
   can only hold one value per element — .be-v-{alias} on the card itself already claims --bs-body-bg
   etc for the resting state, so a second .be-v-{alias} for hover can't coexist on that same element.
   Instead the hover variant is applied to a `display:contents` ancestor wrapper (invisible to layout,
   but still part of the cascade), and bridged here into the --card-hover-* names index.css's
   `.card-number.style-2:hover` rule already reads. The card inherits them from that ancestor without
   its own --bs-* overrides ever touching these different property names. */
 .be-hover-scope {
  --card-hover-bg-color: var(--bs-body-bg);
  --card-hover-color: var(--bs-body-color);
  --card-hover-color-border: var(--bs-border-color);
  --card-hover-color-link: var(--bs-link-color);
  --card-hover-color-link-hover: var(--bs-link-hover-color);
}