/*
 * Site overrides.
 *
 * Loaded LAST so it wins over the theme stylesheets. Two kinds of rule live
 * here, kept in separate sections:
 *
 *   1. Approved deviations - deliberate, client-approved changes.
 *   2. Reimplemented theme JavaScript - rules that restore behaviour the
 *      original produced with JS we deliberately do not ship. These are
 *      fidelity fixes, NOT deviations.
 *
 * Anything added must also be recorded in KNOWN_DIFFERENCES.md.
 */

/* ===========================================================================
 * 2. REIMPLEMENTED THEME JAVASCRIPT
 * ======================================================================== */

/* ---------------------------------------------------------------------------
 * Content offset below the header.
 *
 * #site-header is `position: absolute`, so it takes up no space in flow. The
 * theme's custom.js compensated by measuring the header on load and writing
 * that height onto #page as an inline `padding-top` (verified on the
 * reference: `padding-top: 100px` at 375px, `140.797px` at 1440px). Without
 * an equivalent, the first section would sit underneath the header.
 *
 * The header is absolute rather than in-flow so that it can switch to
 * `position: fixed` when `.sticky` is added without the page jumping.
 *
 * Header.tsx writes the exact measured height into --tsg-header-height on
 * mount. The values below are what that measurement yields at each breakpoint,
 * so first paint already matches and there is no layout shift on hydration:
 *
 *   >= 810px   140.8px   topbar (40.8) + header-main (100)
 *   768-809px  164.59px  the topbar's contact row wraps to two lines
 *   <= 767px   100px     topbar hidden by `topbar-mobile-off`
 *
 * Do not fold this into a single value: a constant offset is exactly the bug
 * that ie8.css's `.site-content { padding: 6.5em 0 0 }` used to cause.
 * ------------------------------------------------------------------------- */
#page.site {
  --tsg-header-height: 140.8px;
  padding-top: var(--tsg-header-height);
}

@media (max-width: 809px) {
  #page.site {
    --tsg-header-height: 164.59px;
  }
}

@media (max-width: 767px) {
  #page.site {
    --tsg-header-height: 100px;
  }
}

/*
 * ...except while the header still carries `header-loading`, which the theme
 * uses on first paint to make #site-header `position: relative` - in flow, so
 * it reserves its own space. Padding on top of that would offset the content
 * twice. The class is dropped on mount, at which point this selector stops
 * matching and the padding above takes over in the same commit, so the two
 * states hand over with no layout shift.
 *
 * Browsers without :has() ignore this rule and show the double offset until
 * hydration, which is the safe direction to fail in.
 */
#page.site:has(> #site-header.header-loading) {
  padding-top: 0;
}

/* ===========================================================================
 * 1. APPROVED DEVIATIONS
 * ======================================================================== */

/* ---------------------------------------------------------------------------
 * Page-header banner: the smaller mobile padding.
 *
 * The theme ships both sizes, selected by a class it adds server-side:
 *
 *   .page-header .page-header-inner                     { padding: 140px 0 }
 *   .page-header.mobile-page-header .page-header-inner   { padding:  80px 0 }
 *
 * The reference carries `mobile-page-header` at 991px and below (verified: the
 * class is present at 768px and 375px, absent at 1440px). Applying it from a
 * media query instead of adding the class in JavaScript renders identically
 * (382px banner at 1440, 256px at 768, 244px at 375) and avoids a hydration
 * layout shift.
 * ------------------------------------------------------------------------- */
@media (max-width: 991px) {
  .page-header .page-header-inner {
    padding-top: 80px;
    padding-bottom: 80px;
  }
}

/* ---------------------------------------------------------------------------
 * Contact form: keep Akismet's honeypot field hidden, in CSS.
 *
 * Contact Form 7 ships this decoy for bots to fill in:
 *
 *   <p style="display:none !important"><label>Δ<textarea
 *      name="_wpcf7_ak_hp_textarea" cols="45" rows="8">…
 *
 * Its invisibility depends entirely on that inline attribute - CF7's own
 * stylesheet contains no rule for it (grep: zero matches). That is a single
 * point of failure: anything that rewrites or strips inline styles (a React
 * re-render dropping `!important`, which the property setter rejects, or a
 * form-filler browser extension un-hiding fields) puts a bare 45x8 textarea on
 * the page under the Submit button, which is exactly what the client reported
 * seeing. It could not be reproduced in a clean browser, so the trigger is
 * environmental - but the fragility is real either way.
 *
 * Hiding it from the stylesheet as well removes the dependency. The field stays
 * in the DOM and keeps working as a honeypot: ContactForm.tsx still reads its
 * value and silently drops any submission that filled it in.
 * ------------------------------------------------------------------------- */
form.wpcf7-form textarea[name="_wpcf7_ak_hp_textarea"],
form.wpcf7-form input[name="_wpcf7_ak_js"] {
  display: none !important;
}

