/* event/event_pro.css */
body {
  background: var(--custom-background-color);
  background-attachment: fixed;
  background-size: cover;
  color: var(--custom-text-color);
  font-family: var(--theme-font-body);
  line-height: 1.5;
}
.pro-shell { display: flex; flex-direction: column; min-height: 100dvh; position: relative; }
.pro-main { display: flex; flex: 1; justify-content: center; }
/* 1020px where the purchase form has a second column, 640 everywhere else,
   and the 640 cap is LIFTED rather than forgotten (Vicky, 2026-08-22). 640 was
   never about the page looking right at 640 — it was the Customize studio's
   canvas, about 856px on a 1440 laptop, which meant a wider layout collapsed
   for most organizers and they never saw the thing they were customizing. That is being answered separately with an explicit
   studio zoom, so the constraint went and the preference stayed: 640 is still
   what every other buyer page measures, and this page only goes wider because
   its purchase form has a second column to put somewhere (event_columns.css).
   The studio's own answer landed the same morning (#1545): its desktop canvas
   lays the page out at a fixed 1280px and draws it at a magnification the
   organizer picks, so this width is one an organizer can actually see.

   CLIP, not hidden. Both do the job the card wants — keeping the banner inside
   the rounded corner — but `overflow: hidden` makes this a scroll container,
   and the sticky rail inside then has nothing to stick to and silently sits
   still. `clip` does not, so it is the only one of the two that can be here.
   The second copy of this rule is emitted inline by event.html's BandGradient
   block; it says clip for the same reason, and a rail that freezes only for
   accounts with a gradient band is exactly the bug nobody would find. */
.pro-card {
  background: var(--custom-text-background-color);
  color: var(--custom-text-color);
  container-type: inline-size;
  max-width: 640px;
  overflow: clip;
  width: 100%;
}
/* The wide card is the SECOND COLUMN's, and it goes where the column goes
   (Vicky, 2026-08-23). data-priced is one answer from eventFlowCore, read here
   and again inside the card by event_columns.css, so the width and the grid
   can never disagree — a 1020px card with one column in it is the worst of the
   three shapes, a ticket list stretched to 956px to make room for a rail that
   was never coming. An event where nothing has a price keeps 640, which is
   both what it had before the rail existed and what every other buyer screen
   still measures. */
.pro-card[data-priced] { max-width: 1020px; }
/* The banner renders the shape the organizer STORED — the crop dialog's
   rectangle is the rendition (assets.go), and a frame that re-crops it at
   render time silently zooms into any deliberately wider-than-3:1 crop,
   contradicting the stored-shape decision the slot is built on (the message
   email shows the same picture and cannot crop when it renders).
   What the fixed 3:1 frame this replaces was really protecting is the FOLD,
   and that survives as a depth cap only: never deeper than 3:1 of the card
   (100cqi/3 — .pro-card is the inline-size container, which is also why the
   cap follows the 640/1020 width split above by itself), so a pasted-URL
   square still can't bury the tickets. The fold numbers were measured when
   the frame was 16/9 on the then-510px card at 1280x800: 287px of banner
   pushed the event name 367px down an 800px screen; at 3:1 the name, date,
   venue, description and first ticket rows are all above the fold. A
   wide-and-thin crop renders exactly as chosen — thinner than the cap, so
   the cap is inert and object-fit never crops. */
.pro-banner { max-height: calc(100cqi / 3); object-fit: cover; }
.pro-content { padding: 1rem; }
.pro-header { align-items: flex-start; display: flex; gap: 1rem; }
.pro-header .event-logo { border-radius: 8px; max-height: 80px; max-width: 80px; }
.pro-card h1 {
  color: var(--custom-heading-color);
  font-family: var(--theme-font-heading);
  font-size: 2.25rem;
  font-weight: 300;
  line-height: 1.15;
  margin: 0;
}
.pro-content h2,.schedule-group h3,.step-heading { font-family: var(--theme-font-heading); }
.pro-content h2 { color: var(--custom-heading-color); font-size: 1.125rem; }
.pro-meta { color: var(--custom-text-color-muted); margin: 1rem 0 2rem; }
.pro-meta .meta-icon { margin-right: .15rem; vertical-align: -.125em; width: 1.125em; }
/* 72ch is not a new measure, it is the one this page already had: a 640px card
   less its 2rem padding is 576px, which at the body size is about 72
   characters. Stating it stops the card's new 1020px widening the LINE as well
   as the page — at full width the organizer's description would otherwise run
   to about 119 characters, roughly twice a comfortable read. In ch rather than
   px so it follows the account's own body font and the airy/compact scale,
   and it never engages on a phone, where the column is nowhere near it. */
