/* ------------------------------------------------------------------ *
 * Lady Bellaïs — corrections layered on top of the Webflow stylesheet.
 *
 * Loaded AFTER css/lady-bellaise.webflow.css so these win, and kept in a
 * separate file so a fresh Webflow export never overwrites them.
 * Each rule states the bug it fixes. Nothing here restyles the design.
 * ------------------------------------------------------------------ */


/* --- Private charters: photos overlapping the footer after submitting ---
 *
 * .image_collection is position:absolute with height:100%, and the height of
 * .section-main-form comes entirely from the form beside it. When Webflow
 * swaps the form for the short "Thank you" block the section collapses to a
 * few hundred pixels, but the four photos keep their natural size — and being
 * out of normal flow, they spill straight over the footer.
 *
 * Hold a floor under the section so it cannot collapse that far, and clip
 * anything that would still overflow. Both classes are used only on
 * private-charters.html, and in the normal state the section is far taller
 * than 100vh, so neither rule changes the page as it looks today.
 */
/* The photo column is display:none below 992px, so the overlap is a
   desktop-only bug — hold the floor only where the photos actually are. */
@media screen and (min-width: 992px) {
  .section-main-form {
    min-height: 100vh;
  }
}

.image_collection {
  overflow: hidden;
}

/* Give the success and error blocks some room once Webflow reveals them.
   Deliberately no `display` here: Webflow keeps both hidden with
   display:none and reveals the right one inline, so setting display in a
   stylesheet would force the "Oops! Something went wrong" message to show
   permanently. */
.section-main-form .w-form-done,
.section-main-form .w-form-fail {
  min-height: 40vh;
}


/* --- Private charters: the submit messages were unreadable -------------
 *
 * Both blocks were styled for a dark background — white text on a 14%-white
 * panel — but the form section is #f8f5f4. Measured contrast was 1.08:1 for
 * "Thank you! Your submission has been received!" and 1.71:1 for the error
 * (WCAG AA wants 4.5:1), so in practice neither message could be read.
 *
 * Recoloured using the site's own tokens: --accent for the confirmation,
 * --primary for the error, both on a tinted panel of the same hue.
 */
.section-main-form .success {
  color: var(--accent);
  background-color: #3e1f1f0f;
}

.section-main-form .success_text {
  color: var(--accent);
}

.section-main-form .error-message {
  color: var(--primary);
  background-color: #8b2d2d0f;
}

.section-main-form .error-message_text {
  color: var(--primary);
}


/* --- Language dropdown: unreadable white-on-white ----------------------
 *
 * Webflow only ever styled `.language-link.w--current` — colour, padding,
 * flex layout, all of it sits behind that one selector. That was fine while
 * the switcher held a single entry (always the current one), but with four
 * languages the other three matched no rule at all: no colour, so they
 * inherited the nav's white text, on the dropdown's white background.
 *
 * This applies the exact styling Webflow already had on `.w--current` to
 * every item, so nothing new is invented — the design just reaches the
 * links that were missing it.
 */
.locales-list .language-link {
  display: flex;
  flex: 1;
  width: 100%;
  gap: .5rem;
  align-items: center;
  justify-content: flex-start;
  padding: 1rem;
  color: var(--black);
  text-decoration: none;
}

/* The Dutch flag's middle band is white and would vanish against the
   white dropdown — a hairline keeps every flag readable. */
.locales-list .language-link img {
  flex: none;
  border-radius: 2px;
  box-shadow: 0 0 0 1px #0000001f;
}

.locales-list .language-link:hover {
  background-color: #0000000a;
}

/* Mark the language you're already on. */
.locales-list .language-link[aria-current="true"] {
  font-weight: 600;
}


/* --- About page: the timeline links were not clickable ----------------
 *
 * `.section-timeline` carries `z-index: -3` with `position: relative`, so
 * the whole section forms a stacking context that paints behind the body's
 * background. Visually it still shows (the body background propagates to
 * the canvas), but hit-testing lands on <body> instead — every link in the
 * timeline, including "snorkel and sightseeing excursion", "sunset sail",
 * "private charter" and "events", was dead.
 *
 * The negative value existed to hide the fixed progress bar
 * (`.timeline_progress-bar`, position:fixed, top 0 to 50vh) where it
 * overflows past the top and bottom of the section. So simply clearing it
 * makes the red bar bleed over the photo above.
 *
 * Instead: put the timeline back at z-index 0 so it is hit-testable, and
 * lift the sections either side above it so they go on hiding the bar's
 * overflow exactly as before. Paint order is unchanged; only hit-testing
 * moves. Verified with elementFromPoint on all four links, plus before /
 * after screenshots of both section boundaries.
 */
