/* Shared section-divider component (Phase 5 audit + fix, 17.09.26).
   Full measurement/type audit of all 10 pages: reference/section-
   dividers.json + this repo's README "Section dividers" table.

   Squarespace 7.1 renders these client-side from a JSON config embedded
   in each section's own `data-current-context` attribute (type/height/
   flip/stroke) -- the STATIC raw HTML never contains the real SVG path,
   only a `d="M0,0"` placeholder, so every shape/height/colour value used
   here was read off LIVE via Playwright (data-current-context JSON +
   getComputedStyle + the browser-rendered SVG `d` path/box), not
   inferred from the static markup or guessed.

   Technique: a `.divider` sits inside its OWN section (which must be
   `position: relative; overflow: visible;` -- set per page, see each
   page's own CSS) and is absolutely positioned to straddle or sit just
   above the section's own bottom edge, so it NEVER adds to the
   section's measured height (same convention site.css's original
   `.wave` primitive already established for the site's "wavy" shape --
   this file only adds the 2 further shapes that convention didn't cover
   (pointed, slanted). Wavy dividers keep using site.css's existing
   `.wave`/`.wave-down`/`.wave-up` classes verbatim, unedited here --
   only their per-instance inline stroke-width/colour needed correcting
   at each call site (see each page's own HTML), not this file.

   Colour/stroke-width are set inline on each `<path>` (same convention
   site.css's `.wave` already uses), not a CSS variable here -- only 2
   colours appear across every divider on the whole site (`#000` solid
   black on the large majority, `#F9AD7D` peach on my-school-of-work's
   and bray-new-student-offer's own hero/CTA dividers -- live-measured
   via getComputedStyle, close to but not identical to the existing
   --about-peach token, so written as a literal hex rather than
   repurposing that variable). Every divider on the site renders at a
   real, on-screen 6px stroke width, confirmed via getComputedStyle
   (strokeWidth: "6px") on every live instance measured -- achieved here
   with `vector-effect="non-scaling-stroke"` on each inline `<path>`
   (also present on live's own stroke SVG), which keeps the stroke a
   constant 6 screen pixels regardless of how non-uniformly the
   containing SVG's viewBox is stretched by `preserveAspectRatio="none"`
   -- do not drop that attribute when adding a new divider instance, or
   the stroke will render too thin. */
.divider {
  position: absolute;
  left: 0;
  right: 0;
  line-height: 0;
  z-index: 2;
  pointer-events: none;
}
.divider svg {
  width: 100%;
  height: 100%;
  display: block;
}

/* Pointed (single centred "V" chevron, live divider type "pointed") and
   slanted (single diagonal edge, live divider type "slanted") -- both
   sized in `vw` because that is literally how Squarespace's own divider
   config expresses height (both my-school-of-work instances measured
   "12vw" in their own live `data-current-context` JSON -- confirmed
   against live Playwright boxes at BOTH 375 and 1440, `12vw` resolves
   to ~45px / ~172px at each width, matching the measured line-to-
   section-edge distance almost exactly with no separate breakpoint
   override needed). Unlike `.wave` (which straddles the section
   boundary, roughly half above/half below), these two sit ENTIRELY
   above the section's own bottom edge -- live-measured, the point/
   line's own lowest edge touches the boundary almost exactly (offset
   ~0px), so `bottom: 0` is correct, not a straddling negative offset. */
.divider--pointed-12,
.divider--slanted-12 {
  height: 12vw;
  bottom: 0;
}

/* studywithme's own smaller slanted divider (live divider type
   "slanted", "2vw" config, same live-match logic as above, just
   smaller -- confirmed 28.8px desktop / 7.5px phone against live). */
.divider--slanted-2 {
  height: 2vw;
  bottom: 0;
}

/* Pointed at bray-movement-school's own 6vw config (my-school-of-work's
   -12 variant above is a taller, different config -- kept unedited).
   This page's own SVG `d` path is a mountain (apex up), the mirror of
   my-school-of-work's valley (apex down) -- both are still "a single
   centred V chevron", just opposite orientation, confirmed by a fresh
   live crop per-page (see each page's own HTML comment); this class only
   sets height, the `d` path is written per-instance same as every other
   shape on this site. Un-anchored (no `bottom: 0`) -- bray-movement-
   school keeps its own pre-existing straddle offset (top:-20px/
   bottom:-20px, that page's own CSS) rather than this shape owning its
   position outright, so a future full-padding rebuild of that page can
   switch it to `bottom: 0` without touching this file. */
.divider--pointed-6 {
  height: 6vw;
}

/* Scalloped (live divider type "scalloped", bray-movement-school only,
   6vw): section-dividers.json's own shape_note flagged this as "not
   pixel-verified" off a screenshot -- re-confirmed against a FRESH live
   crop of the actual boundary (nutshell/layers, bray-movement-school,
   17.09.26): NOT a repeating scallop despite the name, a single gentle
   ASYMMETRIC downward curve (higher at the left edge, dipping through
   the middle, levelling off toward the right) -- Squarespace generates
   the real `d` path client-side from this type name (no literal path in
   the raw HTML or the live `data-current-context` JSON, same as every
   other shape on this site -- see this file's own top-of-file note), so
   the exact curve below is a visual match to that crop, not a vector-
   exact reproduction (same convention already accepted for this site's
   pointed/slanted paths). Height-only class, same un-anchored convention
   as .divider--pointed-6 above. */
.divider--scalloped-6 {
  height: 6vw;
}

/* Rounded ("smile" -- single shallow upward arc spanning the full
   section width, live divider type "rounded": bray-new-student-
   application-form (x2), bray-new-student-offer (x6, not built this
   phase)). Genuinely different mechanics from every shape above: a live
   Playwright probe of bray-new-student-application-form (17.09.26)
   found this section's own measured `padding-bottom` is EXACTLY this
   divider's own config height (6vw = 86.4px desktop / 22.5px phone,
   reference/bray-new-student-application-form/measurements.json) on
   BOTH the divider-hosting sections on that page -- i.e. Squarespace
   reserves the divider's own space AS that section's real padding-
   bottom, then draws the curve inside it, rather than a decorative
   overlay straddling a section that would otherwise have little/no
   padding there (the `wavy`/`pointed`/`slanted` convention above). Built
   here as `position:absolute; bottom:0; height:6vw` (still adds NO
   height beyond what the section's own padding-bottom already reserves
   for it -- same end result as every other shape, just because that
   padding genuinely exists on this page, not because the divider forces
   it to). `.divider--rounded-down` = filled BELOW the curve (use at a
   section's own bottom edge when travelling DOWN the page into a
   different-coloured section, e.g. this page's plain hero into its own
   peach form section); `.divider--rounded-up` = filled ABOVE the curve
   (mirror use, when THIS section's own colour is the one fading out at
   its bottom edge, e.g. the peach form section into the page's default
   footer background). Fill colour is set inline per instance (this
   file's existing convention, e.g. `.wave`'s stroke colour) since it has
   to match whichever of the two neighbouring section backgrounds bleeds
   into the divider's own box; `isFlipX` in the live config is a no-op
   here (a single symmetric hump reads identically mirrored, same as
   `pointed`'s own confirmed no-op, see section-dividers.json). */
.divider--rounded-down,
.divider--rounded-up {
  height: 6vw;
  bottom: 0;
}