/* =========================================================
   Platform patches. Only things WordPress or Hello Elementor
   impose on our markup live here, so the design system in
   /assets/css stays free of CMS-specific workarounds.
   Loaded after site.css.
   ========================================================= */

/* Hello Elementor's theme.css and header-footer.css are dequeued in functions.php:
   they ship a second, conflicting design system that claims .site-header,
   .site-footer, .site-main and — worst of all — paints every button #c36 on hover.
   These rules stay as a safety net in case those stylesheets ever come back.

   `padding-block: 0` used to be in this list and had to come out: the design gives
   .site-footer a 32px bottom padding, and this rule — a class plus a :not(), so two
   classes, loaded after the design — silently won and every page came out 32px short.
   A safety net must not outrank the thing it is protecting. Hello Elementor is
   dequeued by file path in functions.php, which is the real defence; these are only
   the properties the design never sets itself, so nothing here can beat it. */
.site-header:not(.dynamic-header),
.site-footer:not(.dynamic-footer) {
  width: auto;
  max-width: none;
  margin-inline: 0;
}

body:not([class*="elementor-page-"]) .site-main {
  width: auto;
  max-width: none;
  margin-inline: 0;
}

/* Every interactive control here defines its own hover in the component CSS.
   A blanket hover colour from the theme has to be neutralised without painting a
   background of its own, or controls that rely on their resting background would
   go transparent on hover.

   The selectors are wrapped in :where() so this weighs a single pseudo-class and loses
   to every design rule. Written plainly, `[type="button"]:hover` is an attribute plus a
   pseudo-class — exactly as specific as `.filter-chip[aria-pressed="true"]` — and since
   this file loads later it won. The selected FAQ category chip therefore went
   transparent with dark text while the pointer was still on it, so its white count badge
   disappeared against the white page and came back only once the chip lost focus.

   Hello Elementor is dequeued by file path in functions.php, and that is the real
   defence against its `button:hover { background-color: #c36 }`. This is only a net for
   buttons nothing else styles, so it must never outrank something that does.

   The pseudo-class goes inside :where() too, so the whole thing weighs nothing at all.
   With it outside, this was one pseudo-class — a tie with `.filter-chip { background:
   #fff }` — and, loading later, it won and made an unselected chip's hover background
   transparent instead of white. */
:where(
  button:hover, button:focus,
  [type="button"]:hover, [type="button"]:focus,
  [type="submit"]:hover, [type="submit"]:focus,
  [type="reset"]:hover, [type="reset"]:focus
) {
  background-color: unset;
  color: unset;
}

body {
  background-color: var(--ink-950);
}

/* Elementor wraps shortcode output in a widget container with its own spacing.
   Our sections own their rhythm, so take Elementor's off. */
.elementor-widget-isramizug_module > .elementor-widget-container {
  margin: 0;
  padding: 0;
}

/* The few WordPress content classes worth keeping from the dequeued theme stylesheet,
   for prose pages that Elementor will own later. */
.alignright { float: right; margin-inline-start: 1rem; }
.alignleft { float: left; margin-inline-end: 1rem; }
.aligncenter { display: block; margin-inline: auto; }
.wp-caption { max-width: 100%; }
.wp-caption-text { font-size: 0.875rem; color: var(--text-500); }
.screen-reader-text {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  overflow: hidden;
  clip-path: inset(50%);
  white-space: nowrap;
  border: 0;
}

/* -----------------------------------------------------------------
   Prose rhythm is NOT restated here any more.

   It used to be, because Elementor wraps each block in a <div class="elementor-widget">
   and the design's `.prose > * + *` therefore stopped matching. Two hand-written rules
   put the spacing back, and both were wrong in ways that were invisible in the file:
   they targeted a .elementor-widget-container that this Elementor build does not render
   at all, and they carried three classes where the design carries one, so they outranked
   `.prose h2` and flattened the heading spacing.

   elementor-flex.css now generates the equivalents straight from the design's own
   stylesheets, with the wrapper in :where() so each rewritten rule weighs exactly what
   the original weighs. That keeps the design's rules in the same order of precedence
   they have in the static build, which hand-written restatements kept getting wrong.
   ----------------------------------------------------------------- */

/* A container that exists only to host one of our modules adds nothing of its own. */
.im-module-host,
.im-module-host.e-con {
  padding: 0;
  gap: 0;
  max-width: none;
}