/* Hide the wrapping <p> too, so it cannot contribute height or a label. The
   textarea rule above is the fallback for browsers without :has(). */
form.wpcf7-form p:has(> label > textarea[name="_wpcf7_ak_hp_textarea"]) {
  display: none !important;
}

/* ---------------------------------------------------------------------------
 * 404 page: the "Please return to Homepage" link is actually clickable.
 *
 * The theme paints a second, ghosted copy of the giant "404" behind the first:
 *
 *   .error-404-main .text-404 .inner-text {
 *     position: absolute; left: 15px; top: 15px; right: 0; bottom: 0;
 *     opacity: 0.15;
 *   }
 *
 * `right: 0; bottom: 0` stretches that box over everything below it, so it sat
 * on top of the search field and the Homepage link and swallowed every click -
 * confirmed with elementFromPoint, which returned `span.text-404.inner-text` at
 * the centre of the link. Present on the reference too, where the link was
 * `href=""` and so did nothing regardless.
 *
 * It is pure decoration, so it should never have been a click target. No
 * visual change: opacity, position and size are untouched.
 * ------------------------------------------------------------------------- */
.error-404-main .text-404 .inner-text {
  pointer-events: none;
}

/* ---------------------------------------------------------------------------
 * Contact page: the three contact cards are all the same height.
 *
 * On the original the cards size to their own content, so "Our Location" -
 * whose address wraps onto a second line - is 300px while "Contact Number" and
 * "Our Email Address" are 273px, leaving the row visibly ragged along the
 * bottom. Verified present on the reference, so this is a deliberate deviation
 * requested by the client, not a fidelity fix.
 *
 * The Elementor columns are already equal height (all 300px); only the
 * .feature-box inside each one falls short, so stretching that to fill its
 * column is enough. No padding, colour or type is touched.
 * ------------------------------------------------------------------------- */
.elementor-element-7bc20b5 .elementor-widget-wrap {
  /* Elementor sets flex-start here, which is what stops the single flex line
     from filling the column. */
  align-content: stretch;
}

.elementor-element-7bc20b5 .elementor-widget-wrap > .elementor-widget {
  align-self: stretch;
  display: flex;
  flex-direction: column;
}

.elementor-element-7bc20b5 .elementor-widget-wrap > .elementor-widget > .elementor-widget-container {
  flex: 1 1 auto;
}

.elementor-element-7bc20b5 .feature-box {
  height: 100%;
}

/* ---------------------------------------------------------------------------
 * In-page anchor targets clear the sticky header.
 *
 * The header's "Services" item links to /#service-section, reproducing the
 * original's /home/#service-section. The jump lands the section at the very top
 * of the viewport, where the sticky bar - `position: fixed` past 250px of
 * scroll - covers its "OUR SERVICES" label and part of the heading.
 *
 * On the reference this is masked rather than solved: a hash jump taken during
 * page load fires no scroll event, so the theme's JS has not yet made the
 * header sticky and nothing is covering the target. Scroll once and follow the
 * link again and the original obscures the heading exactly as this build did.
 *
 * Requested by the client: land the section below the bar, not behind it.
 * Header.tsx publishes the bar's measured height; 80px is the theme's own
 * sticky min-height, used until the bar has been measured once.
 * ------------------------------------------------------------------------- */
#service-section {
  scroll-margin-top: var(--tsg-sticky-header-height, 80px);
}

/* ---------------------------------------------------------------------------
 * Footer: remove the "sticky footer reveal" gap.
 *
 * The Finix theme pins .site-footer with `position: fixed` and its JavaScript
 * gives .site-content-contain a bottom margin equal to the footer height, so
 * the footer is revealed from behind the page as you reach the bottom. That
 * leaves a band of empty page background between the last section and the
 * footer.
 *
 * Verified present on the reference site (margin-bottom: 513.195px, footer
 * position: fixed). Removed at the client's request: the footer now sits in
 * normal flow directly after the last section.
 * ------------------------------------------------------------------------- */
.sticky-footer .site-footer,
.site-footer {
  position: relative;
}

.sticky-footer .site-content-contain,
.site-content-contain {
  margin-bottom: 0;
}

/*
 * With the footer back in normal flow it would leave white space below itself
 * on pages shorter than the viewport (404, sign-in). This is the standard
 * flexbox sticky-footer: the page fills at least the viewport height, the
 * content area absorbs the slack, and the footer sits at the bottom.
 *
 * Result: no reveal gap on long pages, and no white band on short ones.
 */
#page.site {
  display: flex;
  flex-direction: column;
  min-height: 100vh;
}

#page.site > .site-content-contain {
  flex: 1 0 auto;
}

#page.site > .site-footer {
  flex-shrink: 0;
}