/* =======================================================================
 * /events/ (post 3499). REVIEW-12, 2026-09-10.
 * Spec: loop/work/REVIEW-12/vesper.md sections 1.2, 2 and 3.1.
 *
 * ONLY THIS PAGE'S OWN TYPE ROLES AND LAYOUT BELONG IN THIS FILE, NOTHING
 * ELSE. The page is an un-rebuilt 2022 Divi layout carrying the global
 * systems only, so the button levels live in css/myth-motion.css (the
 * button system is declared once) and the gift strip's own surface and
 * seam modifiers live in css/myth-bands.css (the component owns its own
 * modifiers, MANUAL-43-FINAL's `--events-dark` included, even though only
 * this page ever prints it). What is left is this page's own Divi
 * headings, its hero's two body paragraphs and layout, the H1's line
 * reserve, and the "What we host" section's own closing space, none of
 * which any other route renders. (MANUAL-43, 2026-09-12, added sections 4
 * and 5; MANUAL-43-FINAL, same day, added sections 6 and 7; MANUAL-45,
 * same day, added section 8 and corrected section 7. The "three rules"
 * this note originally described are now eight, all still scoped to this
 * page alone.)
 *
 * NO COLOUR HERE THAT THE PALETTE DOES NOT ALREADY HOLD: Maroon #6E0C01
 * and Ink #1C1310, both from docs/BRAND-DIRECTION.md section 1. No
 * page-scoped button or surface rule. `!important` is used in exactly two
 * places, sections 5 and 8 (MANUAL-45), both an explicit, user-authorised
 * exception to this file's own general rule against it: Divi wrote an
 * inline `style="font-weight: ..."` (or a `<b>`/`<strong>` tag) directly
 * onto the visible text node inside eight paragraphs on this page, which
 * no external rule at any specificity can out-rank without `!important`,
 * and editing that markup out of post_content was ruled out of scope.
 * Every other rule in this file still needs no `!important`.
 *
 * Specificity: every TYPE rule (sections 2-5) is (0,2,1), one class on the
 * section plus the Divi text module's own class plus the element. Divi's
 * customizer sets its heading sizes at the element level
 * (h3{font-size:35px} and the responsive 30px and 25px below it) and the
 * family in one h1,h2,h3,h4,h5,h6 rule, so (0,2,1) clears all of them
 * without needing a weight the cascade has to fight. The four H3 modules
 * and the new H2 module carry NO type attributes in the layout, so Divi
 * generates no per-module rule for any of them and nothing here is
 * overriding an !important (the two exceptions above are on `p`
 * descendants, not headings). Sections 6 and 7 (MANUAL-43-FINAL) are
 * LAYOUT, not type: (0,2,0) and (0,3,0) for the two flex rules; section
 * 7's own padding rule is `.et_pb_section.myth-events-what`, (0,2,0), not
 * (0,1,0) as first written (MANUAL-45 correction: a bare `.myth-events-
 * what` loses to Divi's own core `.et_pb_section{padding:2%/4% 0}` at
 * 981px and up, equal specificity, later in source order). Section 8 is
 * TYPE but targets `p`, not a heading Divi has its own rule for, so
 * `!important` substitutes for specificity there instead.
 * ===================================================================== */

/* -----------------------------------------------------------------------
 * 1. The H1's two-line reserve (Vesper 1.2).
 *
 * "Host your event in Gillingham or Maidstone" is 42 characters and sets
 * in two lines at 26 / 45 / 60px, exactly as the 35 character string it
 * replaces did, so the hero's rhythm does not move and the string change
 * costs no layout shift. The reserve is here so that the paragraph below
 * cannot ride up while the webfont swaps in, and so a future shortening of
 * the string cannot collapse the hero to one line. Same mechanic and same
 * value as .myth-gill-hero__h1 in css/myth-gillingham.css, which is the
 * site's existing answer to this problem.
 *
 * The size, colour, alignment and the H1's text shadow are NOT touched:
 * the shadow is the only thing separating White type from the unscrimmed
 * photograph behind it, and a scrim is a hero rebuild, not this task.
 * --------------------------------------------------------------------- */
#event-form h1 {
  min-height: calc(2 * 1.05em);
}

