/* ------------------------------------------------------------------
   Heyrnarstöðin — mobile layout fixes.

   Loaded AFTER custom.css and refresh.css by
   templates/shaper_helixultimate/index.php, so it is the last word on
   layout without editing either of those files.

   custom.css  = "what the old Floox site looked like"
   refresh.css = "what we changed on purpose in 2026"
   mobile.css  = "what responsive layout needs" — this file.

   Most of it is inside a max-width media query, but not all: several of the
   faults below are the same migrated value going wrong at every width, not
   only on phones, and those are fixed once rather than twice. §1 and §3
   (hero image sizing) and §8 (slider alignment) are the width-independent
   ones.

   ── Why any of this is needed ──────────────────────────────────────
   The page content was migrated from SP Page Builder 3 to SPPB 6, and the
   two builders disagree about responsive settings in three ways. Every
   rule below traces back to one of them:

   1. SPPB 3 shipped its own mobile stylesheet (e.g. it hid slider text and
      buttons below 600px). SPPB 6 does not, so content that used to be
      hidden or reflowed now renders at its desktop geometry.

   2. Breakpoint values CASCADE DOWN in SPPB 6. A setting entered only for
      xl now also applies at sm — so desktop-only nudges leak onto phones.
      The booking form's 36px/75px offset is the clearest case: authored
      for desktop, inherited by every phone.

   3. SPPB 3 ignored some per-breakpoint values that SPPB 6 honours, so
      stale numbers left in the page data (image widths in px, hand-tuned
      negative offsets) suddenly took effect.

   The stale numbers live in the page JSON in the database, not in any
   file. Correcting them there means ~20 edits invisible to version
   control, which also have to be repeated against the production
   database. These rules neutralise them at the template level instead,
   which keeps the fix in git and covers pages added later.

   Breakpoint: 767.98px throughout, matching Bootstrap 5 / Helix and the
   `md` breakpoint SPPB 6 itself emits — so these rules turn on exactly
   where SPPB's own mobile rules do, never half a breakpoint out.
   ------------------------------------------------------------------ */


/* 1. Images never outgrow their column
   ------------------------------------
   SPPB writes the image addon's width setting as a fixed pixel pair —
   `width: 1140px; max-width: 1140px` — with no percentage fallback. The
   sub-page hero images are all set to 1140px (a few to 731/860/975 for
   the small breakpoints), so below a ~1440px viewport they are wider than
   the column that holds them and spill out of it: at 390px the Fróðleikur
   hero rendered 860px wide, i.e. a 2.3× zoom into the middle of the photo.

   Re-capping max-width at 100% restores normal responsive behaviour — the
   image draws at its set width when there is room and shrinks when there
   is not — and height:auto keeps the aspect ratio while it shrinks.

   Deliberately NOT inside a media query: the overflow starts at ~1440px,
   so this is a desktop fix as much as a mobile one. At 1440px and wider
   the column is roomier than 1140px and the cap never engages, so the
   intended desktop size is untouched. */

.sppb-addon-single-image img,
.sppb-addon-image img {
	max-width: 100% !important;
	height: auto !important;
}


/* 2. Per-addon position nudges
   ---------------------------
   SPPB's "custom position" setting emits `position: relative` plus a left
   and top offset on the addon wrapper. Two sets of these are wrong on a
   phone, for the two different reasons above:

   a) The booking form carries left:36px / top:75px entered at xl only.
      Under SPPB 6's cascade that reaches phones, where it pushed the form
      36px right of its column — enough to run its right edge ~21px past
      the screen — and 75px down into the section below.

   b) Four hero images carry large negative left offsets entered ONLY for
      the small breakpoints (-362px on Fróðleikur, -379px on Ókeypis
      heyrnarmæling, -180/-80px on Um okkur, -100px on Tenglar). Those were
      manual re-centring for the oversized render that §1 has now fixed:
      with the image no longer overflowing there is nothing left to
      compensate for, and the offset just drags it off the left edge.

   Zeroed rather than overridden with new numbers, because the correct
   offset once the widths are right is simply none. The home page's three
   promo cards also match this selector; their nudge is top:12px, so they
   shift up by 12px on phones and are otherwise unaffected. */

