instead does the same job for the same reason and
leaves the card free to let a panel out. */
event-venue {
border: 1px solid var(--divider-color);
border-radius: 10px;
display: block;
margin: 1rem 0 1.5rem;
}
/* No map, no card. The border is there to hold the map and its words
together; around two lines of text on their own it reads as something
missing rather than something tidy (Vicky, 2026-08-10). The server sends the
words up to the summary line instead when there is no map to keep them here
(venueBlock.HasMap) — this rule is what covers the case it CANNOT know
about: apple-map.js removing its own mount in the browser, which would
otherwise leave a bordered box round nothing. */
event-venue:not(:has(event-map)) {
border: 0;
border-radius: 0;
margin: 1rem 0;
}
event-venue:not(:has(event-map)) venue-facts { padding: 0; }
/* 9px, not 10: the card's corner less its own 1px border, which is the
radius of the hole the map actually sits in. Only the TOP corners — the map
is the first thing in the card and the words sit under it. */
event-map { border-radius: 9px 9px 0 0; display: block; overflow: hidden; }
/* The Apple provider's mount. It starts DISPLAY:NONE and apple-map.js reveals
it in the one instant before MapKit measures it — because every other path
through that module (no JS at all, a blocked library, a token Apple
refuses, an address nothing can geocode) must leave a page identical to one
with no map provider, and a sized-at-parse-time box would instead leave an
empty rectangle above the address. Same proportions as the iframe once
shown, so switching providers doesn't move the page. */
event-map [data-apple-map] {
aspect-ratio: 3 / 2;
display: none;
width: 100%;
}
event-map iframe {
aspect-ratio: 3 / 2;
border: 0;
display: block;
width: 100%;
}
/* Letterbox only where there is room for one. 3:2 is the phone shape: at
375px the old 5:2 map was ~150px tall, too squat to place anything in, and
a map you can't read is worse than the address on its own. */
@media (min-width: 34rem) {
event-map [data-apple-map],
event-map iframe { aspect-ratio: 5 / 2; }
}
venue-facts {
display: block;
padding: .75rem .9rem;
}
venue-facts p {
color: var(--custom-text-color-muted);
font-size: .9rem;
margin: 0;
}
/* The other home: no map, so the words sit with the venue's name on the
summary line. No padding of its own — it is one more line in the meta
stack. The 1.3em indent that used to be here was clearing a LOCATION PIN,
and the pin went when the date and venue became one line (2026-08-20). What
was left was an address stepped in from the line above it and a directions
line stepped in again from that — which is the "clumsy/unfinished" Vicky
read on 2026-08-21. Flush left, like every other line in the stack. */
.pro-meta venue-facts { padding: 0; }
.pro-meta venue-facts p { font-size: 1em; }
/* Classic's meta line is a , so the facts follow it rather than sit
inside; close the gap the paragraph would otherwise leave. */
.classic-info p:has(+ venue-facts) { margin-bottom: 0; }
.classic-info > div > venue-facts { padding: .2rem 0 0; }
/* The directions line: the verb once, then the services. The separators are
TEXT between the links, not a ::before on them — a pseudo-element inside an
takes the link's underline (text-decoration draws over descendants
whatever they set) and sits inside its hit area, so the dots read as part of
the link and click like it. */
venue-links {
color: var(--custom-text-color-muted);
display: block;
font-size: .88rem;
margin-top: .35rem;
}
venue-facts p:not(:empty) + venue-links { margin-top: .5rem; }
/* ---- Directions, as one disclosure ----
The verb-and-three-services sentence became a menu on 2026-08-21: three
underlined targets directly above the ticket list competed with the one
thing the page is for. The mechanics are the ticket's
"Add to calendar" (public/cal_menu.css) — this bundle does not carry that
file, so the few rules are repeated rather than the file being moved into a
bundle the buyer journey would then load twice.
The summary is a LINK, not a pill: it belongs to the meta stack, and a
filled control there would put the weight back that the menu exists to
take away. */
.dir-menu { display: inline-block; position: relative; }
.dir-menu > summary { align-items: center; color: var(--custom-link-color); cursor: pointer;
display: inline-flex; gap: .15em; list-style: none; }
.dir-menu > summary::-webkit-details-marker { display: none; }
.dir-menu > summary:hover { text-decoration: underline; }
.dir-menu > summary:focus-visible { border-radius: .25rem; outline: 2px solid var(--custom-link-color); outline-offset: 2px; }
.dir-menu .caret { transition: transform .12s ease; }
.dir-menu[open] .caret { transform: rotate(180deg); }
.dir-menu > nav { background: var(--custom-text-background-color); border: 1px solid var(--custom-control-border);
border-radius: .5rem; box-shadow: 0 6px 20px -8px color-mix(in srgb, var(--custom-text-color) 30%, transparent);
display: flex; flex-direction: column; left: 0; margin-top: .35rem; min-width: 11rem;
padding: .3rem; position: absolute; z-index: 20; }
.dir-menu > nav a { border-radius: .3rem; color: var(--custom-text-color); font-size: .85rem;
padding: .4rem .55rem; text-decoration: none; white-space: nowrap; }
.dir-menu > nav a:hover { background: color-mix(in srgb, currentColor 8%, transparent); }
@media (prefers-reduced-motion: reduce) { .dir-menu .caret { transition: none; } }
/* IN THE CARD, THE PANEL OPENS UPWARD, over the map (Vicky, 2026-08-24: the
menu "is constrained in the box"). The clip that cut it off this time is the
PAGE card's, one box further out than the one moved off on
2026-08-21: .pro-card carries `overflow: clip` to hold the banner and the
theme's band inside its rounded corners, and where the location is the last
block on the page (page_arrangement.go — an organizer can put it there, and
the map is a tall thing to have last) the panel's third service falls past
the card's bottom edge and is cut.
Moving THAT clip is not the same trade as last time. It holds a stack of
full-bleed elements — banner, stub band, and a manifest theme's 8px colour
band — against a radius an account can set as high as 40px, and no
arrangement of per-element radii reproduces it: the element under the band
would need a partial corner, which border-radius cannot describe. So the
card keeps its clip and the panel stops needing to leave.
Upward is not a workaround here, it is the better placement anyway: a map
is 227px tall on a 375px phone and taller everywhere else, so a ~111px
panel always has room above the summary, and it lands on the map it is
about instead of over the ticket list — which is the same reason this
became a menu in the first place. Scoped to , so the OTHER
home of these words (up on the summary line, where there is no map because
venueBlock.HasMap sent them there) still opens downward rather than over
the event's own name. */
event-venue .dir-menu > nav { bottom: 100%; margin: 0 0 .35rem; }
/* event/event_columns.css */
/* The purchase construct in two columns: the list you are choosing from on
the left, what it comes to on the right (Vicky, 2026-08-22 — a buyer screen
earns a second column if it has a live updating amount, and this total moves
on every stepper press). Below the threshold these are three plain blocks in
source order and the page is exactly what it was, which is why the mobile
case needs no rules at all here.
A CONTAINER query, not a media query, and the two jobs are deliberately on
two different elements: a container query cannot style its own container, and
`container-type` carries `contain: layout style inline-size` with it — not
something to hand to an element whose own subtree is being shown and hidden a
step at a time by the wizard. So the FORM is the container and the block
inside it is the grid.
Measuring the form rather than the viewport is also what makes the widget
sheet and a themed page come out right for free: each asks how much room it
actually has, and a narrow embed simply never crosses the threshold.
EVERY RULE BELOW IS GATED ON data-priced, which eventFlowCore withholds from
an event where nothing — no ticket, no good, no add-on, no donation — has a
price (Vicky, 2026-08-23). The rule that earns a screen a second column asks
for an amount, and a free event has none: its total prints the word "Free"
and never moves again, so the rail would hold a Continue button the footer
already keeps in view and nothing else. Such an event keeps the single
column and the 640px card, which is what it had before this file existed.
The gate is an EVENT-level answer, not a live one. A rail that appeared the
moment somebody picked a paid ticket would slide the ticket list sideways
under them mid-press; the page is one shape from the first paint. (The two
checkout screens ask the same question of the ORDER, in railData — by then
the selection is made and cannot move.)
The attribute stays on the container query rather than replacing it: a free
event is one column at every width, and a paid one still has to be wide
enough. Both conditions, or the widget sheet gets a 352px rail in a 460px
box. */
form[data-checkout] { container-type: inline-size; }
@container (min-width: 900px) {
/* 22rem for the rail, which is the number that falls out of holding the
LIST still: a 1020px card less its 2rem padding is 956px, and 956 minus
this gap minus 352 leaves 576 — the exact width the ticket list has at
640px today. So the row a buyer already knows does not stretch by a single
pixel to pay for the second column (Vicky, 2026-08-23, asking whether the
left column needed to be that wide; at 20rem it was 608px, and the gap
between a ticket name and its price went from ~330px to ~360px).
The rail wanted the 32px anyway: at 320px its longest line, the group
discount's "Free tickets — 1 × Supporter", wrapped onto two. */
.purchase-cols[data-priced] {
align-items: start;
display: grid;
gap: 1.75rem;
grid-template-columns: minmax(0, 1fr) 22rem;
}
/* A grid item's min-width is auto, so one long unbroken ticket name would
push the column past its track and take the rail off the card with it. */
[data-priced] > .purchase-main { min-width: 0; }
/* A hairline, not a second card. The construct already sits inside
.pro-card, and a filled-and-shadowed box in there would be a card inside a
card — the boxes-in-boxes shape Vicky has taken out of the checkout twice.
The border is the same --divider-color the ticket rows rule themselves
with, so the rail reads as part of the same object.
The radius never exceeds the card's own, the way event_qty.css already
sizes a control inside it: a square-cornered card must not contain a
rounded panel. */
/* THE ACTION SITS UNDER THE THING IT ACTS ON, and the two travel together.
The rail is ONE sticky group — summary, then button — rather than two
stickies pinned to opposite ends of a stretched column.
It was the two-ended version first, on the reading that the button should
be pinned bottom-right on every screen (Vicky, 2026-08-24). Seeing it
built, she called the result "very isolated and unanchored", and the
screenshot says why: the summary is HIDDEN until something is selected,
so an event page at rest has an empty rail with a lone button pushed to
the foot of a track whose height comes entirely from the ticket list. It
floats in the middle of the page beside the third row, attached to
nothing.
Pinning it to the top of an empty rail instead only trades one fault for
the worse one: the button would then LEAP from top to bottom the moment a
first ticket was picked, which is the flying-around she named as the
thing to avoid. Keeping the pair together means the only movement is the
button stepping down by the height of the summary that appeared above
it — the natural consequence of content arriving, not a jump.
`align-items: start` is what lets the rail hug its contents again; with
`stretch` the column takes the list's full height and there is empty
track under the group. The checkout's own steps still pin their action to
the foot of their column, because there the summary must come BEFORE the
form (the total has to be above a wallet button that charges on a tap)
and the action after, so those two can never be one group.
Nothing here may become a scroll container. A sticky child of one stops
sticking silently, which is the trap #1552 already pinned for this
screen. */
[data-priced] > .purchase-rail {
border: 1px solid var(--divider-color);
border-radius: min(var(--custom-card-border-radius, 12px), 12px);
display: flex;
flex-direction: column;
position: sticky;
top: 1.25rem;
}
[data-priced] > .purchase-rail > .summary { padding: 1.25rem; }
/* The breakdown ARRIVES OPEN, showing what you are getting (Vicky,
2026-08-24, reversing the call recorded here). It was built this way once
before and taken out again on the grounds that six money fences went red
for it; that was a cost argument, not a design one, and she has now
answered the design question. The fences moved instead.
What did NOT change is whose state it is. The server picks the INITIAL
state and checkout-summary.js still never touches `open` — a buyer who
shuts the fold keeps it shut through every quantity change, which is the
contract that module has held since it was written. */
/* A timed event's wizard hides BOTH of the rail's children until the Tickets
step, and a reserved-but-empty third of the card beside the date cards is
just a hole. The column goes with it.
Reserving it was the first attempt, on the grounds that the list must not
shift sideways when the total arrives. That reasoning does not apply here:
the rail is only ever empty during the wizard, where the ticket list has
not been rendered yet, so there is nothing on screen to reflow. Everywhere
else the footer is showing, which means the rail has content from the
first paint and never collapses at all.
The two selectors ask the same question from opposite ends, and the
parent's has to be written as :not(:has(…)) rather than the :has(:has(…))
it reads like — :has() may not be nested inside :has(), so that form is
invalid and drops silently, leaving the track behind while the rail
correctly disappears (which is exactly how this was found). */
[data-priced] > .purchase-rail:not(:has(> :not([hidden]))) { display: none; }
.purchase-cols[data-priced]:not(:has(> .purchase-rail > :not([hidden]))) {
grid-template-columns: minmax(0, 1fr);
}
/* AN EMPTY CART HAS NOTHING TO FOLD. The box is on screen from the first
paint now, so before anything is chosen its disclosure would be a caret
over an empty drawer — checkout-summary.js marks that state and the
control stands down to a plain line of text until there is a breakdown
under it. */
[data-priced] .purchase-rail .summary[data-empty] > summary {
cursor: default; list-style: none; pointer-events: none;
}
[data-priced] .purchase-rail .summary[data-empty] .promo-caret { visibility: hidden; }
/* The disclosure is the first thing in the rail now, so the rule that
separated it from the ticket list above it would draw across the top of
the panel, a hairline inside a hairline.
BOTH HALVES, and only the margin was taken the first time (Vicky,
2026-08-25: "is there a darker/thicker top line here?"). The border
survived, landing exactly against the panel's own — two 1px lines of the
same colour stacked, so the top edge came out 2px while the other three
stayed 1px, which reads as a heavier line rather than as a doubled one.
The comment above described the fault and the fix only did half of it. */
[data-priced] .purchase-rail .summary { border-top: 0; margin-top: 0; }
[data-priced] .purchase-rail .summary summary { padding-top: 0; }
/* The Pro footer's negative margins exist to bleed the button band to the
CARD's edges (event_pro.css). The rail is not the card, so in here they
would drag the button out through the panel's border on three sides. */
/* The button lives INSIDE the box, under the total, with a hairline between
them — one object rather than a panel and a loose button. Every margin
goes, because the space is the box's padding now and a margin here would
push the button out through the border it is supposed to sit inside. */
[data-priced] .purchase-rail .pro-form-footer {
border-top: 1px solid var(--divider-color);
margin: 0;
padding: 1rem 1.25rem;
}
}
/* shared/owner_strips.css */
/* owner strips — the full-bleed lines a signed-in organiser meets above an
event's own public page, and (with one deliberate exception below) nobody
else ever does. Two of them today:
.secret-preview the page opens for you and answers not-found for
everyone else (event_secret.go). Without it, a page that
loads fine is the thing most likely to be read as
working when it isn't.
.owner-strip paid tickets are being kept off the page because no
payment door is open (shop.go's paidHidden). It reports
an ABSENCE, so there is nothing on the page beside it to
notice — which is why it moved up here from a tinted
note under the description (Vicky, 2026-08-12).
.sandbox-strip this whole page is a copy of the account, for testing,
and nothing on it is charged for real (sandbox.go). THE
ONE STRIP IN THIS FILE EVERYBODY SEES rather than only a
signed-in organiser — a sandbox address is openable by
anyone holding the link, on purpose, so the strip is the
only thing telling whoever is looking that the checkout
in front of them is not real.
LITERAL COLOURS, and that is the whole point of the file. Two reasons:
1. The event bundle carries no shared tokens at all (styles.go — event.html
is its own document on the account's own --custom-* palette), so
var(--warn) and friends do not exist here. Written against them the
strip rendered as unstyled bold text.
2. Even if they did, this is a message from Tito ABOUT the page rather than
part of the page, and an organiser palette could tint it into invisibility
or into looking like the event's own design. Sitting deliberately outside
the account's colours is what says "this is not your event page talking".
The pair is fixed and measures 15.0:1, so it clears AA on any account
palette, and the strips are full-bleed above everything so neither can be
mistaken for a banner the organiser chose. Both can be up at once — a
secret event with no payments connected stacks them, caveat first.
A THEMED PAGE LOADS NONE OF THIS. docs/themes.md § The CSS contract says so
outright, and it is a promise to theme authors rather than an oversight —
so the sandbox strip injected into a themed document carries the same
declarations inline, as sandboxStripDecls in sandbox.go.
TestSandboxStripStyleMatchesItsStripsRule compares the two declaration sets
and fails if either side gains, loses or changes one. */
.secret-preview,
.owner-strip,
.page-preview,
.sandbox-strip {
/* Near-black, deliberately not a hue: most of these report something the
reader has to weigh (paid tickets are being held back, this page is a
draft, this shop is a copy that takes no real money), and a coloured band
would either look like part of the design or like a warning about the
wrong thing. */
background: #1b1e27;
color: #f8f9fb;
font: 550 13px/1.4 ui-sans-serif, system-ui, -apple-system, "Segoe UI", Roboto, sans-serif;
letter-spacing: .01em;
margin: 0;
padding: .65rem 1rem;
text-align: center;
}
/* The secret strip takes the brand cobalt instead (Vicky, 2026-08-28): it is
the one of the three that carries no problem at all — the event is secret
because somebody chose that, and the strip exists so a page that loads for
you is not read as a page that loads for everybody. Louder than the
near-black on a white event page, and unmistakably ours.
#1a45c4 is --cobalt-600 written out, for the reason the whole file exists:
the event bundle carries no shared tokens, so var(--accent) would render as
nothing here. Against #f8f9fb it measures 7.4:1, so it clears AA for this
13px/550 text on any account palette, the same guarantee the pair above
makes. If the brand blue ever moves, this line moves with it by hand. */
.secret-preview { background: #1a45c4; }
/* .page-preview is the third strip: an organiser looking at one of their own
static pages from the admin (static_page_public.go). It is the only one that
carries a link and a state, because it is the only one whose two states LOOK
identical — a draft and a live page render the same, and whether anyone else
can open it is the one thing a preview cannot show.
Its link takes the strip's own ink rather than an accent: the pair above is
fixed at 15.0:1 precisely so no palette can weaken it, and a blue link
inside it would be the one thing on the strip an account's colours could
argue with. Underlined, so it still reads as a link without a hue. */
.page-preview {
align-items: center;
display: flex;
flex-wrap: wrap;
gap: .4rem .9rem;
justify-content: center;
}
/* a[href], not a bare `a`: the buyer journey paints every link
--journey-link from `body.buyer-journey a`, which outranks a lone class and
would leave this one the account's blue on a near-black bar — the exact
trap head_edit.css already records. The attribute buys the specificity
without borrowing the journey's own class, which this file cannot depend on:
the event page is a different document and has none. */
.page-preview a[href] {
color: #f8f9fb;
text-decoration: underline;
text-underline-offset: 2px;
}
.page-preview a[href]:hover { text-decoration-thickness: 2px; }
/* Amber for a draft, green once it is live — said before the sentence is read.
Never the only carrier: the words say the same thing. */
.page-preview .strip-dot {
background: #f2a33c;
border-radius: 50%;
flex: none;
height: 7px;
width: 7px;
}
.page-preview[data-state="live"] .strip-dot { background: #43c489; }
/* shared/embed_sheet.css */
/* The widget's purchase sheet: what a buyer page looks like when it is being
rendered inside the iframe on the organiser's own website, lifted over
their page (embed_journey.go, layout.html's embed-sheet-top/bottom).
THE SHEET'S RECTANGLE IS THE SAME ON EVERY STEP, and that is the point of
nearly every rule here (Vicky, 2026-08-10: "it needs to be static in the
centre of the page", after an earlier attempt where the modal jumped
around). Tickets, details, payment and confirmation are four very
different heights, so a box sized by its content re-centres on each one
and hops up the screen under the buyer's pointer. What stops it:
- a fixed WIDTH and HEIGHT, not max-height and not content-driven;
- `inset: 0; margin: auto`, which centres a fixed-size fixed-position
box in both axes and depends on nothing about what is inside it;
- one scrolling region, , between a header and a footer
that are outside it.
Change any of those three and the sheet starts moving again.
IT IS IN shared/ BECAUSE THE SHEET SPANS TWO DOCUMENTS, and that is the
one thing to know before editing it. The first step renders the event's
own purchase form, which is styled by the EVENT bundle (styles/event/, on
the account's --custom-* palette) in a document of its own — exactly as
event.html is. Every step after it is an ordinary buyer page in the
layout.html shell, on the public bundle's --journey-* palette. Two
bundles, one chrome, out of one file, so the box cannot drift between the
step that sells and the step that asks; styles.go lists it as a trailing
group on both.
That is why every colour here resolves through --sheet-*: each chain names
the journey token first, the event page's equivalent second, and Classic's
own literal last (Classic sets neither vocabulary — its card is #fff and
its rules are hardcoded, so the last leg is that card, copied from
event_classic.css). The legs are the same colour by construction —
--journey-card and --custom-text-background-color are both
Design.CardBackground, and so on down the list. A token that existed on
only one side would be a sheet that changed colour on step two.
THE SCRIM DOES NOT DIM THE ORGANISER'S PAGE, and cannot. A cross-origin
iframe never composites onto the page behind it — the browser paints the
frame's own canvas backdrop (#450, #732) — so what is behind the sheet is
OUR backdrop, and the scrim is what makes it read as a page dimmed under a
modal rather than as a flat colour. Nothing here may reintroduce
transparency on the frame; that road was walked and written down twice. */
/* The frame's canvas is PAINTED, never left to the browser — the same
lesson as #450/#732, arriving one document further in. What is behind the
sheet is our own canvas (a cross-origin iframe does not composite onto the
page behind it), and an unpainted canvas is filled by the browser from
whatever it decides the context is: viewed here it came out near-black
under a light design, which turns the scrim below from a dim into a void.
So the account's own page colour goes on deliberately, and the scrim dims
THAT. --bg carries it in both documents — layout.html's shell sets it from
the journey palette, event.html's head sets it from the account theme —
which is why this one is not a --sheet-* chain like the rest. */
body[data-embed-sheet] { background: var(--bg, #fff); min-height: 0; padding: 0; }
/* Every chrome rule below is written `body[data-embed-sheet] .es-…`, and the
prefix is load-bearing rather than tidy scoping. On the later steps this
file is read inside the public bundle, where `body.buyer-journey footer`
and `body.buyer-journey a` outrank a bare class — measured, and what it
cost was a footer that spread across the sheet on the step that sells and
huddled in the middle on the step that asks, with the close control
turning link-blue on the way. Same box, same chrome, both documents: the
prefix is what makes the second half of that true. */
/* The page inside the sheet gives up the buyer journey's card: the sheet IS
the card, and a card inside a card at 460px is two borders and two lots of
padding around a form that has neither to spare. Only the layout.html
steps have a to undo — the first step's own document has none.
`sheet-scroll > main`, not `body > main`, and the difference was 64px of
dead space under every confirmed order (Vicky, 2026-08-10: "quite a lot of
white space at the bottom"). The chrome wraps the page — scrim, sheet,
scroll region — so is two levels down and a child selector on body
matched nothing at all, silently: the rule was there, it was correct, and
it applied to no element on any step. The journey's own rule is
`body.buyer-journey > main` and lands a class-and-two-types, so this has
to carry one more than that to win rather than merely tie. */
body[data-embed-sheet] sheet-scroll > main {
background: none; border-radius: 0; box-shadow: none; margin: 0;
max-width: none; min-height: 0; padding: 0;
}
/* The page's own credit line is emptied in sheet mode (layout.html: the
sheet's foot carries the Tito line already), and an emptied element still
brings its 48px top margin with it — 48px of nothing under the last thing
a buyer read. Zero-height and no words means no gap either. */
body[data-embed-sheet] sheet-scroll > main > footer:empty { margin: 0; }
/* THE SHEET'S SIZE IS DECLARED ONCE, HERE, AND THE LOADER READS THE SAME
NUMBERS. Since the lift, the organiser's page is dimmed by a scrim in
THEIR document and our iframe is sized to the sheet and nothing more —
which means embed.js has to know how big the sheet is, and two files now
have an opinion about it. They agree because
TestSheetSizeAgreesWithTheLoader parses both and compares; a number
changed here alone fails that test rather than leaving a modal with a
transparent margin around it. Change them together.
--tito-sheet-w: 460px --tito-sheet-h: 640px --tito-sheet-full: 520px
(full = at and below this viewport width the sheet IS the screen). */
:root {
--tito-sheet-full: 520px;
--tito-sheet-h: 640px;
--tito-sheet-w: 460px;
}
/* The scrim inside the frame. Since the lift there is nothing behind the
sheet for it to dim — the frame is the sheet's own rectangle now, and the
dimming the visitor sees is the loader's, drawn on the organiser's page
where their content actually is. It stays for the one case that still has
a surround: the sheet opened on our own host, outside any widget, which is
how it is reviewed and how a `?embed=` link behaves if somebody shares
one. */
embed-scrim {
background: color-mix(in srgb, #000 55%, transparent);
inset: 0; position: fixed; z-index: 0;
}
embed-sheet {
/* The two token vocabularies this chrome can find itself inside, and
Classic's literals last. See the note at the top of this file. */
--sheet-card: var(--journey-card, var(--custom-text-background-color, #fff));
--sheet-fg: var(--fg, var(--custom-text-color, #30303a));
--sheet-heading: var(--journey-heading, var(--custom-heading-color, #252535));
--sheet-line: var(--line, var(--custom-control-border, #e1e1e1));
--sheet-muted: var(--muted, var(--custom-text-color-muted, #65656d));
--sheet-radius: var(--journey-radius, var(--custom-card-border-radius, 16px));
background: var(--sheet-card);
border-radius: var(--sheet-radius);
color: var(--sheet-fg);
display: flex;
flex-direction: column;
/* Fixed, not max-content: see the note at the top of this file. */
height: min(var(--tito-sheet-h), 100%);
inset: 0;
margin: auto;
overflow: hidden;
position: fixed;
/* No drop shadow, and that is a decision rather than an omission: the
sheet always sits on the scrim above, 55% black in either scheme, where
a black shadow paints nothing anybody can see. The elevation tokens are
the shared bundle's and do not reach the event document at all, so
asking for one here would be a shadow that appeared on step two and not
on step one — the exact drift this file exists to prevent. */
width: min(var(--tito-sheet-w), 100%);
z-index: 1;
}
body[data-embed-sheet] .es-head {
align-items: center;
border-bottom: 1px solid var(--sheet-line);
display: flex;
flex: none;
gap: .75rem;
/* Back on the left where there is one, close on the right always — the
event's name has gone from between them (layout.html says why). */
justify-content: space-between;
padding: .85rem 1.15rem;
}
/* THE EVENT'S NAME DOES NOT APPEAR INSIDE THE WIDGET, on any step. The
journey's steps each open with it as an eyebrow, which is right on our own
site — a buyer arriving from an email needs telling what they are paying
for — and wrong in a box pasted onto the event's own page, where they read
it a second ago (Vicky, 2026-08-10).
Matched by data-src rather than by class: the SAME eyebrow carries the
order reference on the order page ("Order R7X2QK"), which is not the event
name and is worth keeping. The attribute is what tells them apart, and it
is already there for the Customize studio's source map. */
body[data-embed-sheet] .bj-eyebrow[data-src="content:event.name"] { display: none; }
body[data-embed-sheet] .es-title {
color: var(--sheet-heading);
font-weight: 600;
/* One line, ever: the header is chrome, and an event with a long name must
not be allowed to push the tickets down the sheet. */
overflow: hidden; text-overflow: ellipsis; white-space: nowrap;
}
body[data-embed-sheet] .es-back {
align-items: center;
color: var(--sheet-muted);
display: inline-flex;
font-size: .9rem;
gap: .25rem;
text-decoration: none;
}
body[data-embed-sheet] .es-back:hover { color: var(--sheet-fg); }
body[data-embed-sheet] .es-back:focus-visible { outline: 2px solid currentColor; outline-offset: 2px; }
/* margin-left:auto rather than the header's justification: the close is the
only thing in the header on most steps, and space-between with one child
puts it at the START. Pushed from the element itself, it sits right
whether or not a back link is beside it. */
body[data-embed-sheet] .es-close {
align-items: center;
border-radius: 999px;
color: var(--sheet-muted);
display: flex;
flex: none;
height: 32px;
justify-content: center;
margin-left: auto;
text-decoration: none;
width: 32px;
}
body[data-embed-sheet] .es-close:hover { background: color-mix(in srgb, var(--sheet-fg) 8%, transparent); color: var(--sheet-fg); }
/* Drawn INSIDE the control, in the control's own colour: an indicator that
contrasts by construction against whatever it sits on, and one that a
years-old `:focus { outline: none }` on the page cannot reach — this is
our own document, but the rule is the same one #743's button follows and
it costs nothing to keep them alike. */
body[data-embed-sheet] .es-close:focus-visible { outline: 2px solid currentColor; outline-offset: -3px; }
/* The order review (embed_review.html), the modal's first screen once the
box out on the organiser's page has done the asking. A receipt: each line
is a name on the left and a price on the right, the total under a rule,
and the button. Sheet-only vocabulary, so it lives here rather than in
either bundle's own components. */
/* ADD-ON ROWS ARE ALWAYS VISIBLE ON THE REVIEW, and the rule they undo is
the reason they have to be. On the event page an add-on hides until its
ticket's stepper goes above zero (`.js [data-addon-for]`, event_addons.css)
— addon-rows.js reveals it, keyed to that input. The review has no
steppers for tickets: the choosing happened out in the box, and the rows
it offers were filtered to the chosen types SERVER-side. So the script has
no input to watch, would never reveal anything, and the heading sat over
an empty space. Shown from the start here, which is also what the rows
mean here. */
body[data-embed-sheet] .js [data-addon-for],
body[data-embed-sheet] li[data-addon-for] { display: list-item; }
body[data-embed-sheet] .review-lines { margin: 0 0 1rem; }
body[data-embed-sheet] .review-line {
border-bottom: 1px solid var(--sheet-line);
display: flex;
gap: 1rem;
justify-content: space-between;
padding: .7rem 0;
}
body[data-embed-sheet] .review-line dt { min-width: 0; }
body[data-embed-sheet] .review-line dd { flex: none; font-variant-numeric: tabular-nums; margin: 0; }
body[data-embed-sheet] .review-qty { color: var(--sheet-muted); }
body[data-embed-sheet] .review-total {
display: flex;
gap: 1rem;
justify-content: space-between;
margin: 0 0 1.25rem;
}
body[data-embed-sheet] .review-total strong { font-size: 1.15rem; }
/* The purchase form's own footer bleeds to the edges of whatever holds it,
and what holds it here is rather than the event page's
card — so the bleed is retuned to this padding instead of that one. The
bottom is squared off: on the page the footer is the last thing before the
card ends, and in the sheet there is a real footer under it. */
body[data-embed-sheet] .pro-form-footer {
margin: 1rem -1.15rem 0;
padding: 1rem 1.15rem;
}
sheet-scroll {
display: block;
flex: 1;
min-height: 0;
/* The sheet is over somebody else's page: a wheel that reaches the end of
this list must not start scrolling their article underneath. */
overflow-y: auto;
overscroll-behavior: contain;
padding: 1.15rem;
}
body[data-embed-sheet] .es-foot {
align-items: center;
border-top: 1px solid var(--sheet-line);
display: flex;
flex: none;
font-size: .8rem;
gap: .75rem;
justify-content: space-between;
padding: .7rem 1.15rem;
}
body[data-embed-sheet] .es-out { color: var(--sheet-muted); text-decoration-color: var(--sheet-line); }
body[data-embed-sheet] .es-secured { align-items: center; color: var(--sheet-muted); display: flex; gap: .3rem; }
body[data-embed-sheet] .es-secured a { color: inherit; text-decoration: none; }
body[data-embed-sheet] .es-secured svg { flex: none; }
/* INSIDE THE WIDGET'S FRAME THE SHEET FILLS IT, and the two rules below are
why this is not the phone rule underneath.
Since the lift, the loader sizes our iframe to the sheet exactly — so in
here the viewport IS the sheet, 460px wide, which is under the phone
breakpoint. Left to the media query the sheet would go full-screen and
square off its corners on a 27-inch monitor, and the frame around it would
still be a rounded 460px box. The outer screen is cross-origin and cannot
be read from in here at all, so what the sheet keys off is the one thing
it does know: that it is framed (embed-sheet.js sets the attribute). The
loader owns the size and the corners, because the loader can see the
screen; the sheet just fills what it is given.
The inner scrim goes with it: there is nothing behind the sheet in here
any more, and the dimming the visitor sees is the loader's, over the
organiser's own page. */
:root[data-framed] embed-sheet { height: 100%; width: 100%; }
:root[data-framed] embed-scrim { display: none; }
/* On a phone the sheet is the screen: no corners to round, no margin to
centre in, and every pixel of width spent on the form. Standalone only —
framed, the loader has already made the frame the screen and the rules
above have made the sheet fill it. */
@media (max-width: 520px) {
:root:not([data-framed]) embed-sheet { border-radius: 0; height: 100%; width: 100%; }
:root:not([data-framed]) embed-scrim { display: none; }
}