.pro-description { margin-bottom: 2rem; max-width: 72ch; }
/* Every link on the card the organizer did not draw as a button: the ones
   linkify made out of their own description text, and the directions links,
   wherever venue.css put that block — beside the map, or up in .pro-meta when
   the event has no map. Nothing coloured either before, so both arrived as UA
   blue in the middle of the organizer's own palette.
   <event-description> and <venue-links> rather than the wrapper classes,
   because those two are the names docs/themes.md publishes as the CSS
   contract — a theme styles the same elements this does. */
event-description a,
venue-links a { color: var(--custom-link-color); }
/* ticket-list / ticket-row — the Pro skin of the purchase construct's public
   contract (docs/themes.md §The CSS contract). The list keeps its real <ul>
   inside: the wrapper is there to give it context, not to replace it. */
ticket-list {
  display: block;

  /* An author `display:` beats the UA's [hidden] rule, so a list the step
     wizard hides stayed on the page: on a timed event the ticket rows sat
     under the date cards the whole way through (found 2026-08-10). The
     attribute is how checkout-steps.js reveals the list, so the rule that
     gives it a box has to say what hidden means. */
  &[hidden] { display: none; }

  > ul { list-style: none; margin: 0; padding: 0; }

  > ul > li {
    border-bottom: 1px solid var(--divider-color);
    padding: 1rem 0;

    &:last-child { border-bottom: 0; }
    /* An attached add-on hangs off the ticket above it: no rule between the
       two, a spur down the left instead. */
    &[data-addon-for] {
      border-left: 2px solid var(--divider-color);
      margin-left: .2rem;
      padding: .6rem 0 .6rem 1rem;
    }
    &:has(+ li[data-addon-for]) { border-bottom: 0; }

    /* A RULE SEPARATES TWO ROWS, so it is drawn by what is on the screen and
       not by what is in the markup. Under JavaScript this list carries rows a
       buyer is not being shown: an add-on waits for its ticket to be chosen
       (addon_rows.css), and a choice waits for the wizard to walk to it
       (asked_elsewhere.css). Both are display:none, and a border on a row that
       is not displayed draws nothing while a border on the row above it closes
       a group that is no longer there.

       So under .js the rule is restated from scratch: every row starts with no
       border, and a row takes one only when a row a buyer can actually SEE
       follows it. `shown` below is that set — a plain ticket, or an add-on
       whose ticket is chosen. With no JavaScript every row is shown, none of
       this applies, and the three declarations above stand as they always did.

       Vicky, 2026-09-05: "Now there's HRs between some elements and not
       others though." */
    .js & { border-bottom: 0; }
    .js &:has(~ li:is(:not([data-addon-for]):not([data-asked-elsewhere]), [data-addon-for].addon-on)) {
      border-bottom: 1px solid var(--divider-color);
    }
    .js &:has(+ li[data-addon-for].addon-on) { border-bottom: 0; }
  }
}
ticket-row {
  justify-content: space-between;

  & label { font-size: 1rem; font-weight: 500; }
  & .grow > span:first-child { font-size: 1rem; font-weight: 500; }
  & .muted, & .grow .muted { font-size: .875rem; }
  & .price { color: var(--custom-text-color-muted); }
  /* Every input in a row is a box the buyer types in — except a donation
     row's tickbox, which the skin must leave as a tickbox. */
  & input:not([type="checkbox"]) {
    background: transparent;
    border: 1px solid var(--custom-control-border);
    border-radius: 4px;
    box-shadow: var(--custom-control-shadow);
    color: var(--custom-text-color);
    padding: .45rem;
  }
  & .qty button.step {
    background: color-mix(in srgb, var(--custom-text-color) 6%, var(--custom-text-background-color));
    border: 0;
    color: var(--custom-text-color);
  }
  & .qty button.step:hover:not(:disabled) {
    background: var(--custom-text-color);
    color: var(--custom-text-background-color);
  }
}
.pro-card .checkout-fields input,.pro-card .checkout-fields select,.pro-card .checkout-fields textarea {
  background: transparent;
  border: 1px solid var(--custom-control-border);
  border-radius: 4px;
  box-shadow: var(--custom-control-shadow);
  color: var(--custom-text-color);
  padding: .6rem;
}
/* The widget's sheet is the second document this skin dresses, and it has no
   .pro-card to sit inside — the sheet IS the card (embed_sheet.html). Named
   here rather than restated in the sheet's own stylesheet, because the
   account's button colour is this skin's answer and there must be only one
   of it: the CTA in the box and the CTA on the page are the same button. */