/* -----------------------------------------------------------------
   Pages converted to native Elementor widgets (.im-native).
   The design owns every margin already; Elementor's container gap and
   per-widget spacing would add to it and stretched a converted service
   page by 20%. Scoped to converted pages so anything the client builds
   fresh in Elementor keeps its normal spacing behaviour.
   ----------------------------------------------------------------- */
/* An Elementor container is display:flex; flex-direction:column by default, which
   overrode the design's own layout — buttons meant to sit in a row stacked instead.
   Inside converted pages the containers are plain blocks and the design's own
   display/flex/grid rules decide the layout, exactly as in the static build.
   Padding is left alone: the sections' padding is part of the design. */
/* :where() makes this rule specificity-zero. Written normally it is two classes and
   outranks the design's own single-class layout rules — .page-hero__grid { display:
   grid } lost to it and every grid collapsed into a stack. At zero specificity it only
   applies where the design says nothing, which is exactly the intent: undo Elementor's
   default, never override ours. */

/* Elementor containers are flex, and a flex item defaults to min-width:auto, which
   refuses to shrink below its own content. The mobile service carousels are horizontal
   scrollers, so inside a flex container they sized to their full scroll width and
   pushed the page 600px wide. Letting items shrink restores the scroller.

   Every part is wrapped in :where() so the rule carries no specificity at all. Written
   normally it is two classes and beat the design's own min-width — the troubleshooting
   panel's urgency meter is `min-width: 150px` and came out 87px. At zero specificity it
   only applies where the design says nothing, which is exactly the intent. */
:where(.im-native) :where(.e-con) > *,
:where(.im-native) :where(.elementor-widget) > *,
:where(.im-native) :where(.elementor-widget-container) > * {
  min-width: 0;
}
/* The decisive one. Elementor wraps every widget in two divs, which land between a
   layout container and its children — so `.hero__actions { display: flex }` was laying
   out the wrappers, not the buttons, and the buttons stacked. display:contents removes
   the wrappers from layout entirely, so the design's flex and grid rules apply to the
   real elements exactly as they do in the static build. The wrappers carry no styling
   of their own, so nothing is lost by making them invisible to layout. */
.im-native .elementor-widget:not(.brand__logo),
.im-native .elementor-widget > .elementor-widget-container,
.im-native .elementor-button-wrapper {
  display: contents;
}
/* The logo is the one widget that has to keep its box. Elementor puts a widget's CSS
   classes on the wrapper, so .brand__logo — which is what sizes the lockup and what
   swaps the wide version for the compact one below 420px — lands on the wrapper and
   nowhere else. Made display:contents, the wrapper stops being a box, both lockups
   stay visible, and the two of them share the space the header gives one: the logo
   rendered 48px wide instead of 151px, at the correct height, so it looked squashed
   rather than missing. These rules repeat the design's own, at the weight needed to
   outrank the two-class rule above. */
.im-native .brand__logo { display: block; }
.im-native .brand__logo--compact { display: none; }
@media (max-width: 420px) {
  .im-native .brand__logo--full { display: none; }
  .im-native .brand__logo--compact { display: block; }
}
/* Elementor ships `.elementor-widget-image a img[src$=".svg"] { width: 48px }`, on the
   reasonable assumption that an SVG has no intrinsic size and would otherwise fill its
   container. Ours declares width and height, and the design sizes it by height. That
   selector is one class, one attribute and two elements, which outranks the design's
   `.brand .brand__logo img`, so the logo came out 48px wide at the right height —
   correct-looking at a glance and badly squashed on measurement. The attribute
   selector is repeated here so the weights match and the extra class decides it. */
.im-native .brand__logo a,
.im-native .brand__logo a img[src$=".svg"],
.im-native .brand__logo img {
  display: block;
  width: auto;
  height: 46px;
  max-width: none;
}
@media (max-width: 640px) {
  .im-native .brand__logo a,
  .im-native .brand__logo a img[src$=".svg"],
  .im-native .brand__logo img {
    height: 40px;
  }
}

/* -----------------------------------------------------------------
   The header navigation is a real WordPress menu, so WordPress marks
   the current page itself. Its submenu markup differs slightly from
   the designed markup, so the design's own selectors are extended to
   the classes WordPress emits.
   ----------------------------------------------------------------- */
.main-nav .menu-item-has-children > a::after {
  content: none;
}
.main-nav .sub-menu {
  margin: 0;
  padding: 0;
  list-style: none;
}