/* Base reset — matches the <style> block in every canvas artboard's
   <helmet> exactly. Everything else stays as inline styles, ported
   directly from the approved canvas, so there's one source of truth. */

body {
  margin: 0;
  background: #F4F3EF;
}
* {
  box-sizing: border-box;
}
input, select, textarea, button {
  font-family: inherit;
}
a {
  color: #B84F00;
}
a:hover {
  color: #8F3D00;
}
input:focus-visible,
select:focus-visible,
textarea:focus-visible,
button:focus-visible,
a:focus-visible {
  outline: 3px solid #3F3870;
  outline-offset: 2px;
}

.entry-shell {
  max-width: 390px;
  width: 100%;
  margin: 0 auto;
  display: flex;
  flex-direction: column;
  min-height: 100vh;
  background: #F4F3EF;
  color: #161B20;
  font-family: 'Saira', system-ui, sans-serif;
}

/* Chrome/Safari: hide native number-input spinners on the quantity steppers
   (they have their own +/- buttons already). */
input[type="number"]::-webkit-outer-spin-button,
input[type="number"]::-webkit-inner-spin-button {
  -webkit-appearance: none;
  margin: 0;
}

@keyframes omm-spin {
  to { transform: rotate(360deg); }
}

/* display and margin-left both used to be inline on the <svg> — moved to
   a real rule because an inline style always beats an external stylesheet
   rule, even one inside a media query, so the desktop overrides below
   couldn't actually switch either property. Same values, same effect, on
   mobile. display:block isn't just tidiness: SVG defaults to
   display:inline, which leaves baseline-alignment gap beneath it that
   wasn't there when it was set inline before. */
.entry-progress-svg {
  display: block;
  margin-left: -10px;
}

/* progress_svg_wide is desktop-only content (see _macros.html); hidden
   here so it never shows up if this stylesheet fails to load or on any
   viewport narrower than the breakpoint below. */
.entry-progress-svg-wide {
  display: none;
}

/* Desktop (Design Spec §4 — "not designed yet", built to the plan given
   there): the shell itself stops capping at mobile width, and three
   classes take over independently instead —
     .entry-band    full-bleed photo elements (hero/band/photo-block),
                     capped at 1600px (Design Spec §6's own hero sizing)
                     so they don't stretch absurdly on very wide screens
     .entry-content everything else (steps, amend pages, the map/progress
                     strip): a centred ~640px column per the plan
     .entry-footer  the footer action bar, as "a centred bar" (the plan's
                     other option, a sticky side panel, needs a two-column
                     layout this app doesn't have)
   Nothing here changes a single inline style value, so mobile — the only
   part actually approved on the design canvas — renders pixel-identical
   to before. */
@media (min-width: 900px) {
  .entry-shell {
    max-width: none;
  }
  /* width: 100% (not just max-width) is load-bearing: these are children
     of .entry-shell's column flexbox, and a flex item with auto cross-axis
     margins (margin: 0 auto here) shrink-to-fits to its in-flow content's
     width instead of stretching — which collapses to 0 for something like
     the hero, whose content is entirely position:absolute. An explicit
     width makes the cross-size definite so max-width + the auto margins
     behave the normal, expected way. */
  .entry-band {
    width: 100%;
    max-width: 1600px;
    margin: 0 auto;
  }
  .entry-content,
  .entry-footer {
    width: 100%;
    /* min(80vw, 1200px), not a bare 80vw: Sam asked for ~80% of the
       viewport, but uncapped that puts a plain text input at ~2400px on
       a very wide display — the cap keeps it reasonable up there while
       still giving the full 80vw on ordinary screens. */
    max-width: min(80vw, 1200px);
    margin: 0 auto;
  }
  /* Scaling the mobile graphic up (a since-reverted earlier attempt)
     grows the icons and the gaps between them by the same factor, so it
     never actually reads as "wide" relative to the rest of the page —
     the icons just get bigger too. Swap to progress_svg_wide instead,
     whose nodes are laid out with real extra space between them, and let
     it fill the column rather than centring a fixed-size element in it. */
  .entry-progress-svg {
    display: none;
  }
  .entry-progress-svg-wide {
    display: block;
    width: 100%;
    height: auto;
  }
  .entry-progress-wrap {
    width: 100%;
  }
  .entry-map-svg {
    width: 100%;
    height: 100%;
  }
}

.entry-progress-panel {
  /* One hill, summit in the middle behind the steps. Separate files for
     mobile and desktop, each drawn at that breakpoint's panel size and
     never stretched: "cover" just crops a little off the sides when the
     panel is narrower, like a map cut to fit. */
  background: url("../img/contours-hill.svg") center / cover no-repeat, #28353F;
}

@media (min-width: 900px) {
  .entry-progress-panel {
    background-image: url("../img/contours-hill-wide.svg");
  }
}