.pro-card .checkout-button,
body[data-embed-sheet] .checkout-button {
  background: var(--custom-button-background-color);
  color: var(--custom-button-text-color);
  width: 100%;
}
/* No rule above the button (Vicky, 2026-08-21: "I don't think we need the
   border above the continue button on the event page"). The ticket list
   already draws a hairline under its last row, so the band's own line landed
   a padding's width below it — two rules, close together, separating nothing
   from nothing. The space is what sets the button apart from the list, which
   is the same way every other primary action on the journey is set apart. */
.pro-form-footer {
  margin: 1rem -1rem -1rem;
  padding: 1rem;
}
/* That bottom margin is the card's own padding pulled back, so the button
   band finishes flush with the bottom edge — which is only ever right while
   the tickets are the last thing on the page. Arranged above the location or
   the description (page_arrangement.go), the same pull dragged whatever came
   next up over the button and left it touching (Vicky, 2026-08-18). Where
   something follows, the band keeps its full-width rule and simply ends. */
.pro-content > [data-block="tickets"]:not(:last-child) .pro-form-footer { margin-bottom: 0; }
/* The credit is the only thing on this page outside the card, so it is the
   only thing whose colour is not the card's business. --custom-page-ink is
   black or white against the PAGE background (eventDesign.PageInk); the link
   inherits it rather than taking the organizer's link colour, which is chosen
   to read on the card and can land anywhere against a page background they
   set separately. */
.pro-footer { color: var(--custom-page-ink); padding: 1rem; text-align: center; }
.pro-footer a { color: inherit; }
@media (min-width:600px) {
  .pro-main { flex: none; padding: 3rem 3rem 1.5rem; }
  .pro-card {
    border-radius: var(--custom-card-border-radius);
    box-shadow: var(--custom-card-shadow);
  }
  .pro-content { padding: 2rem; }
  .pro-form-footer { margin: 1rem -2rem -2rem; padding: 1rem 2rem; }
}
/* The step wizard's palette (event_steps.css draws it). The account's own
   customisation tokens, so a timed event's Date › Time › Tickets steps theme
   with the rest of the page rather than beside it. */
.checkout-steps {
  --step-accent: var(--custom-button-background-color);
  --step-accent-ink: var(--custom-button-text-color);
  --step-heading-ink: var(--custom-heading-color);
  --step-ink: var(--custom-text-color);
  --step-ink-muted: var(--custom-text-color-muted);
  --step-line: var(--custom-control-border);
  --step-link: var(--custom-link-color);
  --step-surface: var(--custom-text-background-color);
}

/* The summary line under the event's name: the same shape every other buyer
   surface uses, "date · venue" on one supporting line (2026-08-21). It was
   two icon-led rows, which is the only place on the journey where those two
   facts were stacked. */
.pro-meta .pro-summary { color: var(--custom-text-color-muted); font-size: .95rem; margin: .35rem 0 0; }