/* -----------------------------------------------------------------------
 * 2. "What we host" (Beacon 6.2 owns the string and the position, Vesper 2
 *    owns how it reads).
 *
 * The band title that closes the route's (1, 3) heading skip. Every value
 * except the margin is the number .myth-events-faq__heading already
 * computes on this same page: /events/ ends R12 with two band headings and
 * they must be one type role, not two. font-weight 500 is what that
 * heading computes; Julius Sans One ships one weight, so the engine
 * discards the synthetic step and the two computed style objects match.
 *
 * Maroon on this band's parchment ground measures 8.69:1 at 390, 9.94:1 at
 * 768 and 9.54:1 at 1440, sampled from the darkest rendered pixel of the
 * surface, against a 4.5:1 floor. Gold is forbidden on this ground at
 * 1.92:1 to 2.19:1 (palette.contrastLaws).
 *
 * The space ABOVE the heading is the row's own padding plus the section's
 * (50 / 66 / 92.8px, within 2.8px of the law's 48 / 64 / 96 band scale at
 * every width); the space below is 35 / 42 / 44.8px. More above than below
 * is what makes it a band title over the four cards rather than a trailing
 * line of the hero. No eyebrow above it and no divider under it.
 * --------------------------------------------------------------------- */
.myth-events-what .et_pb_text h2 {
  font-family: "Julius Sans One", sans-serif;
  font-weight: 500;
  font-size: 32px;
  line-height: 1.1;
  letter-spacing: normal;
  text-transform: none;
  color: #6E0C01;
  text-align: left;
  /* Divi's global 10px of heading padding is a theme default, not a
     decision. The gap is written as a margin so it collapses with the
     first card's own top margin instead of stacking with it. */
  padding-bottom: 0;
  margin: 0 0 8px;
}

@media (min-width: 768px) {
  .myth-events-what .et_pb_text h2 {
    font-size: 36.3px;
    margin-bottom: 12px;
  }
}

@media (min-width: 1024px) {
  .myth-events-what .et_pb_text h2 {
    font-size: 44px;
    margin-bottom: 16px;
  }
}

/* -----------------------------------------------------------------------
 * 3. The four event-type card headings (Vesper 3.1).
 *
 * The strings are the client's and are untouched. Four things change and
 * each has a reason:
 *
 * 1. #280C00 to Ink #1C1310. #280C00 is a seventh hex on a site with six
 *    documented ones and it is within one luminance point of Ink on this
 *    ground (14.32:1 against 14.23:1), so nobody sees the change, which is
 *    exactly why there is no case for keeping a stray colour. Ink and not
 *    Maroon: the band heading above now takes the accent, and four card
 *    titles in the same Maroon would put five equal claims on one surface.
 * 2. The 20 percent black offset text shadow comes off. No heading on the
 *    site carries one except the H1, where it stands in for a scrim. These
 *    four sit on flat parchment with nothing to be separated from.
 * 3. line-height 1.0 to 1.15. At 390 the first heading sets on two lines
 *    and 1.0 puts the ascenders into the descenders. Costs 9px at 390 and
 *    nothing at 768 or 1440, where all four set on one line.
 * 4. Divi's padding-bottom: 10px becomes an explicit margin, the same
 *    0, 2, 0 margin rule R09 wrote for the Gillingham grid headings.
 *
 * UPDATE, MANUAL-43 (2026-09-12, the user's own instruction, superseding
 * the paragraph this replaces): the family moves from Cabin to Julius Sans
 * One, weight 500, the same face and weight every other Julius Sans One
 * heading on the site computes, closing the split the previous paragraph
 * called temporary. Font-family and weight are the ONLY two properties
 * this update touches; size, colour, line-height, shadow and margin above
 * are the same values the previous paragraph already justified and are
 * left exactly as they were. All four headings were confirmed still
 * setting on their existing one or two lines at 30px/35px after the family
 * change, so no size compromise was needed here (unlike the H1 below).
 *
 * Ink on the darkest sampled pixel of this ground: 12.96:1 at 390,
 * 14.83:1 at 768, 14.23:1 at 1440. The body paragraphs under them are
 * #333333 and are not touched.
 * --------------------------------------------------------------------- */
.myth-events-what .et_pb_text h3 {
  font-family: "Julius Sans One", sans-serif;
  font-weight: 500;
  font-size: 30px;
  line-height: 1.15;
  color: #1C1310;
  text-align: left;
  text-shadow: none;
  padding-bottom: 0;
  margin: 0 0 16px;
}