@media (max-width: 767.98px) {
	.sppb-addon-wrapper.addon-root-image,
	.sppb-addon-wrapper.addon-root-ajax-contact {
		left: 0 !important;
		top: 0 !important;
	}
}


/* 3. Sub-page hero image spans the full content width
   ---------------------------------------------------
   The hero is set to a fixed 1140px, which was the whole page container on
   the old Helix 3 site — at every desktop width the hero and the body copy
   below it lined up, because both were 1140px.

   Bootstrap 5 (and so Helix Ultimate) has a wider tier: the container grows
   to 1320px from 1400px up. The body copy follows it, the hero cannot, and
   the page ends up with its text and booking form sticking out 90px past
   each edge of the image above them — the wider the screen, the more
   obvious. §1's max-width cap stops the image overflowing, but a cap alone
   cannot make it GROW to meet a container that is now wider than it.

   Letting the image fill its column restores the old relationship — hero
   and content are the same width again — and keeps it at every future
   container size rather than at one hard-coded number. The source files are
   1940px wide, so there is headroom above the 1320px tier and the image is
   still being scaled down, never up.

   Its column KEEPS the grid's 15px, which is what puts the hero's left edge
   on the page's one left margin (§10) — the same line the logo above it and
   the body copy below it sit on. That is the alignment the old site had, by
   a different route: there the hero overhung its column by 15px on each side
   and the template's Custom CSS pulled the logo 15px left to meet it

       @media screen and (min-width: 800px) { .sp-default-logo { left: -15px } }

   so both landed on the container's OUTER edge. Two elements stepped off the
   margin together. Here they both stand on it instead, which reaches the same
   logo-to-hero alignment and additionally squares the hero with the slide
   text and the booking form that §8 and §9 put on that line.

   Scoped by :has() to the first section AND to sections that actually
   contain an image addon, so it only ever matches a sub-page hero. On the
   home page the first section holds the slider, which has no
   .sppb-addon-single-image, so the selector correctly matches nothing there
   and the promo cards further down keep their gutter.

   Note the body section keeps its own 36px left padding, which offsets the
   copy a further ~28px to the right of the hero. That asymmetry was on the
   old site too and is left alone here — this section is about the hero's
   SIZE and edges, not about that inherited nudge. */

.page-content > .sppb-section:first-child:has(.sppb-addon-single-image) .sppb-addon-single-image img {
	width: 100% !important;
}


/* 3b. …and is zoomed and left-anchored on phones
   ----------------------------------------------
   The hero photographs are 1940×620 — a 3.1:1 letterbox, drawn that shape
   because on a desktop it spans 1140px and is 364px tall. Scale the whole
   frame down to a 390px phone and it becomes a 120px ribbon: technically
   the same picture, but too thin to read as one, and it makes the top of
   every sub-page look like a divider rather than a header.

   The old site did not shrink it either. It rendered the image 860px wide
   inside a ~345px column and pulled it left, so the phone showed a taller
   window onto part of the photo — zoomed and cropped, not scaled down.

   Same idea here, expressed as a percentage instead of the old site's fixed
   pixel width and negative offset: the image is drawn 140% of the page
   width and the overhang falls off the right, so the phone shows the
   left-hand ~71% of the picture at 1.4× the size it would otherwise be.
   A percentage keeps the same framing on every screen, where the old site's
   860px/-362px pair only worked at the width it was measured on.

   The 140% is the one number worth tuning here — raise it to zoom in
   further and show less, lower it toward 100% to show more of the frame.
   Height follows the aspect ratio on its own (168px at 390px wide, 262px at
   600px), so nothing else needs changing when it moves.

   Three supporting pieces, none of them optional:

   - max-width has to be released. §1 caps every image at 100% of its
     column, which would clamp this straight back to full width.
   - the container is text-align: center, which for an over-wide inline
     image means it hangs off BOTH sides equally. Left alignment is what
     makes it start at the left edge and run off only the right.
   - the section clips the overhang. Without it the 40% overflow widens the
     document and the whole page scrolls sideways.

   The row container is widened too. Below 576px it is already fluid, but
   between 576 and 767px Bootstrap caps it at 540px, which would leave the
   hero floating with margins while the phone layout around it is edge to
   edge. Overriding it keeps the hero full-bleed across the whole range.

   The 24px corner radius comes off with it. It was never visible on the old
   site's phone layout — the image hung off the edge of the screen, taking
   its corners with it — and on a full-bleed band, rounded corners cut two
   notches out of the top of the page. Desktop keeps the radius, where the
   hero is inset and the curve is doing what it was drawn to do. */

