/* Product strip.
 *
 * HIDDEN BY DEFAULT, because that is what the original does. On the live site
 * the products sit inside a floating widget that renders closed
 * (ufw_wb_closed ufw_wb_hidden) and #shopwp-root measures 0px — nothing appears
 * in the page flow. An earlier version of this rendered a visible 239px strip,
 * which added exactly that much height to every page and produced a large pixel
 * mismatch on all of them. DR-002 said "same position"; a visible in-flow strip
 * is not the same position.
 *
 * The heading stays in the DOM regardless: it counts toward the heading outline
 * on 58 of 59 pages and the SEO gate blocks on losing it.
 */
.product-strip {
  position: absolute;
  width: 1px; height: 1px;
  margin: -1px; padding: 0; border: 0;
  overflow: hidden; clip: rect(0 0 0 0); clip-path: inset(50%);
  white-space: nowrap;
}

/* Full-bleed rows and sections, reproduced responsively.
 *
 * WPBakery's script pulls these to the viewport edge and pads them back so the
 * inner content still lines up with the container. It writes that in pixels for
 * whatever viewport it ran at, which a static page cannot do, so the same
 * intent is expressed here in CSS that responds.
 *
 * Measured on live, offsets in px:
 *
 *              375    768   1440
 *   parent x    15     39    165
 *   section     15     39    165     padding == parent x
 *   row          0     24    150     padding == parent x - 15
 *
 * Rows sit 15px lower than sections because .vc_row carries a -15px gutter
 * margin of its own, which its columns' 15px padding cancels. Sections have no
 * such margin. Getting that 15px wrong misaligns every column on the page
 * against the text above and below it.
 *
 * Offset with `left`, not negative margins. WPBakery's own per-element custom
 * CSS emits `.vc_custom_<id> { margin: 0 !important }` in an inline <style>,
 * which beats any margin rule from a stylesheet — so the live site cannot use
 * margins here either, and does exactly this: position:relative + a negative
 * left + width:100vw. A margin-based version of this rule computed the right
 * padding and silently did nothing about the width.
 *
 * Keyed on the data attribute WPBakery itself marks these with, not on a class.
 * The previous rule here targeted .vc_row-has-fill, which the homepage's
 * full-width block does not carry — it is a <section> with vc_section-has-fill —
 * so the homepage hero was never full-bleed on the static site. It rendered
 * 30px narrower than live, which pushed the h1 onto three lines instead of two
 * and shifted everything below it.
 */
[data-vc-full-width="true"] {
  position: relative;
  box-sizing: border-box;
  left: calc(50% - 50vw);
  width: 100vw;
  max-width: 100vw;
  padding-left: calc(50vw - 50%);
  padding-right: calc(50vw - 50%);
}

.vc_row[data-vc-full-width="true"] {
  left: calc(50% - 50vw + 15px);
  padding-left: calc(50vw - 50% - 15px);
  padding-right: calc(50vw - 50% - 15px);
}

/* Content stretched edge to edge gets no padding at all. */
[data-vc-stretch-content="true"],
.vc_row[data-vc-stretch-content="true"] {
  padding-left: 0;
  padding-right: 0;
}