@media (min-width: 1024px) {
  .myth-events-what .et_pb_text h3 {
    font-size: 35px;
    margin-bottom: 20px;
  }
}

/* -----------------------------------------------------------------------
 * 4. The hero H1 (MANUAL-43, 2026-09-12, the user's own instruction,
 *    superseding section 1's original "the H1 cannot join them" decision).
 *
 * R12/Vesper 1.3 kept this H1 on Cabin because "Host your event in
 * Gillingham or Maidstone" in Julius Sans One wraps to three lines at 390
 * at any size from 24px up, and called the Cabin exception temporary. The
 * user's 2026-09-12 instruction overrides that: move the H1 onto Julius
 * Sans One like every other heading on the site, and shrink its mobile
 * size only as far as needed to hold two lines, accepting it reads smaller
 * on phones than it did on Cabin. Section 1's min-height reserve
 * (calc(2 * 1.05em)) is untouched; size, colour, alignment and the text
 * shadow it names are also untouched here except for the font-size values
 * below, which that section's own comment already flagged as open.
 *
 * Line counts were measured live in a real browser with getClientRects()
 * (grouping the rendered text's own rects by rounded top, not
 * height/line-height division, which produced non-monotonic false results
 * at this exact font) at the hero column's TRUE rendered width at each
 * breakpoint, not an assumed one:
 *   390:  312.00px column.  22px is the largest size that holds 2 lines
 *         (23px wraps to 3).
 *   768:  614.39px column.  36-44px all hold 2 lines.
 *   1024: 473.48px column, genuinely narrower than both 768 and 1440 (a
 *         pre-existing Divi responsive-column behaviour on this
 *         un-rebuilt layout, not something this task touches or caused).
 *         34px is the largest size that holds 2 lines here (35px wraps to
 *         3), a real, lower ceiling than the task brief's own assumption
 *         of "up to 64px", which this file corrects rather than repeats.
 *   1440: 665.84px column. 32-36px all hold 2 lines.
 *
 * Shipped values step 22 / 28 / 32 / 36px, a deliberate rising scale (not
 * the bare minimum at every breakpoint) that clears every ceiling above
 * with margin: 6px under 1024's binding 34px cap, 8px under 1440's 44px
 * headroom. font-weight 500 matches every other Julius Sans One heading
 * on the site, same as sections 2 and 3 above.
 * --------------------------------------------------------------------- */
.myth-events-hero .et_pb_text h1 {
  font-family: "Julius Sans One", sans-serif;
  font-weight: 500;
  font-size: 22px;
}

@media (min-width: 768px) {
  .myth-events-hero .et_pb_text h1 {
    font-size: 28px;
  }
}

@media (min-width: 1024px) {
  .myth-events-hero .et_pb_text h1 {
    font-size: 32px;
  }
}

@media (min-width: 1440px) {
  .myth-events-hero .et_pb_text h1 {
    font-size: 36px;
  }
}

/* -----------------------------------------------------------------------
 * 5. The hero's two body paragraphs (MANUAL-43, 2026-09-12).
 *
 * The uppercase "ORGANISING MADE EASY..." line and the form column's
 * "Fill out the form below..." intro both still compute Divi's default
 * body font. This brings them onto the same Karma serif, 1.6 line-height
 * every .myth-band p on the site reads at (css/myth-bands.css), the same
 * two properties and nothing else: no colour change, no letter-spacing,
 * no eyebrow treatment. The eyebrow atom (gold colour, wide tracking) is
 * retired sitewide and is deliberately not reintroduced here; the first
 * line's own upper-case casing is text-transform already set on the
 * element by the page itself, not this rule, and is left as-is.
 *
 * UPDATE, MANUAL-45 (2026-09-12, the user's own instruction): font-weight
 * added, and forced with !important, an exception to this file's own
 * header rule against it, granted explicitly for this one fix. Confirmed
 * live before writing anything: the visible text in all three hero lines
 * sits inside an inline-styled or bold-tag child the Divi module wrote
 * into post_content (`<span style="font-weight: 400;">` on the eyebrow
 * line, `<b>` on the sub-heading, `<strong>` on the form intro), each
 * computing 400, 900 and 700 respectively, none of them the 500 every
 * other body-text block on this page and site reads at
 * (`.myth-band-faq__answer`, `.myth-gift-strip__text`, both confirmed
 * live at 500 moments before this fix and left untouched). Editing or
 * stripping those inline styles and tags would be a post_content markup
 * edit, out of scope for this task, so the override happens here instead:
 * the parent `<p>` rule below AND a second rule targeting exactly the
 * three element types Divi used (span, b, strong) as its children, both
 * at !important, since an inline `style` attribute otherwise beats any
 * external stylesheet rule regardless of selector specificity. Confirmed
 * live after: the innermost node holding the visible text in all three
 * lines computes 500, not just the parent `<p>`. --------------------- */