@media (max-width: 767.98px) {
	/* The gutter §3 leaves in place on desktop comes off here — on a phone the
	   hero is full-bleed, so its section and its column both have to give up
	   their side padding as well as the container's below. Zeroed only inside
	   this query, which is what keeps the desktop hero on the page margin. */
	.page-content > .sppb-section:first-child:has(.sppb-addon-single-image),
	.page-content > .sppb-section:first-child:has(.sppb-addon-single-image) [class*="sppb-col-"] {
		padding-left: 0 !important;
		padding-right: 0 !important;
	}

	.page-content > .sppb-section:first-child:has(.sppb-addon-single-image) .sppb-row-container {
		max-width: none !important;
		width: 100% !important;
		padding-left: 0 !important;
		padding-right: 0 !important;
	}

	/* The row carries Bootstrap's -15px gutter margins, which the container's
	   +15px padding normally cancels. Zeroing that padding above leaves the
	   negative margins unopposed and the hero ends up 30px wider than the
	   page, hanging 15px off each side — so they have to go together. */
	.page-content > .sppb-section:first-child:has(.sppb-addon-single-image) .sppb-row {
		margin-left: 0 !important;
		margin-right: 0 !important;
	}

	/* Keeps the 40% overhang from widening the document and turning the
	   whole page into a sideways scroll. */
	.page-content > .sppb-section:first-child:has(.sppb-addon-single-image) {
		overflow: hidden;
	}

	/* Without this the container's inherited text-align: center splits the
	   overhang across both edges — 20% lost off the left as well as the
	   right — instead of starting the image at the left edge. */
	.page-content > .sppb-section:first-child:has(.sppb-addon-single-image) .sppb-addon-single-image-container {
		text-align: left;
	}

	.page-content > .sppb-section:first-child:has(.sppb-addon-single-image) .sppb-addon-single-image img {
		width: 140% !important;
		/* §1 caps images at 100% of their column; without releasing that,
		   the 140% above resolves straight back to full width. */
		max-width: none !important;
		/* The aspect ratio does the rest — no fixed height and no object-fit
		   needed, because the image is not being squeezed into a box any
		   more, just drawn larger than the opening it shows through. */
		height: auto !important;
		border-radius: 0 !important;
	}
}


/* 4. Home slider — room for the text and the button
   -------------------------------------------------
   The slides carry a title, a paragraph and a green call-to-action
   button. On phones only the title was visible: the stage is 300px tall
   with overflow:hidden, and the slide content needed 384–435px, so the
   paragraph was cut in half and the button fell entirely below the fold.

   SPPB 3 hid the paragraph and the button outright below 600px, so this
   never showed on the old site. SPPB 6 dropped that rule and renders
   them — into a box still sized for a title alone.

   Two things fix it:

   a) The line-height. It is a flat 52px at every breakpoint, which suits
      the 74px desktop title (a deliberately tight 0.7) but is 1.7× the
      30px phone title — the single biggest waste of vertical space.
      A unitless 1.2 scales with whatever size the slide is set to, so the
      one slide that sets 70px keeps its proportions too.

   b) The stage height, which is set inline from the addon's own
      `custom_height` setting (300px for sm/xs) and so needs !important.
      460px fits the tallest slide's 339px of content with the leftover
      split evenly above and below by the slider's own vertical centring:
      61px of clearance at the top, which puts the title below the 50px
      fixed header rather than colliding with the logo.

   The slide titles are separate <p> elements — hard line breaks, three
   lines on every slide — so this height is stable across all of them
   rather than depending on where the text happens to wrap. */