.section-timeline {
  z-index: 0;
}

.section-timeline-heading {
  z-index: 1;
}

.section-timeline-cta {
  position: relative;
  z-index: 1;
}

/* The same fixed bar also showed through the footer.
 *
 * `.timeline_progress-bar` is `position: fixed` with `inset: 0 auto 50vh`, so
 * it sits in the top half of the VIEWPORT for as long as it is painted — it
 * does not stop at the end of the timeline. `.section-timeline` is a
 * positioned stacking context (z-index 0, above), and `.footer` was static,
 * so the bar painted over the footer all the way down the page. Confirmed
 * with elementFromPoint: the topmost element at the bar's centre, while the
 * footer filled the viewport, was the bar itself.
 *
 * The sections either side of the timeline already hide the bar's overflow by
 * sitting at z-index 1. The footer needs the same treatment and nothing more.
 * Everything designed to sit above the footer is far higher — `.nav` is 90,
 * `.container_navigation` 1000, `.cms_version` 99 — so this changes nothing
 * else, on this page or any other.
 */
.footer {
  position: relative;
  z-index: 1;
}


/* --- Horizontal overflow between 992px and 1279px ---------------------
 *
 * `.main-container` is a flex item (its parent `.section` is display:flex)
 * with the default `min-width: auto`, which stops a flex item shrinking
 * below its content's intrinsic width. Its content includes the tours
 * carousel, whose slides carry `min-width: 400px`, so the container
 * refused to go below its 80rem (1280px) max-width and hung 128px off
 * each side of a 1024px viewport — the "Explore what we offer" heading
 * was visibly cut off on the left.
 *
 * Below 992px a media query makes the container fluid, and at 1280px+
 * there is room for it, which is why the bug only appears in that band.
 *
 * `min-width: 0` is the standard flexbox remedy: it lets the item shrink
 * to its container. The carousel keeps its own overflow handling, so the
 * slides still scroll horizontally as designed.
 */
.main-container {
  min-width: 0;
}

/* The three contact cards in the footer are 300px each with 4rem gaps
   (1028px total) and only become fluid below 992px, so they overflowed
   in the same band. Let them wrap instead. */
.div-block-17 {
  flex-wrap: wrap;
}


/* --- Hero: the background video had no play/pause control ---------------
 *
 * `js/webflow.js` pauses every <video> on the page when the visitor's
 * system asks for reduced motion:
 *
 *     matchMedia("(prefers-reduced-motion: reduce)").matches
 *       && $("video").each(function () { this.pause() })
 *
 * Honouring that preference is right — a full-bleed moving background is
 * exactly what it is asking us to stop — but Webflow's own control for
 * starting it again (`.w-background-video--control`, which the same script
 * already wires up) is missing from the export, so the pause was a dead
 * end and the hero sat on its first frame. It also meant the site offered
 * no way to stop a 27-second loop, which WCAG 2.2.2 (Level A) requires.
 *
 * The control is now in the four home pages. Webflow ships only its
 * position and `padding: 0` for it — no size, colour or contrast — so the
 * look is defined here. Nothing else in the hero moves.
 */
.hero .w-background-video--control {
  /* .container-grid above it is z-index 1; without this the button is
     painted under the hero copy and cannot be clicked. */
  z-index: 2;
  bottom: 1.5rem;
  right: 1.5rem;
  display: flex;
  align-items: center;
  justify-content: center;
  width: 2.25rem;
  height: 2.25rem;
  border: 1px solid #ffffff59;
  border-radius: 50%;
  background-color: #00000040;
  color: #fff;
  cursor: pointer;
  transition: background-color .2s, border-color .2s;
}

.hero .w-background-video--control:hover {
  border-color: #fff;
  background-color: #00000073;
}

.hero .w-background-video--control:focus-visible {
  outline: 2px solid #fff;
  outline-offset: 2px;
}

/* The two icons are stacked children; only the one matching the current
   state is ever visible (Webflow toggles `hidden` on the other). */
.hero .w-background-video--control > span {
  display: flex;
  align-items: center;
  justify-content: center;
  line-height: 0;
}