.myth-events-hero .et_pb_text p {
  font-family: Karma, serif;
  line-height: 1.6;
  font-weight: 500 !important;
}

.myth-events-hero .et_pb_text p span,
.myth-events-hero .et_pb_text p b,
.myth-events-hero .et_pb_text p strong {
  font-weight: 500 !important;
}

/* -----------------------------------------------------------------------
 * 6. Vertical centring of the hero's text column (MANUAL-43-FINAL, user,
 *    2026-09-12, user-reported and confirmed live: at 1024px the section
 *    measured 733.39px tall while the H1 sat only 60-135px from its top
 *    edge, roughly 400-600px of unused space below it before the section
 *    ended).
 *
 * Confirmed before writing anything (the task's own instruction): the row
 * is a classic Divi float layout (`.et_pb_row{display:block}`,
 * `.et_pb_column{float:left}`), not already flex or grid, and BELOW 1024px
 * Divi's own responsive CSS stacks the two columns (no float, full width
 * each), where the text column's box already fits its own content exactly
 * (measured: 323.5px box height at 390, 196.56px at 768, both equal to the
 * two text modules' own combined height, no slack to centre into). The
 * defect is float-only and desktop-only: at 1024px+ the row is two
 * side-by-side floated columns of DIFFERENT natural heights (the text
 * column short, the form column tall), and CSS floats never equalise
 * sibling height, so the text column's own box was always exactly as
 * tall as its own two paragraphs, with the leftover row height simply
 * appearing as background below and beside it.
 *
 * Fixed at 1024px and up only, so the confirmed-correct stacked layout
 * below it is never touched: the row becomes a flex container
 * (`align-items: stretch`, flexbox's own default, is what actually
 * equalises the two columns' height here, not a value this rule states
 * explicitly), which stretches the text column to match the form
 * column's height, exactly the height-matching a float row cannot do;
 * the text column then centres its own two children within that new,
 * taller box. Divi's own explicit per-column width rules are untouched
 * and still govern width under flex exactly as they did under float
 * (flex-basis defaults to the element's own width when none is set),
 * confirmed live: both columns' widths and the form column's own height
 * and position are byte-for-byte the same after this rule as before it,
 * at 1024 and 1440.
 *
 * Measured after the fix, space above the two-paragraph group to the
 * column's own top edge against space below it to the column's own
 * bottom edge: 189.53px and 189.53px at 1024px, 199.61px and 199.63px at
 * 1440px (the 0.02px difference is float-pixel rounding, not an error).
 * True centring, not eyeballed. --------------------------------------- */
@media (min-width: 1024px) {
  .myth-events-hero .et_pb_row {
    display: flex;
  }

  .myth-events-hero .et_pb_column:first-child {
    display: flex;
    flex-direction: column;
    justify-content: center;
  }
}