@media (max-width: 767.98px) {
	.sp-slider .sp-slider-outer-stage {
		height: 460px !important;
	}

	.sppb-sp-slider-title {
		line-height: 1.2 !important;
	}

	/* Bootstrap's bottom margin on <p> would add ~16px per title line on
	   top of the line-height the rule above just tightened. */
	.sppb-sp-slider-title p {
		margin-bottom: 0;
	}
}


/* 5. Booking form fills the content width
   ---------------------------------------
   custom.css §6 pins the fields to `width: 275px !important` — the old
   site's measurement, and correct on desktop where the form sits in a
   narrow column beside the promo images. On a phone the column is the
   full width of the screen and the fields kept their 275px, leaving the
   form stranded in the middle of the content area.

   Percentage rather than a larger fixed width so it tracks the column at
   every screen size. It still needs !important to beat the custom.css
   rule, and the selector goes through .sppb-form-group for the same
   specificity reason documented there.

   The section padding is zeroed too. On sub-pages it is 36px on the left
   and 0 on the right — the mirror of the 36px addon offset removed in §2 —
   which would otherwise leave the form visibly off-centre. Zero rather than
   a gutter of its own because the grid column inside already carries 15px,
   and 15px is exactly the page's left margin (see §8): anything added here
   is on top of that and pushes the form off the line the logo and the slide
   text sit on. */

@media (max-width: 767.98px) {
	.sppb-section:has(.sppb-addon-ajax-contact) {
		padding-left: 0 !important;
		padding-right: 0 !important;
	}

	.sppb-addon-ajax-contact .sppb-form-group .sppb-form-control {
		width: 100% !important;
	}

	/* custom.css §7 pulls the whole form up 47px to line it up with the
	   promo images beside it. Nothing sits beside it on a phone — the
	   columns are stacked — so the pull just drags it into the section
	   above. */
	.sppb-addon-ajax-contact {
		top: 0;
	}

	/* On the home page the form and the three promo cards are columns of one
	   row, so on desktop the space between them is horizontal and no bottom
	   margin was ever needed. Stacked on a phone that leaves the submit
	   button sitting flush against the top of the first card — zero gap,
	   while the cards themselves are spaced 30px apart, so the form reads as
	   if it belongs to the picture below it.

	   40px rather than the cards' 30px: that rhythm is the spacing WITHIN a
	   run of cards, and the form is a different kind of block ending in a
	   full-width button. A slightly wider gap separates the two groups
	   instead of making the form look like a fourth card.

	   Applied to the form on every page, not just home. Elsewhere the form
	   is last in its section and the extra space falls before the footer,
	   which needs it just as much.

	   !important because SPPB writes the addon's own spacing as
	   `#sppb-addon-wrapper-1698313256826 { margin: 0px }`. One id outranks
	   any number of classes, and the id is regenerated whenever the page is
	   rebuilt in the builder, so it cannot be matched here directly —
	   the same wall custom.css §6 and refresh.css §6 both hit. */
	.sppb-addon-wrapper.addon-root-ajax-contact {
		margin-bottom: 40px !important;
	}

	/* The submit button is a fixed 180px (120px on the home page) set in
	   custom.css §6. Matching it to the fields it belongs to reads as one
	   block and gives the primary action a full-width tap target. */
	.sppb-addon-ajax-contact .sppb-btn,
	body.itemid-109 .sppb-addon-ajax-contact .sppb-btn {
		width: 100%;
	}
}


