/* ============================================================
   KUHN ELEMENTOR KIT — structural reset
   ------------------------------------------------------------
   The static design assumes this DOM:

       body > main > section > .container

   Elementor renders this instead:

       body > .elementor > .e-con > .elementor-widget
              > .elementor-widget-container > section > .container

   Three things break as a result:

     1. `.e-con` is a flex container. `position: sticky` on `.sticky-col`
        stops working, and GSAP's `pin: true` on the services ride cannot
        insert its spacer correctly.
     2. Selectors written against the original hierarchy stop matching.
     3. Container padding and flex `gap` add their own spacing on top of
        the section rhythm, so everything drifts.

   The fix is to make the wrappers transparent to layout, so the browser
   computes the page exactly as it did in the static file. Every widget
   sits in a container carrying `.kek-shell`, which the importer writes,
   so this is scoped to our own sections and leaves the rest of the
   client's Elementor content untouched.

   Skipped inside the editor: Elementor needs the real boxes there to
   draw its handles and drop zones.
   ============================================================ */

/* `.kek-shell` is added at render time by the plugin and, as a convenience,
   written into the imported JSON. The :has() selectors below are a second
   route to the same containers, straight from the content: if the class ever
   fails to land — an Elementor change, a hand-built page, a template edited
   elsewhere — the reset still reaches them. */
body:not(.elementor-editor-active) .e-con:has(> .e-con-inner > .elementor-widget[data-widget_type^="kek-"]),
body:not(.elementor-editor-active) .e-con:has(> .elementor-widget[data-widget_type^="kek-"]),
body:not(.elementor-editor-active) .e-con:has(> .e-con-inner > .elementor-widget[data-widget_type^="kek-"]) > .e-con-inner,
body:not(.elementor-editor-active) .kek-shell,
body:not(.elementor-editor-active) .kek-shell > .e-con-inner {
  display: block;
  width: 100%;
  max-width: none;
  padding: 0;
  margin: 0;
  gap: 0;
  min-height: 0;
  --padding-top: 0px;
  --padding-right: 0px;
  --padding-bottom: 0px;
  --padding-left: 0px;
  --gap: 0px;
  --content-width: 100%;
}

/* The widget shells carry no box of their own.
   `display: contents` was the obvious choice here and it is the wrong one:
   ScrollTrigger pins by inserting a .pin-spacer where the section was and
   switching the section to position:fixed. If the spacer's parent has been
   removed from the box tree, GSAP has nothing to measure against and the
   services ride scrolls past instead of pinning.
   A plain block with a zeroed box model is layout-neutral for full-width
   block sections and keeps the spacer's parent real. */
body:not(.elementor-editor-active) .elementor-widget[data-widget_type^="kek-"],
body:not(.elementor-editor-active) .elementor-widget[data-widget_type^="kek-"] > .elementor-widget-container,
body:not(.elementor-editor-active) .kek-shell .elementor-widget,
body:not(.elementor-editor-active) .kek-shell .elementor-widget > .elementor-widget-container {
  display: block;
  width: 100%;
  max-width: none;
  margin: 0;
  padding: 0;
}

/* Elementor sets `overflow: hidden` on containers in several presets.
   A pinned ScrollTrigger inside an overflow-clipped ancestor never
   releases, so the services ride would freeze half-scrolled. */
body:not(.elementor-editor-active) .kek-shell,
body:not(.elementor-editor-active) .e-con:has(.elementor-widget[data-widget_type^="kek-"]) {
  overflow: visible;
}

/* The original scoped this to `main > section`; after the reset our
   sections are no longer direct children of <main>, so restore it by
   class instead. */
body:not(.elementor-editor-active) .kek-shell section > .container,
body:not(.elementor-editor-active) .elementor-widget[data-widget_type^="kek-"] section > .container {
  will-change: transform;
}

