/*
 * Site-wide CTA normalization. Audit (2026-08-17) found the same "Call Us
 * Today" text styled 3 different ways on one page, plus a different red
 * shade on home, plus home's hero pairing both buttons in the identical
 * red (competing primary CTAs, no hierarchy). Elementor writes each
 * button's color as a per-widget ID-scoped rule baked into that page's own
 * data, so normalizing needs !important to override whatever hex that
 * specific page happened to be set to.
 *
 * Only two button intents exist site-wide: a Call action (tel: link) and
 * everything else. tel: is the reliable signal -- present on every Call
 * button audited, absent from every other CTA -- so it drives the split
 * instead of relying on each page's own (inconsistent) color choice.
 */

/* Primary: any Call-style button, anywhere on the site. */
a.elementor-button[href^="tel:"] {
  background-color: var(--jr-color-primary) !important;
  border-color: var(--jr-color-primary) !important;
  color: #fff !important;
}

/* Secondary: every other button, unconditionally (2026-08-18 -- only two
   CTA intents exist anywhere on the site now: the floating Call button
   handles every call action, so any button that isn't itself a tel: link
   is the form/quote action and gets the same secondary treatment, no
   exceptions, no pairing condition to satisfy first). */
a.elementor-button:not([href^="tel:"]) {
  background-color: rgba(255, 255, 255, 0.29) !important;
  border: 1px solid rgba(255, 255, 255, 0.6) !important;
  color: #fff !important;
}

/* Light-surface exception (2026-08-19) -- the address/hours/map section
   was switched to a white background; the translucent-white secondary
   above is invisible there (white-on-white), same root cause the hero's
   .jr-btn-secondary-light was built to fix. This section is still plain
   Elementor (not migrated to code yet), so it needs its own scoped
   override rather than the shared class -- same graphite-fill + red-
   border recipe as .jr-btn-secondary-light for consistency. */
.elementor-element-8be06ae a.elementor-button:not([href^="tel:"]) {
  background-color: var(--jr-color-graphite) !important;
  border: 1px solid var(--jr-color-primary) !important;
  color: #fff !important;
}

/* The white background applied to this same section (2026-08-19) only
   covered a ~1250px inner box, not the section edge to edge. Root cause:
   .elementor-element-8be06ae isn't the outer section -- it's one of five
   containers (b541e11, 8850998, 6b6a100, 8be06ae, 47f5c72) that all live
   together inside the REAL outer section (.elementor-element-64b91e8,
   background_color #27252A/graphite), boxed to 1250px by that parent's
   own boxed_width setting. Its own content_width:"full" only controls
   whether ITS children are boxed, not whether IT is boxed inside its
   parent -- that's what made "full" look like a no-op here.
   `width:100%!important` alone (tried first) only filled that same
   1250px box, since 100% of a boxed parent is still boxed.
   Widening the parent (64b91e8) or its shared inner wrapper would also
   widen the other 4 sibling containers, which weren't part of this
   request -- not safe to touch. A box-shadow spread is the standard
   "full-bleed inside a boxed layout" technique: it paints white far past
   this element's own edges without changing its actual box, so the other
   4 siblings' width and layout are untouched. clip-path keeps the spread
   from being clipped oddly by any ancestor. */
.elementor-element-8be06ae {
  position: relative;
  box-shadow: 0 0 0 100vmax var(--jr-color-surface);
  clip-path: inset(0 -100vmax);
}

/* The "Service Areas ends / Roofing - Manchester begins" triangle divider
   (Elementor shape_divider_top on this same 8be06ae node) has the same
   boxed-width problem the background above had: it's a DIRECT child of
   .elementor-element-8be06ae (position:relative, an Elementor default --
   not something added here), so its own position:absolute sizes against
   that same ~1225px boxed box, not the viewport. Unlike the flat white
   background, box-shadow can't fix this -- it's an actual SVG shape that
   has to BE wider, not just color-extended past its box. Standard
   full-bleed break-out instead: 100vw + recenter.
   2026-08-20 correction: the FIRST attempt at this put overflow-x:hidden
   (needed to trim what 100vw over-adds for Chrome's scrollbar gutter) on
   .elementor-element-64b91e8 -- broke the background fix above, since
   that also relies on painting outside 8be06ae's own box, and 64b91e8 is
   a tall flex container whose own layout got disturbed by the overflow
   change too. Scoped to `html` instead: same scrollbar-gutter trim, but
   html has no flex children or height dependencies to disturb, and it's
   already the true full-bleed reference the divider is trying to reach. */
html {
  overflow-x: hidden;
}

.elementor-element-8be06ae > .elementor-shape-top {
  left: 50% !important;
  width: 100vw !important;
  /* margin-left, not transform -- Elementor already puts its own
     rotate/flip transform on this element (that's what makes the shape
     point the direction it does); a transform here would fight that
     same property and one of the two silently loses. margin-left does
     the identical "shift back to center after left:50%" job without
     touching a property Elementor is already using. */
  margin-left: -50vw !important;
  /* Owner also flagged it rendering behind other elements -- raise it
     above the section's own content stacking. */
  z-index: 3;
}