/* 6. Section headings stop falling apart when they wrap
   -----------------------------------------------------
   The text_block headings carry line-height: 90px, from a value the old
   site stored for its desktop breakpoint only. SPPB 6 reads it as the base
   value and applies it everywhere, so on a phone a 24px heading gets 90px
   line boxes — 3.75× the type size.

   On one line that only reads as generous spacing, which is why it went
   unnoticed; on Fróðleikur the heading wraps to two and the halves drift
   apart far enough to look like separate headings.

   Unitless, so it stays proportional whatever size the heading is set to.
   Scoped to text_block: an audit of the rendered pages found these are the
   only titles with a runaway ratio — the booking form's own headings sit
   at a sane 1.57 and are left alone. Desktop keeps the 90px, where it is
   deliberate and matches the old site. */

@media (max-width: 767.98px) {
	.sppb-addon-text-block .sppb-addon-title {
		line-height: 1.3 !important;
	}

	/* Size, once the line-height above stopped the wrapping from breaking.
	   These fall through to the template's own `h3 { font-size: 24px }`,
	   which is a desktop measurement — in a 1140px column it has the width
	   around it to read as a section heading, and on a phone it lands too
	   close to the 16px body copy beneath it to open a new section clearly.
	   30px restores the step between the two.

	   Qualified with h3 and scoped to text_block deliberately: that is the
	   one heading per sub-page this is about. The booking form's own H2s sit
	   in the same page at 21px and are not section headings — they must not
	   be dragged along. */
	.sppb-addon-text-block h3.sppb-addon-title {
		font-size: 30px !important;
	}
}


/* 7. Off-canvas menu spacing
   -------------------------
   Helix draws the phone menu tight: 38px rows at the top level and 21px in
   the sub-menus, with nothing between them. Thirty links stacked at that
   pitch run together into a wall of text, and both sizes are under the 44px
   minimum tap target that WCAG 2.5.8, Apple's HIG and Material all land on
   — the sub-menu rows are less than half of it.

   Two separate mechanisms, because the two levels are built differently:

   - Top-level anchors are already display: block, so vertical padding
     lands: 13px takes the row to a round 44px.
   - Sub-menu anchors are display: INLINE. Their 4px padding does nothing to
     the row height — the 21px pitch is pure line-height, and the padding
     just overflows the list item invisibly. They need display: block before
     any padding counts at all.

   The margins on top of that are the actual gaps. Padding alone would give
   big tap targets that still touch each other; separating the rows is what
   makes the list scannable, and spacing between targets is also what WCAG
   accepts in place of raw size for the sub-menu's slightly smaller 34px.

   The expander arrows need no adjustment: Helix positions them with
   top: 50% and a -50% translate against the anchor, so they stay centred as
   the rows grow.

   No media query. The off-canvas panel is only reachable below 992px (its
   toggler is .d-lg-none) and is hidden otherwise, so the .offcanvas-menu
   scope limits this by itself — and it keeps working if the panel is ever
   switched on at wider sizes.

   This roughly halves again how much of the menu fits on screen at once;
   .offcanvas-inner already scrolls (overflow-y: auto), so the longer lists
   scroll rather than clip. */

.offcanvas-menu .offcanvas-inner ul.menu > li {
	margin-bottom: 6px;
}

.offcanvas-menu .offcanvas-inner ul.menu > li > a {
	padding-top: 13px;
	padding-bottom: 13px;
}

.offcanvas-menu .offcanvas-inner ul.menu ul.menu-child > li {
	margin-bottom: 4px;
}

.offcanvas-menu .offcanvas-inner ul.menu ul.menu-child > li > a {
	display: block;
	padding-top: 8px;
	padding-bottom: 8px;
}