/* -----------------------------------------------------------------------
 * 7. Space after "What we host", before the gift strip (MANUAL-43-FINAL,
 *    user, 2026-09-12, user-reported via screenshot: the closing image and
 *    "Host your event" button sat hard against the gift strip below).
 *
 * Measured live before this fix, last button's own bottom edge to the
 * gift strip's own rendered top edge: 80px at 390, 71px at 768, 0px at
 * 1024, 4.64px at 1440. The defect is desktop-specific (390/768 already
 * had enough natural space from the row's own image/text stacking); 1024
 * and 1440 measured at or near zero, exactly the "close against the
 * divider line" the user's screenshot showed.
 *
 * Fixed with `padding-bottom` on `.myth-events-what` itself (the section's
 * own scoped class, not a new one), at this site's own 48/64/96 band
 * scale (css/myth-bands.css's `.myth-band`, the same rhythm section 2's
 * own heading spacing above already measures within 2.8px of), not an
 * arbitrary number. `.myth-gift-strip` sits partly OVER this section on
 * purpose (its own documented upward seam/shadow overlap, css/myth-bands.css),
 * so the padding does not land pixel-for-pixel below.
 *
 * CORRECTION, MANUAL-45 (2026-09-12, user-reported, user's own live
 * verification caught what this file's own prior record had wrongly
 * called fixed). The single-class selector below was always losing at
 * 981px and up: Divi's own core CSS carries `.et_pb_section{padding:4% 0}`
 * and, from a second core stylesheet, `.et_pb_section{padding:2% 0}` at
 * the same `(min-width: 981px)` breakpoint, equal specificity to a bare
 * `.myth-events-what`, and later in the page's own stylesheet order, so
 * it silently won at 1024 and 1440 the whole time; the "measured after
 * the fix: 60.47px, 71.84px" this comment used to claim came from testing
 * the rule via `page.addStyleTag()`, which appends to the END of the
 * cascade and artificially wins regardless of real specificity, not from
 * the actually deployed file. The real, live, undoctored gap at 1024 and
 * 1440 was still 0px and 4.64px until this correction, unchanged from
 * before that earlier task ever ran. Fixed properly this time by raising
 * specificity instead of relying on source order: `.et_pb_section` added
 * to the selector, (0,2,0) against Divi's own (0,1,0), which wins
 * regardless of enqueue order and needs no `!important`. Measured after,
 * this time via the real deployed stylesheet with a hard cache clear, no
 * injected style: 78px at 390, 85px at 768, 60.47px at 1024, 71.84px at
 * 1440, matching the numbers this comment always intended, now actually
 * true. For comparison, the gap above this section (hero's own lowest
 * content to this section's own heading, untouched by this task) measures
 * 152 to 243px across the same four widths; the two are not pixel-equal,
 * since the "above" figure is an incidental sum of three older,
 * independent Divi padding settings (the hero section's own bottom
 * padding, this section's own Divi-default top padding, and the row's own
 * top padding) rather than one deliberately chosen number, but this fix
 * brings "below" from zero to a comfortably positive, clearly visible gap
 * on the site's own established band scale, which is what the user's own
 * report asked for. Scoped to `.myth-events-what` only: the gift strip's
 * own top spacing, shared with the homepage and all twelve room pages, is
 * untouched, confirmed live on the homepage before and after this rule
 * was added. --------------------------------------------------------- */
.et_pb_section.myth-events-what {
  padding-bottom: 48px;
}

@media (min-width: 768px) {
  .et_pb_section.myth-events-what {
    padding-bottom: 64px;
  }
}

@media (min-width: 1024px) {
  .et_pb_section.myth-events-what {
    padding-bottom: 96px;
  }
}

/* -----------------------------------------------------------------------
 * 8. "What we host" body copy font-weight (MANUAL-45, 2026-09-12, the
 *    "minute discrepancy in font weight" the user flagged from
 *    screenshots).
 *
 * Same root cause and same fix as section 5's own update above, on the
 * four card paragraphs plus their shared intro line (five `<p>` tags in
 * total): each computed `font-weight: 500` on the parent, correctly, but
 * every one of their visible text nodes is wrapped in Divi's own
 * `<span style="font-weight: 400;">`, an inline style that always beats
 * an external rule regardless of selector specificity, so the rendered
 * text read at 400 sitewide against the 500
 * `.myth-band-faq__answer`/`.myth-gift-strip__text` read at on this same
 * page. Confirmed live before writing anything: identical across all
 * five paragraphs, not a per-card difference. Editing the inline style
 * out of post_content is a markup edit, out of scope, so `!important`
 * forces it here instead, the same authorised exception section 5 uses.
 * Confirmed live after: all five paragraphs' inner span computes 500 at
 * every width. --------------------------------------------------------- */
.myth-events-what .et_pb_text p {
  font-weight: 500 !important;
}

.myth-events-what .et_pb_text p span,
.myth-events-what .et_pb_text p b,
.myth-events-what .et_pb_text p strong {
  font-weight: 500 !important;
}