/*
 * Canonical button classes -- for any section built in plain code (not
 * Elementor). The two rules above exist only because Elementor bakes
 * per-widget inline styles into each page's own data that have to be
 * overridden with !important; a hand-coded section has no such baggage,
 * so it should use these classes directly instead of reinventing button
 * styling locally. Same two intents, same values, single source either
 * way -- .jr-btn-primary / .jr-btn-secondary are what a NEW component
 * reaches for; the .elementor-button overrides above stay only for
 * sections that haven't been migrated out of Elementor yet.
 */
.jr-btn {
  display: inline-block;
  padding: 20px 40px;
  border-radius: 4px;
  font-family: var(--jr-font-action);
  font-size: 15px;
  font-weight: 700;
  line-height: 1;
  text-transform: uppercase;
  text-decoration: none;
  text-align: center;
  transition: background-color 0.2s ease, border-color 0.2s ease;
}

.jr-btn-primary {
  border: 1px solid var(--jr-color-primary);
  background: var(--jr-color-primary);
  color: #fff;
}

.jr-btn-primary:hover,
.jr-btn-primary:focus-visible {
  background: var(--jr-color-primary-dark);
  border-color: var(--jr-color-primary-dark);
  color: #fff;
}

/* Secondary has two variants -- translucent white only reads against a
   dark/photo surface; on a light surface it's white-on-white and
   disappears. No single flat color solves both directions (a solid fill
   has the identical problem in reverse: graphite-on-graphite would
   vanish on the hero, which IS graphite-toned). Pick the variant that
   matches the surface behind the button, not one universal color.
   -dark: on graphite, photo overlays, anything dark-toned.
   -light: on white/warm-off-white sections. Solid fill (not translucent)
   since a light surface needs real contrast, not transparency. Same
   graphite already in the purged palette (Colores_y_Tipografia
   2026-08-19) -- reused, not invented -- and the same recipe the quiz
   landing page's .jr-button--secondary already used on its own, now
   promoted here so every section shares one definition. */
.jr-btn-secondary-dark {
  border: 1px solid rgba(255, 255, 255, 0.6);
  background: rgba(255, 255, 255, 0.29);
  color: #fff;
}

.jr-btn-secondary-dark:hover,
.jr-btn-secondary-dark:focus-visible {
  background: rgba(255, 255, 255, 0.42);
  border-color: #fff;
  color: #fff;
}

.jr-btn-secondary-light {
  /* Thin brand-red border added 2026-08-19 -- the graphite fill alone
     still read as low-contrast against a busy photo (as opposed to a
     flat white section, where graphite pops fine on its own). Red edge
     gives it a second, color-based signal that doesn't depend on
     whatever's directly behind the button. */
  border: 1px solid var(--jr-color-primary);
  background: var(--jr-color-graphite);
  color: #fff;
}

.jr-btn-secondary-light:hover,
.jr-btn-secondary-light:focus-visible {
  background: var(--jr-color-surface-dark);
  border-color: var(--jr-color-surface-dark);
  color: #fff;
}

@media (max-width: 767px) {
  .jr-btn {
    padding: 15px 25px;
  }
}

/*
 * Floating "Call Us" button -- the site's single primary conversion path,
 * present on every page (see jr_floating_call_button() in functions.php).
 * Bottom-right, above everything (z-index higher than the sticky header's
 * 1200), pill shape so it reads as an action, not a form field.
 */
.jr-floating-call {
  position: fixed;
  right: 1.25rem;
  bottom: 1.25rem;
  z-index: 9999;
  display: flex;
  align-items: center;
  gap: 0.5rem;
  padding: 0.85rem 1.25rem;
  border-radius: 999px;
  background: var(--jr-color-primary);
  color: #fff;
  font-weight: 700;
  font-size: 0.95rem;
  text-decoration: none;
  box-shadow: 0 8px 24px rgba(0, 0, 0, 0.25);
  transition: transform 0.15s ease, box-shadow 0.15s ease;
}

.jr-floating-call:hover,
.jr-floating-call:focus-visible {
  color: #fff;
  transform: translateY(-2px);
  box-shadow: 0 12px 28px rgba(0, 0, 0, 0.3);
}

.jr-floating-call__icon {
  width: 1.25rem;
  height: 1.25rem;
  flex-shrink: 0;
}

@media (max-width: 480px) {
  /* Label stays visible on phones too -- a bare icon reads as decoration,
     not a call-to-action. Just a smaller pill/gap than desktop. */
  .jr-floating-call {
    padding: 0.7rem 1rem;
    gap: 0.4rem;
    font-size: 0.85rem;
  }
  .jr-floating-call__icon {
    width: 1.1rem;
    height: 1.1rem;
  }
}