/* 8. Slide text sits on the page's left margin
   --------------------------------------------
   The site has one left margin: the page container, plus its 15px inner
   padding. The logo sits on it at every width — 15px at 390, 37px at 1200,
   147px at 1600 — and so does the content below the hero.

   The slide text did not. custom.css §7 boxes it with

       max-width: 1200px; margin: auto; padding-left: 50px

   which was the old site's way of hitting the same line. It worked there by
   arithmetic: Helix 3's container was a fixed 1140px at every desktop size,
   so centring a 1200px box put its edge 30px further out, and the extra
   35px of padding (50 against the container's 15) brought the text back to
   within 5px of the logo. Two wrong numbers cancelling to a right answer.

   Bootstrap 5 breaks the cancellation, because the container is no longer
   fixed — it steps 960 → 1140 → 1320 as the window grows while the slider
   stays pinned at 1200. Every step widens the gap:

       viewport   1200    1400    1600    1920
       offset     +13px   +95px   +95px   +95px

   which is the text drifting right as the page is zoomed out, and at 1400
   and beyond it is most of an inch adrift of the logo directly above it.

   Rather than pick a new pair of numbers that cancel at today's container
   sizes, this matches the container outright: same max-width at every one of
   Bootstrap's tiers, same 15px padding. The slide text then starts exactly
   where the logo does, at every width, and stays there if the container
   tiers are ever changed in the template settings.

   The wrap has to be released first. SPPB sizes it from
   content_container_width — 85% at md and 95% at sm, restored by
   custom.css §7 for parity — and a percentage-width parent that is narrower
   than the viewport re-centres everything inside it, which would offset the
   box this section is trying to line up. Width now lives on the box below,
   which is the only element that should own it. */

.sp-slider .sp-slider-content-wrap {
	width: 100% !important;
	margin-left: 0 !important;
	margin-right: 0 !important;
}

.sp-slider .sp-slider-content-align-left,
.sp-slider .sp-slider-image-align-left {
	max-width: none;
	margin-left: auto;
	margin-right: auto;
	padding-left: var(--hs-gutter);
	padding-right: var(--hs-gutter);
}

/* Bootstrap 5's container tiers, mirrored. Kept as plain numbers rather than
   a variable because Helix compiles its own Bootstrap and exposes no custom
   property for them — if the container widths are ever customised, these are
   the five values to follow. */
@media (min-width: 576px) {
	.sp-slider .sp-slider-content-align-left,
	.sp-slider .sp-slider-image-align-left {
		max-width: 540px;
	}
}

@media (min-width: 768px) {
	.sp-slider .sp-slider-content-align-left,
	.sp-slider .sp-slider-image-align-left {
		max-width: 720px;
	}
}

@media (min-width: 992px) {
	.sp-slider .sp-slider-content-align-left,
	.sp-slider .sp-slider-image-align-left {
		max-width: 960px;
	}
}

@media (min-width: 1200px) {
	.sp-slider .sp-slider-content-align-left,
	.sp-slider .sp-slider-image-align-left {
		max-width: 1140px;
	}
}

@media (min-width: 1400px) {
	.sp-slider .sp-slider-content-align-left,
	.sp-slider .sp-slider-image-align-left {
		max-width: 1320px;
	}
}


/* 9. …and so does the booking form under it
   -----------------------------------------
   The third element on that margin. custom.css §6 cancels the grid gutter
   on the home page's form column:

       body.itemid-109 [class*="sppb-col-"]:has(.sppb-addon-ajax-contact)
           { padding-left: 0; padding-right: 0 }

   for two stated reasons — SPPB 3 had no column gutter, so removing it puts
   the form back where the old site had it, and the column is narrow enough
   (285px at the 1140 container) that 30px of gutter would clamp the 275px
   fields down to 255px.

   The side effect is that the form starts at the container's edge while
   every other thing on the page starts 15px inside it, so it hangs 15px to
   the LEFT of the logo and the slide text above it.

   Restoring the left gutter only puts it back on the line and keeps most of
   the width: the column gives up 15px rather than 30px, so the fields land
   at 270px instead of 255px — 5px off the old site's 275px, against 15px of
   misalignment. Below 992px the columns stack full-width and the gutter is
   already present on both sides, which is why the form is correct there and
   this rule is only needed from 992px up.

   Same specificity as the custom.css rule it overrides, so it wins purely
   by loading later. */