/* No image or figure rules here on purpose.
   This sheet loads after core.css, so any base rule repeated here re-applies
   itself on top of core.css's own overrides and wins on equal specificity.
   Two bugs came from exactly that:

     `.kek-shell img { height: auto }`  undid `.fig-media img { height: 100% }`
                                        and collapsed every ratio box.
     `.kek-shell figure { margin: 0 }`  undid `.cockpit-fig { margin: 1.5rem 0 0 }`
                                        and `.modell-fig { margin: 0 0 1.25rem }`,
                                        shifting two sections by 24px and 20px.

   core.css already handles both. Leave them to it. */

/* Canvas template has no theme wrapper, but the boxed template does;
   neither should constrain a full-bleed band. */
body:not(.elementor-editor-active) .kek-shell section {
  width: 100%;
}

/* ---- Editor-only affordance --------------------------------
   With `display: contents` disabled in the editor the sections
   still need to not collide with Elementor's own padding. */
body.elementor-editor-active .kek-shell,
body.elementor-editor-active .kek-shell > .e-con-inner {
  padding: 0;
  gap: 0;
  max-width: none;
}

/* ============================================================
   The sticky header must escape its wrapper
   ------------------------------------------------------------
   `position: fixed` is only relative to the viewport while no
   ancestor creates a containing block for it. Any ancestor with
   a transform, a filter, a perspective, `will-change: transform`
   or `contain` takes that job over — and then the sticky header
   is the width of that ancestor instead of the width of the
   window. In a Theme Builder template that ancestor is a boxed
   Elementor container, so the header comes back on scroll-up as
   a floating bar in the middle of the page with the hero showing
   either side of it.

   Nothing between <body> and the header may do that.
   ============================================================ */

body.kek-scope .elementor-location-header,
body.kek-scope .elementor-location-footer,
body.kek-scope .elementor-location-header > .e-con,
body.kek-scope .elementor-location-footer > .e-con,
body.kek-scope .elementor-location-header .e-con-inner,
body.kek-scope .elementor-location-footer .e-con-inner,
body.kek-scope .e-con:has(.elementor-widget[data-widget_type^="kek-header"]),
body.kek-scope .e-con:has(.elementor-widget[data-widget_type^="kek-footer"]),
body.kek-scope .e-con:has(.elementor-widget[data-widget_type^="kek-header"]) > .e-con-inner,
body.kek-scope .e-con:has(.elementor-widget[data-widget_type^="kek-footer"]) > .e-con-inner,
body.kek-scope .elementor-widget[data-widget_type^="kek-header"],
body.kek-scope .elementor-widget[data-widget_type^="kek-footer"],
body.kek-scope .elementor-widget[data-widget_type^="kek-header"] > .elementor-widget-container,
body.kek-scope .elementor-widget[data-widget_type^="kek-footer"] > .elementor-widget-container {
  transform: none;
  filter: none;
  perspective: none;
  will-change: auto;
  contain: none;
  max-width: none;
  width: 100%;
  margin: 0;
  padding: 0;
  overflow: visible;
}

/* The header spans the window, whatever it is nested in.
 *
 * The padding is not decoration here. Elementor's Header & Footer Builder
 * styles `.site-header` directly and gives it 16px top and bottom; the design
 * gives it none, because its height comes from the two bars inside it. With
 * that padding the header measured 100px where it should measure 68 — so it
 * hid by the wrong distance and never sat where it belonged, which is what
 * showed as a strip of the page above it.
 *
 * Same for the margin: a header positioned by `inset` should not be nudged. */
body.kek-scope .site-header {
  width: 100%;
  max-width: none;
  left: 0;
  right: 0;
  padding: 0;
  margin: 0;
}

/* And the two bars carry their own spacing — nothing outside may add to it. */
body.kek-scope .site-header > .utility-bar,
body.kek-scope .site-header > .main-bar {
  margin: 0;
}

/* The footer band is full-bleed too — the prefooter card inside it is what
   carries the container width, not the footer itself. */
body.kek-scope .site-footer {
  width: 100%;
  max-width: none;
}