@media (min-width: 992px) {
	body.itemid-109 [class*="sppb-col-"]:has(.sppb-addon-ajax-contact) {
		padding-left: var(--hs-gutter);
	}
}


/* 10. The page gutter
    ------------------
    §8 and §9 lined the logo, the slide text and the page content up on one
    left margin. That margin is not defined in one place, though — it is the
    same 15px arrived at independently by three different mechanisms:

        .container            Bootstrap's own padding — the header and footer
        [class*="sppb-col-"]  SPPB's grid gutter — all page content
        §8                    the slider box, matched to the other two by hand

    Change one and the three come apart again, which is what this token is
    for: every rule that draws the margin now reads --hs-gutter, so the whole
    line moves together and can only ever move together.

    15px is Bootstrap's default and stays the desktop value. On a phone it is
    tight against the screen edge, so it opens up to 30px.

    30px is measured off the old site rather than picked. Its mobile sub-pages
    put headings and body copy 31px from the left and 35px from the right, and
    the booking form 39px and 27px — consistent across every sub-page checked.
    The asymmetry is not a design: the old template's Custom CSS nudged whole
    blocks sideways to line them up (`.sppb-row-container { left: -20px }`,
    `input { left: -28px }`), and each nudge landed slightly differently. A
    single symmetric 30px lands within a pixel of the old left margin and 5px
    of the right, without reproducing the drift.

    In an ordinary section the row container's +15px padding and the row's
    -15px margins cancel out, so the gutter reaching the content is simply
    the column's and overriding the column alone is enough.

    The slider's section is the exception and needs the block below. It wraps
    its row in .sppb-container-inner, which has NO padding, so the row's
    -15px is left standing and the column's +15px was cancelling it instead —
    the slider reached the screen edge at 15 - 15 = 0 by accident, not by
    intent. Widen the column and that accident stops balancing: the slider
    comes off the left edge and takes its text with it. Zeroing both makes the
    full-bleed deliberate and leaves the text position to §8, which is the
    only thing that should be setting it.

    Two other things correctly opt out, both meant to reach the screen edge:
    the sub-page hero (§3b zeroes its section and column padding with
    !important) and the booking form's own section (§5, whose column supplies
    the gutter instead). */

:root {
	--hs-gutter: 15px;
}

@media (max-width: 767.98px) {
	:root {
		--hs-gutter: 30px;
	}

	.container {
		padding-left: var(--hs-gutter);
		padding-right: var(--hs-gutter);
	}

	/* Page-level columns only — matched through their row's wrapper rather
	   than by the class alone. Addons build their own grids out of the same
	   sppb-col-* classes (the booking form's fields are sppb-form-group
	   sppb-col-sm-12 inside a nested sppb-row), and those inner rows carry
	   the same -15px margins. Widening them too would stack a second gutter
	   on the first and push the fields 5px past the line everything else
	   sits on.

	   !important because SPPB emits a per-section rule of its own at each
	   breakpoint:

	       #section-id-1687611310500 > .sppb-row-container > .sppb-row > div
	           { padding-left: 15px }

	   An id plus two classes outranks anything selector-based that can be
	   written here, and the id is regenerated whenever the page is rebuilt
	   in the builder, so it cannot be matched directly either.

	   The two opt-outs below and in §3 are unaffected: both are !important
	   as well and carry more classes, so they still win on specificity. */
	.sppb-row-container > .sppb-row > [class*="sppb-col-"],
	.sppb-container-inner > .sppb-row > [class*="sppb-col-"] {
		padding-left: var(--hs-gutter) !important;
		padding-right: var(--hs-gutter) !important;
	}
}

/* The slider stays edge to edge at every width; only its text takes the
   gutter, and §8 applies that. */
.page-content > .sppb-section:has(.sppb-addon-sp-slider) .sppb-row {
	margin-left: 0 !important;
	margin-right: 0 !important;
}

.page-content > .sppb-section:has(.sppb-addon-sp-slider) [class*="sppb-col-"] {
	padding-left: 0 !important;
	padding-right: 0 !important;
}