/* ============================================================
   The theme lays out our header and footer
   ------------------------------------------------------------
   Hello Elementor — and it is not alone — styles `.site-header`
   and `.site-footer` as flex containers, using the same class
   names the design uses. The design never states a display for
   them, because as a standalone page it never had to, so the
   theme's rule wins.

   The consequence is quiet and confusing. A bar that expected to
   fill the header becomes a flex item sized to its own content.
   Its content is a 1200px row, so the bar is 1200px wide and
   sits hard against the left while the header itself correctly
   spans the window. Nothing carries a max-width, nothing is
   confining anything, and yet the whole header leans left.

   Stating the display is the whole fix.
   ============================================================ */

body.kek-scope .site-header,
body.kek-scope .site-footer {
  display: block;
}

/* The bars inside the header fill the width; the `.container`
   within each one holds the 1200px and centres itself inside it.
   The footer's own children are already `.container` elements —
   widening those would push the whole footer edge to edge, so
   they are deliberately not listed here. */
body.kek-scope .site-header > .utility-bar,
body.kek-scope .site-header > .main-bar {
  width: 100%;
  max-width: none;
}

/* ============================================================
   Elementor Theme Style — buttons
   ------------------------------------------------------------
   Site Settings → Theme Style → Buttons writes rules like
   `.elementor-kit-5 button { background-color: …; color: …;
   padding: … }`. A great many of the design's controls are real
   <button> elements — the FAQ questions, the analysis phase
   list, the problem-picker chips, the before/after tabs, the
   quote arrows, the burger, the navigation's mega-menu trigger
   — and they all inherited the kit's button colour. That was the
   pink.

   Since core.css is scoped, its own two-class rules already
   outrank the kit on everything it states. What it does not
   state, because a standalone page never had to, is that these
   buttons carry no surface, no colour and no padding of their
   own: they inherit. Only those three are restored here.

   The specificity matters as much as the properties. One class
   and two elements: above `.elementor-kit-N button`, below every
   scoped rule in core.css. Pitched any higher and the design
   loses to its own defence — which is exactly what happened when
   this block was written with four `:not()` clauses. The
   navigation's mega-menu trigger, the one nav item that is a
   button, went dark against a dark header while its neighbours
   stayed white; the burger and the close button lost their
   padding; the section rail lost its colour.
   ============================================================ */

body.kek-scope button {
  /* `revert`, not a value of our own.
   *
   * These properties are not stated by the design because the browser's own
   * button styling was already what it wanted — the burger's 1px 6px padding
   * comes from there, not from the stylesheet. Writing `padding: 0` here
   * looked harmless and flattened the burger and the close button. `revert`
   * puts back exactly what the browser would have done had the kit never
   * written anything, which is the condition the design was drawn against. */
  /* `color` and `padding` are load-bearing: removing either makes the
     comparison fail (the section rail loses its colour, the burger and the
     close button lose their padding). `background-color` is precautionary —
     the scoped stylesheet already covers every button the design draws, but a
     button the client adds later would otherwise arrive in the kit's colour. */
  background-color: revert;
  color: revert;
  padding: revert;
}

/* ============================================================
   Hover belongs to the design too
   ------------------------------------------------------------
   The reset above puts a button's resting appearance back to
   what the browser would have given it. It says nothing about
   `:hover`, so a theme's `button:hover` rule still applied —
   and hovering a FAQ question painted it pink where the design
   leaves it untouched.

   These are the controls the design draws as plain text: they
   change colour and border on hover and nothing else. Stated
   here so nothing outside can decide otherwise. The buttons the
   design *does* fill on hover — `.btn-primary` and its
   relatives — carry their own rules at higher specificity and
   are unaffected.
   ============================================================ */
body.kek-scope .faq-q:hover,
body.kek-scope .faq-q:focus,
body.kek-scope .faq-q:active,
body.kek-scope .nav-link:hover,
body.kek-scope .nav-link:focus,
body.kek-scope .proc-step:hover,
body.kek-scope .proc-step:focus,
body.kek-scope .chip:hover,
body.kek-scope .bl-chip:hover{
  background-color: transparent;
}